Master Page Coupling

<< Thread.Abort | Home | IE Dev Toolbar >>

Master Page Coupling

After having done now two applications using master pages they still feel very odd to me. In fact that feel very ... backwards.

I have been developing ASP.NET apps using dynamic control placement based templating for quite some time now (oddly enough I do my windows forms apps the same way). Its great, I have things such as a tab strip control which loads plugins, automatic menu creation, etc. In this model it is parent who is told to run the child, the parent then decides how and where to display the child. The child is completely oblivious of its relationship with its parent with the exception of an interface IControlHost which it uses to interact with its parent.

In master pages the exact opposite is true here is a quick example if you are not familiar shamelessly copy/pasted from a intro to master pages article.

   
<%@ page language="C#" master="~/Intro.master" %>
   <script runat="server">
     void Page_Load(object sender, 
       System.EventArgs e)
     {
       lblMessage.Text = "This content is 
         generated from the content page";
     }    
   </script>
   
   <asp:content id="Content1" contentplaceholderid="middleContent" runat="server">
      <asp:label runat="server" 
         id="lblMessage"></asp:label>  
   </asp:content>

<%@ master language="C#" %>
   <html>
   <head id="Head1" runat="server">
       <title>Master Page</title>
   </head>
   <body>
   <form id="Form1" runat="server">
      <table id="header" style="WIDTH: 100%; HEIGHT:
      80px" cellspacing="1" cellpadding="1" border="1">
       <tr>
         <td width="100%" style="TEXT-
           ALIGN: center">
          <asp:label runat="server" id="Header">
          This is the default header in the Master
          Page</asp:label>
         </td>
       </tr>
    </table>
    <b/>
     <table id="leftNav" style="WIDTH: 108px;
     HEIGHT: 100%" cellspacing="1" cellpadding="1"
     border="1">
       <tr>
          <td style="WIDTH: 100px"> Left
             Navigation
          </td>
       </tr>
     </table>
     <table id="mainBody" style="LEFT: 120px; VERTICAL-
     ALIGN: top; WIDTH: 848px; POSITION: absolute; TOP:
     94px; HEIGHT: 100%" border="1">
       <tr>
          <td width="100%"
            style="VERTICAL-ALIGN: top">
           <asp:contentplaceholder
             id="middleContent"
             runat="Server">
           </asp:contentplaceholder>
          </td>
       </tr>
      </table>
      </form>
   </body>
   </html>

The key is that the child is defining the content placement on the parent. This still offers alot of flexibility for changing interfaces etc and is by far the easier of the two solutions, but what happens if I have two seperate master pages which treat containers differently? The children are directly coupled to the containers on the parent, I can't do this. I end up with a weird hack of layering master pages in order to provide the behavior I need.

The master pages is definately more accessible to the average programmer, and is far better suited for the weekend warriors who create aspx based web pages (i.e. not even writing code behinds). But is this really a good methodology for enterprise level development?!

I am intrested in other's take on this.

Print posted @ Thursday, January 12, 2006 6:13 PM

Feedback

# re: Master Page Coupling

Hi Greg. This is Greg. :-)

I tend to think that Master pages is a great methodology for enterprise level development. I too have been using asp.net since the beginning of time and even though you get alot of flexibility dynamically controlling every placement, size, etc for a control, I still think that master pages will help 75% (maybe more) of those designing web applications. I have developed probably 100 or so applications in the last 4-5 years and haven't come across the need to have my content so dynamic like yours - not saying that isn't necessary, some apps need it, some don't. What I am trying to say is that not everyone's enterprise level application has all of the bells and whistles of plugins, menu creation (I've had this one), etc.

As far as consuming a child page that could possibly use 2 different master pages, if you make your child page content a user control, then create 2 child pages (one for each master page) that loads the control at runtime. This may be the hack you did but in my view, it doesn't get easier than this (or maybe it does). (If this is what you are referring to.)

Anyway, thats my .02.
Greg 1/13/2006 5:38 AM | Greg

# re: Master Page Coupling

Hi Greg. I'm Greg.

Let's look at master pages in a slightly different way. Lets look at master pages in the guise of an inheritance chain (as that is essentially what they are doing). Let's propose that the containers are abstract methods and that the deriving content pages are defining those methods.

Anyone who has dealt with large inheritance chains knows that changing the contract of the super class is quite a dangerous undertaking as you can have changes ripple through the inheritance chain breaking numerous things.

This is very similar to what I am discussing. Take two master pages that need to define content in different ways ex: the same content simply needs to be put in different containers. Since the content is doing roughly the equivalent of defining that it is overriding the content block to put itself in what happens here?

"As far as consuming a child page that could possibly use 2 different master pages, if you make your child page content a user control, then create 2 child pages (one for each master page) that loads the control at runtime. This may be the hack you did but in my view, it doesn't get easier than this (or maybe it does). (If this is what you are referring to.) "

You are right you end up creating two child page hosts for your control. What happens when you need a third? You create a third.

This may seem like a fairly trivial task but what if you are dealing with a large scale system (say 1000 controls). Let's presume 500 of these controls need to change the way that they are operating with the container due to a master page change ... Although your answer is simple, it will require 500 child pages to be created and maintained, you will also have different links for all of these duplicated sub pages that need to be called but I will assume a standardized method was used to generate links from the beginning so this change only effects a single place (the link generation routine or your LinkFactory) without this you would simply be up a creek as you would also have to find every instance calling the links and change them to point to the new page hosts. This is a perfect example of the coupling involved as the change has rippled through the inheritance chain, although the changes were simple they had to be done many times.

With a non-coupled method such as dynamic control placement where the parent is defining where it places the child and the child is oblivious of its parent, there would be no additional code added to make such a change, only the parent would need to be replaced.

I agree 100% that the master page concept will help 75% of .NET developers, especially those who were hard coding headers etc and not using controls for this type of behavior. What I am unsure of is how well this will scale to large applications. You said in your post that you have developed 100 or so applications, these all must be pretty small scale applications (lets presume 5 years with .NET) = 260 working days per year * 5 years = 1300. Divide this by the number of systems and you end up with 13 days per system on average. Naturally this is assuming that you were working at a constant rate without learning curve etc.

I would generally not classify such systems as "Enterprise" systems. This may be a breakdown in terminologies. My worry is not for systems that have 20 controls, my worry is for systems that dynamically may deal with 2000 spread dynamically through multiple control hosts. In the example of 20, I will even go out on a limb and say 50 controls, the overhead incurred by a sweeping inheritance chain can be overcome by some good ole fashion hard work. As you get to these larger systems it becomes a nightmare, especially on the linking problem as the linking is often exponential in relation to system growth.

What I actually ended up doing was making sub pages which could dynamically load controls into their containers (not very many of them) but I feel like I am missing something, my old way seemed to be more scalable and I seem to be shoehorning my old way into master pages ... which leads me to the question, why not just drop the master pages and just use dynamic control placement as I seem to have added a level of complexity to my code without any gain.

Hope this clears my thoughts up.

Greg 1/13/2006 8:03 AM | Greg Young

# re: Master Page Coupling

Well, I guess if you have a project that requires 1000 controls, good for you. Yes, most of my applications have been small compared to that however my definition of small/big is different from yours, or hers, or theirs...

I am always eagar to see how other individuals handle large scale projects but everytime I see what they have done, I get lost in the functionality because A inherits from B which contains C which inherits from F which actually contains B and C...you get my point. All but one time have I seen code that was designed properly and made sense. I have also seen it where people thought they were doing the right thing but in the end, was really overkill.

If you could, please send me a sample of how you are doing this with say 3-5 controls just so I understand this concept. If you can't, I understand. Maybe post a few code examples so that I can see what the idea is.

Thanks,
Greg 1/13/2006 11:17 AM | Greg

# re: Master Page Coupling

There are a few statements here which worry me.

I get lost in the functionality because A inherits from B which contains C which inherits from F which actually contains B and C...you get my point. All but one time have I seen code that was designed properly and made sense. I have also seen it where people thought they were doing the right thing but in the end, was really overkill.

When properly designing a system you _SHOULD_ have lots of "A inherits from B which contains C which inherits from F which actually contains B". Whether or not the people whos systems you looked at did it properly is another story but the verbage you use contains the keys to an object oriented system _indirection_ and encapsulation.

I will see what I can do about getting some terse examples up here. One terse example you could look through is a quick discussion on my unit of work pattern that I put up here. I may be placing that code into a well known ORM which would allow you the chance to look through it as well.

Cheers,

Greg 1/20/2006 10:23 AM | Greg Young

Greg Young