Under My Hat

Tip: In ASP.NET a MasterPage is not a Page but a Control

Posted on 03 March 2010

It must be a few times a week that junior programmers ask me questions about master pages and how a Page and a MasterPage are blended together. They may ask why there is no Page_PreInit, Page_PreLoad or Page_SaveState event in the MasterPage. The facial expression of disbelief that I’m confronted with simply begs for being written about. Hopefully you already know that a MasterPage is not a Page or shares the same Page in its inheritance hierarchy. If you don’t, please read on.

Note: this is not a tutorial. I simply want to stipulate the importance of understanding what a MasterPage is.

MasterPage is a Control

More specifically, a MasterPage inherits from UserControl. A Page inherits from TemplateControl. A UserControl inherits from TemplateControl. In other words, the closest ancestor that they have in common is the TemplateControl.

A MasterPage cannot be cast to a Page. A Page cannot be cast to a MasterPage. Likewise, it is not trivial to convert a Page, including all events and elements, to a MasterPage. This process must be done by hand.

The life-cycle of a MasterPage is comparable to the life-cycle of a UserControl, however some special rules apply. A Page knows nothing of your homegrown user controls, but it is well aware of the existence of MasterPages. The property MasterPage is one sign of this. Another sign is that it treats the MasterPage differently: it loads them before any of the other controls have been loaded. Likewise, it calls the Render method of the MasterPage before it calls any render method of other user- and other controls on the Page.

MasterPage is not an IHttpHandler

Of even greater importance, and perhaps the cause of most confusion, is that a MasterPage does not implement IHttpHandler. ASP.NET is all about IHttpHandlers. It chains a file extension to a class that implements IHttpHandler. When a user requests a resource from a web browser, ASP.NET will look up the appropriate IHttpHandler belonging to that request. While the whole process is slightly more difficult than this, in a nutshell, that’s all there is to it (try to create your own handler for *.undermyhat files and all you need to do is implement IHttpHandler and the ProcessRequest method).

This means that a MasterPage cannot and will not be directly initialized or called by ASP.NET. This fits the previous section, where I explained that a MasterPage is a Control: most controls cannot sit on their own but need a “top level control”, in this case, a Page. The Page is created first, initialized (its ProcessRequest method is called), the PostBackMode is detemined, the scroll position is loaded, the PreInit event is called and the skins and stylesheets are applied. Only then it’s time for the MasterPage to be loaded. When the master pages are loaded (recursively, you can have multiple nested masterpages!) the Init event is (again recursively!) called, which will define the names of all renderable elements (i.e., it recursively loops through the naming containers, of which a MasterPage has one as well).

Many more events follow and books have been written on the subject, so I suffice it to say that a MasterPage is loaded as a control. A special control, yes, but still a control.

Conclusion

A MasterPage does not have the same event cycle as a Page. Instead, it behaves almost equally as a UserControl, with the only exception that it is loaded earlier by the Page (just after the PreInit and before the Init event).

To memorize: in a Page, the first event, PreInit, loads the Themes and Skins and then the MasterPages. The second event, Init, gives names to the elements, among other things.

 

Additional comments powered by BackType