Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy


Add to Technorati Favorites Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

A master page is not a singleton

Here's a misconception I see a lot on the forums lately. There is this idea that controls on a master page should always keep their state across content pages that use it.
When you navigate away from a page (i.e. when you click a link), you go to another page, with another instance of the controls on it, so of course the new controls on the new page have no way of knowing about the state of the controls on the other page.
Having a master page does *not* mean that all the controls on the master page have a unique instance that would be shared by all pages that use this master page. The master page is nothing more than a template, it's not any kind of singleton.
So the only way you can maintain the state across different pages (whether you use a master or not) is by storing it in Session and using that information when a new page is loaded. This can have severe performance drawbacks as you store state for each user but is more or less what WebParts do with their personalization data...
Another approach is to consider that if you need to maintain state across all those pages, maybe they are the same and you need to move from a many-page model to a single-page model.
Please note that the navigation controls (a.k.a. Menu, TreeView, SiteMapPath) will automatically select the current node in the site map according to the URL you're on, giving a minimum version of this application-level state management some were expecting from master pages.

Comments

Ron Shelton said:

Agreed.

I have also had arguments with people about whether a master page (from which individual pages are derived) is an implementation of "Page Controller" or "Front Controller". I argue that it is a "Front Controller" since the derived pages act as concrete handlers of the request, but others argue "Page Controller" because the main view-decision code is centralized.

What do you think?
# November 9, 2005 9:11 AM

Bertrand Le Roy said:

That's a very interesting question. I think individual pages, as well as content pages, *can* implement a Page Controllers, and Master Page *can* implement a front controller.
Now, I think it's really a choice that you make as an application developer to use the tools that ASP.NET are providing (and that are more or less close by their design to formal design patterns) to implement patterns.
Personally, I'm advocating a model where the page itself has almost no logic and where the logic is in smaller parts. In this model, the controller is something that is on the page but it is not the page (think WebPartManager for an example).
# November 9, 2005 2:59 PM

Danny Chen said:

Thanks for posting this. I'm going to start pointing all the forum Q's we get to this post. Maybe people will start picking up on this.
--
Danny
# November 10, 2005 1:42 PM

Patrick Allmond said:

So is there a pro/con list or another thread discussing one approach vs another? i.e. Using the fancy shmancy new master page vs the classic "index.aspx?functionname=" approach? I am working on a new application and I was leaning towards master pages. But I am finding I am missing the functionality and some of the state maintenance of the "index.aspx?function=" approach.
# November 30, 2005 5:15 PM

Bertrand Le Roy said:

Patrick: they are two different things and do not exclude each other. Master pages are meant to provide a simple way to create templated pages and share common layout and/or logic between pages. The command in querystring approach is more suited to implement application logic and flow within one page. You can use both together or one or the other as you see fit. You can also use session when you need to maintain state across pages.
If you tell me more about your precise scenario, I can comment on it and tell you how I would do it (which would by no means be the "correct" way to do it, just my opinion).
# November 30, 2005 5:33 PM