Master Pages The n Commandments

Introduction
Used properly the ASP.NET Master Page can be a useful and time saving mechanism, but there are some pitfalls which developers should be aware of and some common architectural mistakes which can render them more trouble than they are worth. Hopefully by reading this you can avoid some of the common (cough?*$ mistakes I already made) problems.

The n Commandments
The first mistake I made when using master pages was to look at them as a magic answer to the custom inherited page class many of us used in ASP.NET 1.1, when in actual fact the master page is essentially a solution to a work around that was commonly used back then i.e. stacking up user controls on a page to handle header, content and footer sections. The custom page class is still very much required and while you can get a Master Page to function like it, the heartache involved is simply not worth it. Simply put, the Master Page only acts like a Master when the page is initializing, after that it is essentially a user control and in this we find the cause of most problems. Trust me, keep your custom page class in your app_code directory where it should be and think of the MasterPage as a convenient way to uniformly style sites and to include other site wide tags like CSS and Javascript references.

The second mistake I made was trying to access Master Page properties from my user controls, while this can be done, it involves referencing the virtual path in the .ascx file then casting Page.Master to the referenced MasterPage.


.ascx
<%@ Reference VirtualPath="~/MyMasterPage.master" %>
.cs
MyMasterPage m = (MyMasterMaster) Page.Master;


The problem with this is, say for example you start adding a javascript reference from within your user control and then you realize you need to add a different javascript reference from within the page hosting the user control, then adding another reference to the master page in the host page will cause a circular reference. Simply put, it makes much more sense to make the master page clever enough to know what Javascript or CSS references to add. Things like the title tags can be accessed directly



Page.Title


Another easy mistake is in architectures which involve using multiple user controls on the page, which are shown or hidden depending on the function of that page. While this one is not necessarily isolated to master pages it is important in the context of web 2.0 desktop like web applications which magically have elements appear and disappear. Just because an element is not visible it does not at all mean that the code will not run, I worked on an application recently in which I managed to literally quadruple the speed in a matter of minutes by making sure the code in invisible user controls wasn’t running until actually required. The previous developer had presumed that code only runs if the control is visible (logical), the choice of logically breaking up functions into specific user controls was spot on however, this oversight caused the app to run like a snail on ketamine.

Conclusion
Hopefully these pointers will help you have a painless Master Page experience!

kick it on DotNetKicks.com