The Content control is mapped back to the ContentPlaceHolder controls located on the master page. Both the Content and ContentPlaceHolder controls are part of the System.Web.UI.Webcontrols namespace. The master page ContentPlaceHolder control is responsible for rendering all text, markup, and server controls from the rela-ted Content control found on a content page. The Content control on the child page is not a stand-alone control and it is paired with the ContentPlaceHolder control on a master page. For example, the master page might have two ContentPlaceHolder controls called MenuHolder and SelectionArea. Within the content page you can create two Con-tent controls, one mapped to MenuHolder and the other to the SelectionArea ContentPlaceHolder control.

Once a Content control is created, you can add text and other controls to it. It is important to remember that anything that is not inside the Content controls, except for script blocks, will generate an error. Within the Content control on a child page you are able to execute anything that you would in a normal ASP.NET page. For example, you can generate dynamic content using server controls or database queries the same as for any standard ASP.NET page.

Nested Master Pages
It is not uncommon to create multiple master pages to define layouts for various parts of a Web site. This can include different sets of content pages and even linked master pages. The master pages framework supports this as a concept called nested master pages. With nesting, a master page references another as its master. The goal of nested master pages is to allow the creation of componentized master pages.

For example, a company may define a root level master page, as shown in Figure 5, that enforces the overall look for the entire company. As each Web application is built, site developers can define their own master page, as shown in Figure 6. Each site master is based on the company-defined root master page. Keep in mind that the site master is still a standard master page. Typically, the site master will contain Content controls that are mapped to the content placeholders on the root master page. However, the site master page has content placeholders of its own to display content supplied by its child pages. When building site level pages, they inherit from the site level master page, which has inherited from the root level as shown in Figure 7.

Within Visual Studio 2005 Beta 2 the nesting of master pages is only supported within the source editor window of the IDE. However, once the solution is compiled and run it does render the page that has inherited from this nested structure, as shown in Figure 8.

Runtime Behavior
During development, always remember that master and content pages provide separate but linked containers for their respective controls. Master pages provide the ContentPlaceholder and content pages provide the Content controls. At run time the story is a little different. When a request is made for a content page, the ASP.NET compiler merges the output of the master page and content page together. The result is a single page that combines the master page layout with the output of a content page.

In order to accomplish this, the .NET Framework 2.0 implements a feature called partial classes. Using partial classes at run time the compiler merges the two ASPX pages with their associated code behinds together to form a single class. For developers this means that when using master pages, all of the objects on a page are available from the code behind without having to repeat or copy objects that already exist. Fundamentally, partial classes enable a class definition to be split into multiple physical files. Logically, partial classes don't make any difference to the compiler. At run time it simply groups all of the various partial classes into a project together and treats them as a single entity.

Partial classes are an essential part of the design of master pages. They enable the clean separation of the master and individual content pages. Also, they enable the clean separation between the business logic and user interface used for page design. For example, a page designer building a master page doesn't have to worry about the code being built in a content page. Additionally, a Web developer is able to debug a content page separately from the associated master page. The separation of physical files provided by partial classes makes this possible.

Reviewing the Object Model
Understanding how partial classes are used provides the foundation for understanding programmatic access to master pages. The merging of the master and content classes at run time makes the controls on the master page accessible to the content page code. For example, within a content page you can directly access public members or properties of the master page. In order to do this, you must first assign a class name to the master page using the following page-level directive:

<%@ Master Language="VB" ClassName="RootMaster" %>

Within the content page, the current page object exposes a built-in property named master. This property contains a reference to the MasterPage class defined above. Using this reference you can access a user-defined public property called MenuItem and set a label on the content page that contains its value by using the following code:

Dim masterPage As New ASP.RootMaster
lblMenu.Text = masterPage.MenuItem

In addition to casting a master page reference as shown above, you can also create a strongly typed reference to a specific master page by creating an additional <%@ MasterType %> page directive. This directive allows the content page to point to a specific master page as shown below.

<%@ Page masterPageFile="~/root.master"%>
<%@ MasterType virtualPath="~/root.master"%>