After a long time of silence, starting with this entry I'm going to post on this blog a number of excerpts from my new book, "ASP.NET 2.0 Website Programming", soon to be found in all good book stores 
. Please note that these pieces are taken from the Design section of the chapters, that is where I introduce the new ASP.NET 2.0 features & controls, and use that background information to design the module covered by the chapter. It's in the Solution section that the real code is actually being written to implement the sample website, and it's that part that I believe is more interesting and useful for many developers. However, that section is not very good for taking self-containing excerpts, as it should be read as a whole, and therefore I had to chose some examples from the Design. Hope you appreciate them As usual, any feedback is very welcome!
Enter the Master Page Model (Chapter 2)
ASP.NET 2.0 introduces a new “master page” feature that enables you to define common areas that every page will share, such as headers, footers, menus, and so on. A master page enables you to put the common layout code in a single file and have it visually inherited in all the content pages. A master page contains the overall layout for your site. Content pages can inherit the appearance of a master page, and place their own content where the master page has defined a ContentPlaceHolder control. Although this has the effect of providing a form of visual inheritance, it’s not really implemented with inheritance in an OOP sense—instead, the underlying implementation of master pages is based on a template model.
An example is worth a thousand words, so let’s see how this concept turns into practice. A master page has a .master extension and is similar to a user control under the covers. Following is some code for a master page that contains some text, a header, a footer, and defines a ContentPlaceHolder control between the two:
<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>
<html>
<head id="Head1" runat="server">
<title>TheBeerHouse</title>
</head>
<body>
<form id="Main" runat="server">
<div id="header">The Beer House</div>
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
<div id="footer">Copyright 2005 Marco Bellinaso</div>
</form>
</body>
</html>
As you see, it is extremely similar to a standard page, except that it has a @Master directive at the top of the page instead of a @Page directive, and it declares one or more ContentPlaceHolder controls where the .aspx pages will add their own content. The master page and the content page will merge together at runtime—therefore, because the master page defines the <html>, <head>, <body> and <form> tags, you can easily guess that the content pages must not define them again. Content pages will only define the content for the master’s ContentPlaceHolder controls, and nothing else. The following extract shows an example of a content page:
<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true" CodeFile="MyPage.aspx.cs" Inherits="MyPage" Title="The Beer House - My Page" %>
<asp:Content ID="MainContent" ContentPlaceHolderID="MainContent" Runat="Server">
My page content goes here...
</asp:Content>
The first key point is that the @Page directive sets the MasterPageFile attribute to the virtual path of the master page to use. The content is placed into Content controls whose ContentPlaceHolderID must match the ID of one of the ContentPlaceHolder controls of the master page. In a content page, you can’t place anything but Content controls, and other ASP controls that actually define the visual features must be grouped under the outermost Content controls. Another point to note is that the @Page directive has a new attribute, Title, that allows you to override the value specified in the master page’s <title> metatag. If you fail to specify a Title attribute for a given content page, then the title specified on the master page will be used instead.
Figure 2-2 provides a graphical representation of the master page feature.
Figure 2-2
When you edit a content page in Visual Studio, it properly renders both the master page and the content page in the form designer, but the master page content appears to be “grayed out.” This is done on purpose as a reminder to you that you can’t modify the content provided by the master page when you’re editing a content page.
I’d like to point out that your master page also has a code-beside file that could be used to write some C# properties and functions that could be accessed in the .aspx or code-beside files of content pages.
When you define the ContentPlaceHolder in a master page, you can also specify the default content for it, which will be used in the event that a particular content page doesn’t have a Content control for that ContentPlaceHolder. Here is a snippet that shows how to provide some default content:
<asp:ContentPlaceHolder ID="MainContent" runat="server">
The default content goes here…
</asp:ContentPlaceHolder>
Default content is helpful to handle situations in which you want to add a new section to a number of content pages, but you can’t change them all at once. You can set up a new ContentPlaceHolder in the master page, give it some default content, and then take your time in adding the new information to the content pages—the content pages that haven’t been modified yet will simply show the default content provided by the master.
The MasterPageFile attribute at the page level may be useful if you want to use different master pages for different sets of content pages. If, however, all pages of the site use the same master page, it’s easier to set it once for all pages from the web.config file, by means of the <pages> element, as shown here:
<pages masterPageFile="~/Template.master" />
If you still specify the MasterPageFile attribute at the page level however, that attribute will override the value in web.config for that single page.
NOTE: This excerpt was taken from the book "ASP.NET 2.0 Website Programming". Click here to find more about it, and download the complete source code of the sample project.