|
Build Web Sites Using Master Pages
ASP.NET 2.0 master pages enable you to set the common content for a group of Web pages quickly and easily, while also providing for each page's unique content.
by Dino Esposito
Posted June 11, 2004
Technology Toolbox: ASP.NET
Editor's Note: This article is excerpted from Dino Esposito's upcoming book, Introducing Microsoft ASP.NET 2.0 [Microsoft Press, ISBN: 0735620245]. It has been edited for length and format to fit the magazine. You can read a PDF of the full chapter here.
Most Web sites use a similar graphical layout for all their pages. This grows out of accepted guidelines for design and usability. Consistent layout characterizes all cutting-edge Web sites, no matter how complex. For some, the layout consists of the header, body, and footer; for others, it's a more sophisticated aggregation of menus, buttons, and panels that contain and render the actual content. Of course, you want to reuse code across the Web site's pages.
ASP.NET 1.x provides a workaround: You can apply a common layout to all the pages of a Web site by wrapping common user interface (UI) widgets in user controls and reusing them in all the pages. This powerful model produces modular code, but it soon becomes unmanageable when you have hundreds of pages to work with.
A better way to build and reuse pages must fulfill three requirements. The pages have to be easy to modify. Changes shouldn't require deep recompilation and diffuse retouching of the source code. And any change must have minimal impact on the overall performance of the application. ASP.NET 2.0 satisfies these requirements with a new technology—master pages (a kind of supertemplate)—and exploits the new ASP.NET Framework's ability to merge a supertemplate with user-defined content replacements.
A master page is a distinct file that defines the template for a set of pages—much like a PowerPoint master slide. It contains the page's static layout and is referenced at the page level. Regions that you can customize on each derived page are referenced in the master page with a special placeholder control. A derived page is simply a collection of blocks that the runtime uses to fill the holes in the master.
Master pages are transparent to end users, who see and invoke only the content pages' URLs. If they request a content page, the ASP.NET runtime applies a different compilation algorithm and builds the dynamic class as the merge of the master and the content page (see Figure 1). No master file is ever downloaded.
You can start using this new technology by coding the shared user interface and functionality in the master page, which also contains named placeholders for content provided by derived pages. Master page files have a .master extension. Page syntax resembles that of a regular .aspx page, but has a top @Master directive replacing the @Page directive, and one or more ContentPlaceHolder server controls. Each embedded ContentPlaceHolder control identifies a region of markup text whose real content comes from content pages at run time. The body of a master page can contain any combination of server controls, literal text, images, HTML elements, and managed code. All this, plus the content bound to placeholders, originates the virtual .aspx source for generating the dynamic page class for the user.
Content pages and master pages work in conjunction—neither are of any use by themselves. You get an error message if you request a .master resource, because ASP.NET considers .master a forbidden type of resource. You also get an error message if you request an .aspx resource that's built as a content page but isn't bound to an existing master page. (You'll learn more about content pages in a moment.)
Back to top
|