File Organization

ASP.NET 2.0 Master Pages versus Skinning

The goal behind this section is to offer a minimal understanding of ASP.NET 2.0 Master Pages so there is a basis for comparison between them and the DotNetNuke skinning engine. This section is not a definitive guide on how to get started using Master Pages.

A Brief Introduction to Master Pages

With ASP.NET 2.0 a new concept of Master Pages was introduced. For those who have done HTML design work in the past with Dreamweaver, this concept is similar to Dreamweaver HTML templates that have a file extension of .dwt. The idea behind Master Pages is a pretty simple one: create a page template that allows for a consistent look and feel throughout an ASP.NET application while also allowing for various content areas to be replaced at runtime. Each Master Page template uses the .master file extension and can be created and used when you're working within Microsoft's Visual Web Developer.

One of the things that makes Master Pages different from normal HTML design templates is that they use a ContentPlaceHolder that allows for content to be merged from Content Pages at runtime. These content placeholders are represented by <asp:contentplaceholder> controls in the HTML code view of the Master Page template. As a developer or designer, you have the ability to use more than one ContentPlaceHolder within a single Master Page as long as you give each one its own unique ID within that page. Each ContentPlaceHolder on a Master Page is replaced with a Content Page at runtime. This means that for each ContentPlaceHolder you want to have replaced at runtime, you must create a Content Page for it. If you do not have a Content Page for every ContentPlaceHolder, default content will be loaded into the ContentPlaceHolders with no corresponding Content Pages. These Content Pages are linked to the Master Page using the @ Page directive at the top of the page and the actual content area is enclosed within the <asp:content> tag and its corresponding closing tag. Because the Content Page is linked to the Master Page, and will get injected into that Master Page at runtime, the normal HTML, BODY, HEAD, and FORM markup tags are not necessary. In fact, using one of these HTML markup tags outside of the Content control throws the following error at time of compilation: "Only Content controls are allowed directly in a Content Page that contains Content control."

Master Pages are definitely a step in the right direction for Microsoft and the .NET platform. They allow for the separation of content from the page and provide an easier way to get a consistent look and feel throughout the entire application

Why DotNetNuke Still Uses its Skinning Engine

Considering all the advancements that were made for developers and designers with the introduction of Master Pages, you are probably asking yourself, "Why is DotNetNuke still using its proprietary skinning engine rather than taking advantage of Master Pages?" Even with the flexibility introduced with Master Pages, they are not without restrictions of their own.

One restriction of Master Pages is the lack of complete separation between the developer and the designer. It's great that with Master Pages a developer can isolate the content area and then ask the designer to work on that specific area. Although this isolates the designer to a specific area, many designers are not comfortable working within the Visual Studio environment despite the IDE used in Visual Studio, which shows the Master Page with the Content Page loaded into it at design time. For designers to be as productive as possible, they must be able to use the tools they feel most comfortable with. One thing that should not be overlooked is that many designers use an Apple operating system, which will not run Visual Studio, therefore making the concept of Master Pages useless to these designers unless they work in a text editor. Why should HTML design be limited to a designer using a Microsoft Windows operating system?

Note 

This is one of the great benefits of the DotNetNuke skinning engine. It removes these restrictions placed on the designers. They are free to design on whatever operating system using whatever tools they choose, thus allowing them to be more productive.

Another restriction of Master Pages is that even though the designer is limited to a specific content area, there is still .NET code throughout that area. If designers open a Content Page in Visual Studio or their favorite HTML editor, they will see the @ Page directive and server control tags. If the designer has little or no experience working with ASP.NET applications, he could easily, and possibly unknowingly, alter one of these lines of code. If this happens, it means the developer has to spend time tracking down the problem. Because DotNetNuke completely isolates the design from the code by using the skins in combination with modules and skin objects, this situation is less likely to occur. Not only do the chances of a designer altering a developer's work decrease exponentially, it also allows them to work completely independent of one another. The developers can now spend their time developing modules, and the designers can spend their time creating skins and containers. With this complete separation between the two, both designers and developers can be working on the same site simultaneously instead of one waiting for the other.

As you can see, there are several good reasons why DotNetNuke still uses its own proprietary skinning engine instead of implementing Master Pages. One thing that was not addressed is the amount of development effort it would have taken to implement the Master Pages model. Just because a new feature was introduced to the ASP.NET framework, it is not necessarily better than one that was architected to fill a void left by the previous version of the ASP.NET framework. Using the DotNetNuke skinning engine, designers can work more efficiently and produce a better design without having to be concerned with altering the developer's code. The decision to still use the DotNetNuke skinning engine instead of Master Pages was not one that held DotNetNuke back, but one that kept it a step ahead.