Master Pages: Tips, Tricks, and Traps

Hi,

This blog post summarizes best approaches you require while working with Master Pages.

Link Referrred: http://weblogs.asp.net/scottgu/archive/2006/04/18/Great-New-Advanced-Article-on-ASP.NET-2.0-Master-Pages.aspx & http://odetocode.com/Articles/450.aspx

· Parent – Child Architecture

· Event Sequence

· Content Page to Master Page Interaction

· Master Page to Content Page Interaction

· Master Pages and Cross Page Postbacks

· Headers, Scripts, and Meta Tags, Too - Read if from above Link referred.

· Find Control & Name Mangling - Read if from above Link referred.

· Break Urls - See my post - Using URL's in Master Pages

· Master Pages and Themes

· Nesting Master Pages

· Sharing Master Pages - Read if from above Link referred.

Parent – Child Architecture

Let say we have, simple master page as below.

Let say we have, simple content page as below.

Before a web request arrives the page and master page are two separate objects, each with their own children as below.

When a web request arrives for an ASP.NET web form using a master page, the content page (.aspx) and master page (.master) merge their content together to produce a single page.

The master page's next step is to look for Content controls in the controls formerly associated with the page. When the master page finds a Content control that matches a ContentPlaceHolder, it moves the controls into the matching ContentPlaceHolder. In our simple setup, the master page will find a match for ContentPlaceHolder1, and copy over the Label.

All of this work occurs between the content page's PreInit event and content page's Init event

Event Sequence

Inheriting from the above figure, ASP.NET events work their way down the tree of controls. The truth is all lifecycle events (Load, PreRender, etc.) work in this fashion except the Init event. The initialization event works from the inside out. Since the master page is inside the content page, the master page's Init event handler will fire before the content page's Init event handler.

Hence, except Init Event, all the other events fires first for Content Page and then for Master Page.

Content Page to Master Page Interaction

This is simply achieved using the Master Property. You can read it from the link.

Master Page to Content Page Interaction

This is simply achieved using the delegate-event mechanism. Similar to the way we do in User Controls.

Master Pages and Cross Page Postbacks

Postback happens when a control on the master page POSTs to a second web form. For e.g assume a TextBox and Button to the master page.

<asp:TextBox runat="server" id="QueryBox" />
<asp:Button runat="server" ID="SearchButton" PostBackUrl="~/SearchResults.aspx" />

Two possibilities :

· SearchResults.aspx page does use a master page,

• SearchResults.aspx page does not use a master page,

In both cases we use the PreviousPage.Master to access the Master Page. And to access the control we can use the PreviousPage.Master.FindControl.

Master Pages and Themes

· Master pages, being just another control inside a page, do not have a separate theme applied. Master pages use the theme specified by the page that is using them.

· There is no direct method to specify a control skin so that the skin only applies to controls on the master page.

· To pull this trick off, we need to use the concept of skin IDs.

· There are two types of skins: default skins, and skins with a SkinID attribute. A default skin will apply to any control with the same type as the skin, but a skin with a SkinID will only apply to controls with the same type and SkinID.

Nesting Master Pages

All I need to highlight here is : Although nested master pages work at runtime, they do not work in the Visual Studio 2005 designer. If we try to open a content page in design view and the content page uses a nested master page design, the designer will display an error message.

Design view does not support creating or editing nested master pages. To create or edit nested master pages, use Source view.

This error is no more in ASP.Net 3.5. However, there is a trick to achieve this in ASP.Net 2.0 as well. The trick is : Assume we have a Master1 page and NestedMaster1 which uses Master1. Then we have a Page which used NestedMaster1.

<%@ Page Language="VB" MasterPageFile="~/NestedMaster1.master" %>
<asp:Content ID="Content1" ContentPlaceHolderID="NestedContent" Runat="Server">
</asp:Content>

If we attempt to view this content page in design view, Visual Studio will produce the error message shown earlier. If we really want to use the designer with our content page, the trick is to leave the MasterPageFile attribute empty, like in the following code:

<%@ Page Language="VB" MasterPageFile="" %>
<asp:Content ID="Content1" ContentPlaceHolderID="NestedContent" Runat="Server">
</asp:Content>

This code will enable to show the page in the designer mode. However At runtime, the page will throw an exception because it doesn't have a master file. Tp avoid the exception, programmatically set the MasterPageFile property at runtime.

public class BaseContentPage : Page
{
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);

PagesSection pagesConfig =
ConfigurationManager.GetSection("system.web/pages")
as PagesSection;

MasterPageFile = pagesConfig.MasterPageFile;
}
}

Hope this helps.

Arun Manglick