Control Panel Forum Hosting Help 6 Months free Hosting (New!) Resources

Total members: 80998
Average new registrations per day (in last 7 days): 41

New Registration: Open

Register Now

Home » Resources » Master Pages

ASP.NET	ADO.NET	Web Services	Remoting	Visual Studio 2005
Error Bank	Interview Questions	Tips & Tricks	XML	HTML
Jscript/Javascript	IIS	Windows		General

Submit Resource or code snippet ... and get surprise gifts ASP.NET web hosting

Win Digital camera, ASP.NET Books, Free softwares!!

Master Pages

30 Apr, 2008

Author: Amit Kumar

Summary
Tips, Tricks, and Traps

.NET Classes used :

Master pages are a great addition to the ASP.NET 2.0 feature set. Master pages help us build consistent and maintainable user interfaces. Master pages, however, are not without their quirks. Sometimes master page behavior is surprising, and indeed the very name master page can be a bit misleading.To make use of master pages, we first need to understand how master pages work.

For Internal Use Only

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. Let’s say we are using the following, simple master page.

<%@ Master Language="VB" %>



  Untitled Page

The master page contains some common elements, like a head tag. The most important server-side controls are the form tag (form1) and the ContentPlaceHolder (ContentPlaceHolder1). Let’s also write a simple web form to use our master page.

<%@ Page Language="C#" MasterPageFile="~/Master1.master" 
         AutoEventWireup="true" Title="Untitled Page"  %>
             ContentPlaceHolderID="ContentPlaceHolder1" >

The web form contains a single Content control, which in turn is the proud parent of a Label.At this point, the page and master page are two separate objects, each with their own children. When it comes time for the master page to do its job, the master page replaces the page’s children with itself.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 after the content page’s PreInit event, but before the content page’s Init event. During this brief slice of time, the master page is deserving of its name. The master page is in control - giving orders and rearranging controls. However, by the time the Init event fires the master page becomes just another child control inside the page. In fact, the MasterPage class derives from the UserControl class. I’ve found it useful to only think of master pages as masters during design time. When the application is executing, it’s better to think of the master page as just another child control.

The Pre_Init event we just mentioned is a key event to examine if we want to change the master page file programmatically.

Handling the PreInit Event

We can use the @ Page directive and the web.config to specify master page files for our web forms, but sometimes we want to set the master page programatically. A page’s MasterPageFile property sets the master page for the content page to use. If we try to set this property from the Load event, we will create an exception. In other words, the following code…

protected void Page_Load(object sender, EventArgs e)
{ 
  MasterPageFile = "~/foo";
}

… creates the following exception.
The 'MasterPageFile' property can only be set in or before the 'Page_PreInit' event.

This exception makes sense, because we know the master page has to rearrange the page’s control hierarchy before the Init event fires. The simple solution is to just use the PreInit event, but we probably don’t want to write the PreInit event handler over and over for each web form in our application. Chances are good the PreInit event handler will need to look up the master page name from a database, or a cookie, or from some user preference settings. We don’t want to duplicate this code in every webform. A better idea is to create a base class in a class library project, or in the App_Code directory.

using System;
using System.Web.UI;

public class BasePage : Page
{
   public BasePage()
   {
        this.PreInit += new EventHandler(BasePage_PreInit);
   }

    void BasePage_PreInit(object sender, EventArgs e)
    {
        MasterPageFile = "~/Master1.master";
    }
}

To use this base class, we need to change our code-beside file classes to inherit from BaseClass instead of System.Web.UI.Page. For web forms with inline code, we just need to change the Inherits attribute of the @ Page directive.

<%@ Page Language="C#" MasterPageFile="~/Master1.master" 
         AutoEventWireup="true" Title="Untitled Page" 
         Inherits="BasePage" %>

The inheritance approach is flexible. If a specific page doesn’t want it’s master page set, it can choose not to derive from BasePage. This is useful if different areas of an application use different master pages. However, there may be times when we want an application to enforce a specific master page. It could be the same type of scenario (we pull the master page name from a database), but we don’t want to depend on developers to derive from a specific base class (imagine a third party uploading content pages). In this scenario we can factor the PreInit code out of the base class and into an HttpModule.

HttpModules sit in the ASP.NET processing pipeline and can listen for events during the processing lifecycle. Modules are good solutions when the behavior you want to achieve is orthogonal to the page processing. For instance, authentication, authorization, session state, and profiles are all implemented as HttpModules by the ASP.NET runtime. You can plug-in and remove these modules to add or discard their functionality. Here is a module to set the MasterPageFile property on every Page object.

using System;
using System.Web;
using System.Web.UI;

public class MasterPageModule : IHttpModule
{   
    public void Init(HttpApplication context)
    {
        context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);
    }

    void context_PreRequestHandlerExecute(object sender, EventArgs e)
    {
        Page page = HttpContext.Current.CurrentHandler as Page;
        if (page != null)
        {
            page.PreInit +=new EventHandler(page_PreInit);
        }
    }

    void page_PreInit(object sender, EventArgs e)
    {
        Page page = sender as Page;
        if (page != null)
        {
            page.MasterPageFile = "~/Master1.master";
        }
    }

    public void Dispose()
    {
    }
}

When the module initializes, it hooks the PreRequestHandlerExecute event. The PreRequestHandlerExecute fires just before ASP.NET begins to execute a page. During the event handler, we first check to see if ASP.NET is going to execute a Page handler (this event will also fire for .asmx and .ashx files, which don’t have a MasterPageFile property). We hook the page’s PreInit event. During the PreInit event handler we set the MasterPageFile property. Again, the event handler might look up the filename from the database, or a cookie, or a session object, which is useful when you give a user different layouts to choose from.

To use the module, we just need to add an entry to the application’s web.config.

This is half of the tutorial. I will write the next in a few days.

Feedbacks about this page from members:

- No Feedbacks yet !! -

Submit Feedback View All Feedbacks