Why serious web developers can't use Master Pages

ASP.NET 2.0 is a wonderful leap forward from 1.1. Much has improved, and one exciting improvement is Master Pages.

Only Master Pages can't be used by serious web developers.

For today: serious web developers = web developers who wish to observe best coding practices, especially loose coupling and clean separation between layers.

The problem:
Master Pages use a little gremlin called INamingContainer to "help" you. It ensures that no id names on a given page will collide. It does this by kindly renaming your control ids. So if your control id is called "textbox1" - when you use it with master pages, it becomes "ctl00_ContentPlaceHolder1_TextBox1".

And I suppose in some situations, that might be helpful. But in all situations? Come on guys.

The solutions out there range from detecting what that that name is going to be, and dynamically generating your CSS or Javascript, to hard coding what the control will be into your js based on the predictable naming convention. These are completely unacceptable solutions.

The only real solution (short of writing your own control, which I'm pondering), is to skip using Master Pages all together. Which is a serious shame. They had such insanely cool promise.

*sigh*

For more info, read through some of the comments on this post by ScottGu (including our hero's silly suggested workaround) and this article (scroll down to "Name Mangling"). All the suggested solutions are preposterous.

Comments

[Scott]

I have issues with master pages, certainly. I think the script issue is more difficult to solve than the CSS one (using class names instead of IDs is easy).

The problem with script is that there is no one "solution" that will fit everyone's needs, but once you know what is happening and what other approaches are available it's relatively easy to use script in master pages.

[Carson McComas]

Hi Scott, thanks for stopping by. And kudos, actually on that excellent Master Pages article (and all the other superb stuff you do).

To your point - I agree, sort of.

It *is* certainly harder to manage this with javascript (which is my primary beef) than CSS. But any time I have to compromise how I do the front end, because of some locked-in quirk on the back-end it's unacceptable in my mind.

But this issue commits a great sin. In order to "solve" this problem I have to tightly couple my front end, with my backend. And that is the completely unacceptable part.

That said, I've spent several days coming up with a solution I haven't seen elsewhere which will in fact resolve this issue without the tight coupling. It's still a hack for sure - but it's not as big an deal as writing custom controls (although it's close) and once it's done, it's cleaner to work with. I'll be posting about that soon (after I do some more testing and polishing).

[Scott Allen]

Hi Carson: I look forward to reading about your solution. A new approach is surely welcomed.

[Azhar]

Another problem with Master Pages is that for every submit , the entire page gets rebuilt. If the design divides the Web Page into Navigation Menu section and Content section. Then we only want the content section to refresh based on the menu selection instead of the entire page getting rebuilt on the server side. You may be able to design better and faster solution using IFRAMES instead of Master Pages

[Chris]

Thank you! I thought I was the only person who felt like this! In a shop of developers and designers, master pages just hoses up the werks. So thus far, we're just not using them.

[Nate Tregillus]

I am going to have to disagree with you. the concept of master pages is suppose to go hand-in-hand with the concept of skinning, & themes. With this you just give your controls a skinID and in your skins and themes folders you keep your images, and "css-like" skin files. This is a good approach because you can dynamically change the look and feel of your page just by referencing a different theme. This way you can give more flexibility to your users. All an element needs is a skinID attribute to inherit, just like css requires a class attribute. You can also assign default skin values for controls, so you don’t need a skinID.

As for the Java script issues, you shouldn't be writing direct javascript. If there is client side code, you should try to modularize your forms that implement the javascript, and have the javascript implemented via the RegisterClientScriptBlock object. That way all of your code appears in your codes files, and you don't mix aspx html with functionality code, further defining the difference between look and functionality.

Trying to mix and match master pages with Iframes can become trouble some. It's either Master Pages with Skins & Themes or IFrames with CSS, its just not valid to mix both together.

Hope this further defines the issue.

Nate

[Carson McComas]

Hi Nate, aside from advocating The Microsoft Way (which is dangerously proprietary, but your right) your paragraph about javascript is both nonsensical and puzzling and completely misses (or certainly doesn't address or solve for) the point in my post.

[jgasm]

I concur. Master Pages for the loss!