Advanced Master Pages Techniques

This section covers some of the more advanced techniques that are useful when dealing with Master Pages, such as nesting, the use of the Master property, strongly typed Master Pages, and the intricacies of handling relative paths when dealing with rendered content pages.

The real power of Master Pages shines when you begin adding reusable code to them as well as reusable user interface elements and styles.

Nested Master Pages

You can actually indicate that one master page is the master of another. There are a few restrictions to doing this and it can be a bit tricky to get working properly the first time you try it.

The main restriction is that when a master page is a child master page, the top-level element in the ASPX for that page must be a Content control and nothing else. Often when people think of nesting they think of classic ASP or even ASP.NET, where two different user controls were included back-to-back in a page, as shown in the following snippet:

<custom:TopHeader  runat=server /><br/> <custom:MidHeader  runat=server/><br/> 

The trouble here is that the preceding code is actually a linear sequence of controls, and not a nesting of controls. When you define the topmost master page, you define content areas in which other master pages will render themselves. The child master pages then define content placeholders that content pages will fill, completing the rendered pages. Take a look at Figure 24.3 to see an illustration of how master page nesting works to create a complete rendered page.

Figure 24.3. Illustration of Master Page nesting with Content Pages.

One thing to keep in mind when working with nested Master Pages is that the Visual Studio designer will not render any portion of a nested Master Page hierarchy except the topmost parent. All nested master pages and all content pages that utilize those master pages will not display in design mode, so you will have to do it the "old-fashioned" way and actually run the page to see what the final rendering looks like.

The "Master" Property

There's more to Master Pages than just creating reusable layout and style to maintain a consistent look and feel. Master Pages are also accessible programmatically at runtime. Each ASP.NET 2.0 page has a property called Master that is of type MasterPage.

You can use this property to access a host of properties and methods to provide common functionality across all pages that are associated with a given Master Page. Because MasterPage inherits from System.Web.UI.Page you can access all page-related properties of the master page.

More commonly, however, developers will expose methods and properties on the master page that provide functionality that can be shared among all pages that utilize the master.

For example, in the preceding nesting example you saw a Master Page used for an R&D department in a fictitious company. Assume that you need to provide a function called IsDevelopmentSupervisor that you want to be available to all pages within R&D that will indicate whether the current user is an R&D supervisor. You could add the following method to the RDMaster.master code-behind:

public bool IsDevelopmentSupervisor() {   return (Context.User.Identity.Name.ToUpper() == "KEVIN"); } 

Obviously in a production application you would replace this logic with something that queried the current user's Role membership, but the code is fine for this sample.

If you type "Master." into the Page_Load event handler in the code-behind for the RDdefault.aspx page, you'll notice that the method you just entered isn't there. Even after you rebuild the entire solution it won't appear. This is because the Master property is of type MasterPage. If you want access to a member of a specific Master Page, you will need to typecast it, as shown in the following code found in the RDdefault.aspx.cs file:

protected void Page_Load(object sender, EventArgs e) {     if (((RDmaster)Master).IsDevelopmentSupervisor())     {       Response.Write("Greetings, Boss.");     }     else       Response.Write("Greetings."); } 

The preceding code typecasts the Master property to the RDmaster class where the IsDevelopmentSupervisor method has been defined.

Strongly Typed Master Pages

Sometimes you will be writing code for pages and not know at design time which master the page will be associated with, but that isn't the most common scenario. More often than not, you will probably know at design time the type and file of the Master Page. If you know that information, you can give ASP.NET the information and it will provide you with a strongly typed Master property.

To create a strongly typed Master property, you just use the MasterType command in the ASPX file as follows:

<%@ MasterType VirtualPath="~/RDmaster.master"  %> 

If you do this, you'll be reminded of another incredibly handy feature in VS 2005: IntelliSense works inside the <%@ %> tags. After you recompile the page, you can change the previous typecasting code into the following, and it will even support IntelliSense:

protected void Page_Load(object sender, EventArgs e) {   if (Master.IsDevelopmentSupervisor())     Response.Write("Greetings, Boss.");   else     Response.Write("Greetings."); } 

Handling Relative Paths

A common problem among developers working on ASP.NET 1.1 sites is that the use of User Controls could create issues with relative paths. For example, if a user control refers to a relative path, that path will be treated as relative to the container of the control at runtime. This makes locating images, files, and other URLs somewhat of a mess when dealing with a lot of User Controls in different locations.

The same problem can arise when dealing with Master Pages. Take a look at the following simple HTML tag:

<img src="/books/1/237/1/html/2/images/navBorder.jpg" alt="Navigation Border" /> 

The hard thing to remember about Master Pages is that they aren't really pages on their own; they simply provide the ability to lay out content in containers. As a result, the HTML rendered by the code in the Master Page will actually render relative to the content page.

The way to get around this is to make appropriate use of server-side controls. As you probably know, there is a server-side control for virtually every HTML tag, including the img tag.

If you are putting HTML into a Master Page, and you know that the relative path of the code in the Master Page is not going to be the same as the relative path in the Content Page, then you can just put a runat="server" tag inside the control, and ASP.NET will take care of determining the appropriate location of the image. So, to make the image tag render appropriately regardless of where the Content Page exists in the directory structure, just change the code to look as follows:

<img src="/books/1/237/1/html/2/images/navBorder.jpg" alt="Navigation Border" runat="Server"/> 

Because server-side controls consume memory and add to the processing time of your page, you should use them sparingly. A good way to deal with it is to create the Master Page without a single server-side image or URL control and then to selectively convert client-side controls into server-side controls until the Content Page renders properly.