Back to description
DotNetNuke (DNN) is a dynamic, database-driven web application that leverages Microsoft ASP.Net to construct a full-featured... more
DotNetNuke (DNN) is a dynamic, database-driven web application that leverages Microsoft ASP.Net to construct a full-featured website in minutes. As an open source product, the barrier to entry is low in terms of dollars; however the wealth of features can seem daunting at first. DotNetNuke uses Internet Information Services (IIS), the web server included in Windows, and SQL Server 2005 Express Edition, a free database server available for download from Microsoft out of the box. As you migrate a DotNetNuke website out to a hosted web server on the Internet, you’ll probably implement a SQL Server 2000 or SQL Server 2005 database for a little more horsepower.
DNN offers plenty of features to solve common business problems. Graphic design and custom module development both have input on the usability and construction of a website. There’s a certain balance to strike between beauty, familiarity, and discoverability.
... less
The goal of this chapter is to make you comfortable with installing DotNetNuke. If you’re new to web development and databases... more
The goal of this chapter is to make you comfortable with installing DotNetNuke. If you’re new to web development and databases, this can seem daunting the first few times. You should practice installing the software a couple of times to get familiar with the experience.
DotNetNuke v4.5.0, released April 6, 2007, included a fantastic new feature for installationa set of web pages that manage the installation on your behalf and greatly reduce the complexity of the process. Prior to this version, the installation process involved a couple of key edits that were a little tricky to the uninitiated.
If there is a list of things that contribute to the drag on adoption of DotNetNuke technology, the manual installation process is on that list. As of DotNetNuke v4.5.0, this drag has been nearly eliminated. If you have the ambition to install a great ASP.Net technology, there’s little that will get in your way of seeing the default home page of fresh DotNetNuke installation today. That’s not to say the manual installation process doesn’t still have a valid place. This chapter covers a couple of different installation techniques, starting with the prerequisite software, then manual installation procedures, and finally using the shiny new installation wizard.
If you already have some experience with ASP.Net, there’s a good chance you have the prerequisite software installed on your local development computer. DotNetNuke is built on the ASP.Net Framework and will feel very natural to folks who edit web user controls and web.config files on a daily basis. For the benefit of those who are just starting to explore this area, the chapter begins with the assumption that you have a modern computer in front of you running Microsoft Windows, and that’s about it.
web.config
Adding a new DotNetNuke skin you found online is one of the easiest ways to customize a portal and give a site a new look... more
Adding a new DotNetNuke skin you found online is one of the easiest ways to customize a portal and give a site a new look. It’s also a way to draw some inspiration from fellow designers and learn how they accomplished a particular design. Analyzing how other designers have architected their skins provides a good background for modifying an existing skin in Chapter 4, “Exploring Skins” and developing your own skin in Chapter 5, “Creating Custom Skins.”
This chapter covers the following:
Obtaining DotNetNuke skins online
Reviewing the contents of a skin package
Installing a skin using the DotNetNuke administration pages
Installing a skin using the Install folder
Controlling access to a skin
A good way to learn what's possible with skinning DotNetNuke is to see what others have done. A simple search for “DNN skins” on the Internet will return a large number of sites. Some skins are freely available online, and others charge a small fee. First, you’ll poke around and see exactly what files are inside a skin package, and then you’ll apply some skin pages in a couple of different scenarios.
From their control of the HTML structures to their ability to select from a series of controls that expose powerful features... more
From their control of the HTML structures to their ability to select from a series of controls that expose powerful features in DotNetNuke, skin designers, of all the users of DotNetNuke, have the most granular level of control over page layout. After all, the DNN skin determines the entire page layout. Administrators also have a say in the look of a page, because they can elect to enable or disable skin features through the online tools in the system.
This chapter focuses on the core of the book: understanding DotNetNuke skins. It starts with a detailed exploration of skins, panes, and containers. Skin objects and other controls within these files are covered, too.
Editing skin files is a developer-oriented task where text editors are used nearly as often as the web browser. There’s a certain balance to strike in your mind between aesthetic interpretation and technical know-how. Therefore, this is a good time to discuss some developer practices that professionals use every day to protect their work and to be as productive as possible with their time.
The task of designing a skin has a fair number of considerations. One is the structure of the HTML output. The layout of the HTML can help or hinder search engine indexes as well as the design agility of the page. Search engines traverse the Document Object Model, or DOM, of web pages. This is the structure that starts with the opening <html> tag and branches out to every tag in the page in a hierarchical format.
<html>
Consider two pages that display the same content. In this contrived example, the first page uses a series of nested tables, font tags, and style attributes that contribute to a complex DOM. The second page uses only header tags, paragraph tags, and ordered list tags to produce the equivalent page. If you were writing a search engine, how could you calculate the value of the jumbled mess on the first page? You probably couldn’t. Which page would your search engine rank higher? The second page, because it clearly identifies section titles and detailed content. The search engine wants to learn the intent of the content on the web page. Web page designers have a choice of giving good hints about content up front or burying those hints deep within the DOM. I suggest you provide the hints up front.
Another great reason to concern yourself with the HTML output is the agility of the design. If CSS files are used to control the margins, padding, and positioning, then massive updates to all the pages of the site are considerably less work. Only one or two files can be edited and affect all of the pages in the website. You can also be much more certain of consistency throughout the site. If all of the <h1> tags use the same CSS rules, then you don’t have to worry about some pages using the wrong font or size. This would not be the case if the presentation rules were hardcoded into each page. If you resign to using a series of nested tables and their friend, the spacer.gif file, then the file size of the page is increased and the DOM is more complex.
<h1>
spacer.gif
A classy brochure site that touts a product or service company’s offerings to the public has different needs from a structured portal for an information worker who uses the site to perform his job for three hours out of the day. When you create your own custom skin, you need to consider the intended audience and continuously evaluate the website copy. In this chapter, you start with a finished product and analyze it. In, Chapter 5, “Creating Custom Skins,” you start with a clean slate and design a skin of your own.
Now that the preliminary items have been addressed, it’s time to discuss the steps for developing a custom skin from the... more
Now that the preliminary items have been addressed, it’s time to discuss the steps for developing a custom skin from the ground up. In the last chapter, the components of an existing skin were examined and modified to see some of the moving parts. Now you’ll create one of your own.
The first prerequisite for creating a custom skin is an idea for a design. This can take the form of a large JPG file that mocks up the entire page in the browser, or something less sophisticated like a piece of paper with some scribbling. The important thing is to identify a goal for the skin to achieve with an acceptable level of risk. If your client has to approve the site before they cut the final check, you’re probably less willing to accept risk in the design.
The design is the inspiration for constructing the skin and container files, as well as the CSS files used by both items. This chapter outlines a couple of approaches for constructing each element of a skin and discusses some tools useful for solving problems that are bound to spring up along the way.
This chapter lays the foundation for constructing a website for a neighborhood association. The first five chapters covered... more
This chapter lays the foundation for constructing a website for a neighborhood association. The first five chapters covered the principles of developing custom DotNetNuke skins from an academic and forensic perspective. This chapter begins a series that will apply these skills to develop a complete website with custom skins and selected modules that fulfill the needs for the audience of the specific website.
The idea of a neighborhood association website has broad applications because it deals with many types of users, serves several purposes, and has distinct branding requirements. The site must reflect the character of the people in the neighborhood and present the information in a compelling and understandable manner. This setting is a good incubator for the skills you’ve covered in earlier chapters. Now, you’ll apply them to a website for a group of people with specific needs.
In this chapter, you design, construct, and configure a fictional neighborhood association website starting from a default DotNetNuke installation. You’re taking a step back from the angle brackets and CSS rules used to design a single skin and getting a feel for the overall needs of a website. This activity will help to advise and inform decisions that you will make later on when you dive back into the raw HTML. It’s important to understand the intended audience and the capabilities of the core DotNetNuke modules. So, you take a look at both factors throughout this chapter to gain some valuable insight for an effective set of skins.
Chapter 6 set the stage for building an appropriate website for the Neighborhood Association. The modules were installed... more
Chapter 6 set the stage for building an appropriate website for the Neighborhood Association. The modules were installed on the remote server and the essential pages were created. The remote server is currently in a usable state, but it doesn’t have any custom skins, yet. The site is displaying the default DNN-Blue skin for all pages.
You haven’t done too much with the local development server, but now its time has come. The custom skin will be developed and revised on your local machine. Then, the skin will get bundled up and installed on the remote server. If any skin problems are encountered on the remote site, you can work out the kinks on your local machine, bundle up the skin again, and reinstall it on the remote server.
The first five chapters described the fundamental parts of a skin and how to create a custom design from scratch. This chapter goes deeper and applies the prior skills to several types of pages. First, you’ll use the information about the content of the neighborhood association website to plan some custom skins. Next, you’ll cover some common ways custom skins can go awry. Finally, you’ll use this information to construct and apply a custom set of skins to several pages in the site.
The skinning project for the Montavilla Neighborhood Association website happily used the default menu skin object in DotNetNuke... more
The skinning project for the Montavilla Neighborhood Association website happily used the default menu skin object in DotNetNuke, until now. In this chapter, you take a closer look at the menu skin object and explore the options available to you.
A web page is rarely without a menu navigation system so visitors are subjected to many types of menus. Menus in DotNetNuke are usually implemented as skin objects. Skin objects are well suited for this specialized task. The following list describes the common traits of a skin object:
Provides a small, contained feature for a DotNetNuke site.
Exists inside of a DotNetNuke skin file.
Can be customized through properties it makes available to the skin developer.
Can be customized by editing the .ascx file in a text editor, if available.
.ascx
Can be customized by editing the VB.Net or C# code, if available.
A similar skin object probably already exists.
Easy to swap for a best-fit comparison.
Skin objects are nothing new, and you’ve dealt with them on a regular basis in the previous chapters. This chapter focuses on a particular type of skin objectsthose providing menu navigation services. A menu skin object has the ability to request the pages from DotNetNuke. The menu skin object formats the pages into a navigable list for a web page and emits the necessary HTML.
You’ll see how to install a third-party skin object as well as configure alternative menu controls that are already available in a default installation. You’ll leverage one of the alternative menus and apply it to the Neighborhood Association website.
This chapter takes a good look at web user controls and their roles inside a DotNetNuke skin. Previous chapters explained... more
This chapter takes a good look at web user controls and their roles inside a DotNetNuke skin. Previous chapters explained their basic principles, such as how HTML skins are converted into web user controls, or how to create skins as .ascx files directly. Now you’ll go just a little deeper and leverage custom web user controls in your skins.
In an effort to give you a well-rounded familiarity with the DotNetNuke skinning technology, this chapter introduces some ASP.Net coding concepts. You might find that you have a particular fondness for ASP.Net code and have some great ideas for new modules or skin objects. If that’s the case, I highly recommend Professional DotNetNuke 4 by Shaun Walker et al. (Wiley Publishing, Inc., 2006) for more information on writing custom code that targets the DotNetNuke API.
With that in mind, this chapter takes on the following topics:
How to reduce the amount of redundant code
How to create a more interactive skin
How to develop a specialized skin object
Microsoft Silverlight is a new in-browser technology that adds rich interactive features to websites. HTML, CSS, and JavaScript... more
Microsoft Silverlight is a new in-browser technology that adds rich interactive features to websites. HTML, CSS, and JavaScript are great tools, but they can only take a web page so far as a document. Silverlight provides a way to embed audio and video in a page that goes far beyond the capabilities of Windows Media Player. JavaScript can automate the functionality inside the Silverlight object model, too. Silverlight is an exciting way to learn more about rich interactive applications inside DotNetNuke. This chapter gives you a nickel tour of the technology.
The ubiquitous nature of video today makes it a compelling idea for your website. Video recorders are common in households, and many mobile phones even have video recording features. The source of video content is deep. This chapter takes advantage of the video resources available to you and applies it to the DotNetNuke site. In this chapter, you’ll use Silverlight to perform the following tasks:
Build the compulsory Hello World application in Silverlight.
Animate basic shapes on an HTML page.
Extend a DotNetNuke skin by adding an image rotation component through animation.
Build a custom video player with control buttons and video library.
The previous chapters have given minimal explanation to CSS in lieu of other topics. DotNetNuke is so large that your focus... more
The previous chapters have given minimal explanation to CSS in lieu of other topics. DotNetNuke is so large that your focus at any given time on a project is limited to a small subset of the features. Hooray for checklists!
This chapter aims to make you proficient at reading and authoring a few CSS rules. You review some common CSS properties and how they can be used to build a custom design. Most sites make use of these rules in their style sheets; they always seem to throw in some uncommon CSS properties, too. If this is your starting point with CSS, you really ought to take a look at Beginning CSS: Cascading Style Sheets for Web Design, 2nd Edition by Richard York (Wiley Publishing, Inc., 2007), for a more detailed study of CSS.
In this chapter, you learn the following details about CSS:
The structure of a CSS rule in a style sheet
How to target a block of HTML with a selector
How to use margins and padding
How to apply font treatment
How to use background images
How to use positioning for a custom layout
How to edit default styles in DotNetNuke
Although there are many CSS properties, mastering fewer than ten will get you well on your way to understanding nearly any style sheet. This chapter starts with a focus on common CSS rules used on modern, standards-compliant sites. After the fundamentals are covered, you’ll apply these skills inside the DotNetNuke framework.
The HTML and CSS syntax have been around for long enough that several standards have evolved. The HTML 4.01 specification... more
The HTML and CSS syntax have been around for long enough that several standards have evolved. The HTML 4.01 specification available on the World Wide Web Consortium’s site reached recommendation status on December 24, 1999. More recent specifications such as XHTML 1.0 bring additional values to the party, like a predictable document object model. It’s far more important to use a specification consistently on a site than to debate which one to employ.
DotNetNuke has made strides toward compliance in their default installation. Earlier versions contained more issues than later versions. I anticipate DotNetNuke will make a shift to full web standards compliance over time. As you’ll see later on in this chapter, DotNetNuke can be customized to achieve a web standards-based architecture today.
The popularity of DotNetNuke and the vast market for third-party components can also work against a developer and make it difficult to maintain a standards-based system. Envision a graph where the X axis represents the number of unique modules on a DotNetNuke site and the Y axis represents the work exerted to maintain a standards-compliant site. My hypothesis is the line is not flat and probably not even linear. Web standards are not critical to every software vendorif you don’t intend to have guests over, why bother cleaning the house?
This chapter aims to describe standards-based architectures in greater detail. Chapter 5 introduced related topics including Quirks mode and employing a doctype in a web page. This chapter expands upon that web standards discussion and applies its merits to DotNetNuke. This chapter covers the following topics:
Testing for standards compliance
Constructing a standards-based DotNetNuke site
Applying a standards-based menu skin object
Swapping the HTML editor provider
When a developer builds his or her own module or a designer works in tandem with a developer, they have a large impact on... more
When a developer builds his or her own module or a designer works in tandem with a developer, they have a large impact on the HTML emitted by the component. When a developer customizes an existing component using CSS and other techniques, he or she continues to have a need to research and evaluate the HTML emitted by the component. Developers and designers target blocks of HTML with CSS. This chapter focuses on honing these targeting skills.
You’ll dissect an assortment of DotNetNuke modules including one available for free as a separate download from the DotNetNuke website. The goal is to learn some techniques for skinning existing modules by examining their structures, classes, IDs, and hierarchies. You’ll see how some modules are more customizable with CSS than others, based on how much presentation layer code exists in the actual HTML emitted by the components.
Each module presented in this chapter includes an evaluation of the default content it presented to you. Then you’ll experiment with a technique in building a custom design with one of the opportunities presented.
This chapter develops custom designs with CSS using the following modules:
UsersOnline
Contacts
Wiki
News Feeds
AJAX is the acronym for asynchronous JavaScript and XML. It’s a slick technique for improving the experiences of website... more
AJAX is the acronym for asynchronous JavaScript and XML. It’s a slick technique for improving the experiences of website visitors in very specific scenarios. Most web pages won’t have a case for implementing AJAX, but when the scenario is right, it can significantly elevate the visitor’s perception of the website.
This chapter explores ways DotNetNuke websites can embrace features available through AJAX without becoming too bogged down in the details. The Microsoft ASP.Net 2.0 AJAX Extensions 1.0 offers a solid framework for DotNetNuke developers as well as designers. As you might have expected, the DotNetNuke team has also been working on a compelling set of AJAX features for the past few years.
To help ensure that you have a good experience with the exercises in this chapter, use DotNetNuke version 4.5.5 or later. Earlier versions might not work as well with the AJAX features you’ll use in this chapter.
This chapter works through the following concepts:
Understanding the components of Microsoft ASP.Net AJAX
Understanding the context of the Client API inside the DotNetNuke framework
Customizing DotNetNuke with minor enhancements
Skinning a custom module with AJAX features
In a traditional website production process, selected headers of a web page are expressed as image files embedded in the... more
In a traditional website production process, selected headers of a web page are expressed as image files embedded in the HTML content, sometimes called image-text files. An image-text file enables the display of fonts that are not installed on the visitor’s operating system. It’s simply a picture of the formatted word or phrase. The font specifications inside a CSS file are at the mercy of the visitor’s operating system, which make image-text files a good alternative for showing a specific font on all browsers. CSS files generally specify well-known and widely distributed fonts. Depending on the size of the site, a designer might have to create a hundred or more image-text files. As a negative side effect, the practice of using image-text files discourages the work of copy editors who swoop in later and request small changes to the words inside the image-text files.
Scalable Inman Flash Replacement, or sIFR (pronounced siff-er), is a great technology for adding interesting fonts to a web page that might not be installed on the visitor’s computer. This chapter explains how to add unique and distinctive fonts to a web page without going through the hassle of managing a series of image-text files or distributing rare fonts to the visitors of the website before they browse it.
The technology inside sIFR replaces selected parts of a web page with Adobe Flash content on the fly using the client-side resources of JavaScript, Flash, and CSS. The standard HTML content inside the page is unchanged, so it’s easily tweaked by copy editors. The down-level browser experience is as good as it gets, too! When a user without Flash visits a sIFR-enabled site, the browser simply skips the Flash replacement of the selected content and the page renders as standard HTML.
This chapter shows how to achieve the following tasks:
Download and understand the basic sIFR components.
Select and install a new font for a website.
Generate Adobe .swf files with and without Adobe Flash CS3 Professional.
.swf
Add sIFR to a custom DotNetNuke container.
Answers to the exercises at the end of each chapter.... more
Answers to the exercises at the end of each chapter.
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Watermarking Wrox Chapters on Demand are sold with a small unique watermark at the bottom of each page identifying the purchaser name, email address, and order number.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they can be viewed using the Adobe Reader, ADE, or a compatible PDF reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapters on Demand File Any Wrox Chapters on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions or need any further assistance please refer to Technical Support (www.wiley.com/techsupport) or call (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday).
Related Books