| By Thom Robbins |
Article Rating: |
|
| September 9, 2005 03:00 PM EDT |
Reads: |
31,017 |
While meeting with the development staff of a local company we began discussing a project that the CIO had assigned them earlier that morning. The project was actually the first in a series of about 15 planned Web sites scheduled over the next year. Each site was designed to expose sales and marketing collateral to their international reseller community. Their lead developer explained that the first site would contain about a hundred pages, but when complete they expected each site to have several thousand distinct pages. He said, "Layout control and reusability are key for this project to have any chance of success." In their hasty research that morning they had run across a new feature of Visual Studio 2005 called master pages. It seemed to them that this feature might be an important key to this project. However, they hadn't been able to completely understand how it could be used. In this article, as I did that afternoon, we will cover how master pages provide a flexible, template-based architecture for building Web-based applications using Visual Studio 2005 and the .NET Framework 2.0.
Nobody should argue that most Web sites contain a common layout. This provides a common look or brand that makes site navigation and usage easy and familiar. Unfortunately, this wasn't an easy task to implement in either classic ASP or in the first generation of ASP.NET. Of course, and rightly so, many would argue that "include files" in classic ASP and user controls and base pages in ASP.NET helped somewhat in solving this problem. Realistically, neither of these programming techniques was built to natively provide this feature. However, the main design goal of master pages was to solve this exact problem in a way that allowed flexibility for page designers and code reusability for developers. Master pages inherently provide a single location for common controls and layouts that are used across a set of pages and Web sites. Their design makes it easier to centralize the common functionality of Web pages and allows common updates to occur in one place.
The Anatomy of a Master Page
The concept of master pages is actually taken from the world of traditional print and page layout. The traditional master page in this context is a nonprinting page. It's used to create a consistent layout that contains elements that are repeated on each page within a larger document. In the print world this translated into things like headers, footers, and page numbers. The ASP.NET 2.0 Master Page infrastructure adheres to a similar concept and actually consists of two parts: the master page and one or more linked content pages.
Fundamentally, a master page is simply an ASP.NET file that has an extension of .master. Master pages are added to an existing Web site as a new project item, as shown in Figure 1. The master page is responsible for defining page layout, which can include things like static text, HTML elements, and server controls. The master pages also contain the top-level HTML elements for a page, such as <html>, <head>, and <form> tags.
Once added to a project the master page contains a special @Master directive that replaces the standard @Page directive used in ordinary ASP.NET pages. The new directive looks like the following:
<%@ Master Language="VB" CodeFile="MasterPage.master.vb" Inherits="MasterPage" %>
By default a master page is designed to contain the common appearance and behavior for all linked content pages. Within a master page you add placeholders called ContentPlaceHolders as shown in Figure 2. This is where at run time the child pages will insert their rendered page output. The ContentPlaceHolder control is rendered using the following markup:
<asp:contentplaceholder id="MenuHolder" runat="server">
</asp:contentplaceholder>
Any page that uses a master page to define the layout may only place content within the areas defined by the ContentPlaceHolder. From a page designer's perspective, this ensures a consistent site design. Any attempt to place controls outside of the ContentPlaceHolder control on a linked content page will generate an ASP.NET error.
Implementing a Content Page
An individual content page is linked to a master page through the MasterPageFile property within the page directive. This property is part of the .NET Framework 2.0 System.Web.UI namespace that provides user interface elements. An important part of this namespace includes the page class, which is generated automatically whenever a request is made for an ASP.NET form.
For example, when adding a new ASP.NET Web form into a project that contains a master page, the item dialog contains an option to select a master page as shown in Figure 3. When selected, this box enables the Select Master Page dialog box as shown in Figure 4.
Basically, a content page is simply a Web form with an enhanced page directive that causes the inheritance from a master page. Any existing Web forms can also derive from a master page by placing the MasterPageFile attribute in the page directive as shown below.
<%@ Page MasterPageFile="root.master" %>
In each of the content pages all page output is defined within the bounds of a Content control. Keep in mind that that the ContentPlaceHolder control is used to define a relative region within a master page. However, within a content page the Content control acts as the container for page information. When rendered on a content page this control uses the following markup.
<asp:Content ID="Content1" ContentPlaceHolderID="MenuHolder" Runat="Server">
Subscribe to .NET Developer's Journal Email News Alerts
Subscribe via RSS
