I few days ago I made a post about the possible coupling I saw within master pages as compared to a dynamic control based parent. This is due to the child defining the container where it resides on the parent. Perhaps I was not clear enough of about my thoughts so I am going to try to explain them a bit further.
Using any form of dynamic control placement (master pages or parent loading and placing dynamic controls) one uses metadata in order to figure out how to layout the screen, in other words there is metadata defining that in screen x there are 4 controls and where each of the 4 controls should be placed. This metadata is where the coupling enters into play with master pages.
Master pages take the metadata associating the control with it's parent and place it into the child, that is the metadata associating the control to its parent and the control are bound together. This can be seen in looking at any basic master page as the child defines the container within its parent where it should be placed.
In a more classic parent-> child relationship the metadata needed by the parent to determine control placement is not bound to the child. In this methodology the child and the metadata live independently of each other, you can freely change the metadata without touching the controls or the controls without touching the metadata.
While this offers some great functionality (like being able to change out the parent and metadata while leaving the children oblivious to the change) it also has some questions which should be looked at.
Is the relationship between an html control host parent and a html control a relationship that should be strongly coupled? What are the advantages/disadvantages to strongly coupling this relationship.
The main advantage that I see is the fact that the master pages are an intrinsically simpler solution that is available to everyone. I might even go so far as to say that the master page concept could pass the “mother test” that is I could explain the concept to her and as she nods her head like she usually does when I drop into techno babble, she could also easily grasp the concept and could probably write a web page that uses it with under a week of training (she has never written a line of code in her life).
Another advantage may lie in the coupling between the controls and their containers. This is one of those things where the contrasting it to dynamic control placement really depends upon your actual implementation of control placement. Many times we create controls which are of different types, an example of this can be seen in a side bar advertisement control. If the dynamic control placement based system that we are comparing master pages to does not support the distinction between various control types then this coupling can actually be seen as an advantage for the master pages methodology. This is because although there is a coupling between the parent and the child that coupling also very specifically defines the control as being of the right type to be placed within the parent container.
Now before you get too excited about this, this is also a disadvantage. Scratching your head yet? Since the master page is coupled directly to the container it can not possibly be ona more generic level than a container. Lets propose a layout where there are 2 containers of the same size with interchangable content. The content would not be interchangable even though in reality they are. There is no way for me to define a type of container which would allow me to define that certain types of controls (i.e. ones that support a 200px x 300 px display) are valid within certain types of containers (say those that are 200px by 300px). If you have created a dynamic control system for a large scale system (or many small scale systems as the code is 100% reusable) you have most likely supported this type of operation.
I don't want people to misunderstand me and believe my thoughts to be negative on master pages. My thoughts are that they are a wonderful addition in 2.0 and will help countless developers. This is definately a case where the 80/20 rule applies and this is a feature that is targetted at the 80. I would say that their methodology is extremely simple and understandable while providing a good method of supporting templating. I believe that master pages have met every design requirement that they had during development. My arguement is that the design requirements do not have enterprise development in mind, they are geared towards the 80% who were not even using dynamic control placement prior to 2.0 many of whom don't even use code behinds.
If you are reading this and you are on an enterprise class development team take a serious look at this coupling before placing any of these items into your system. Many would say that the “try it out” approach is better, I can't disagree strongly enough. The process of refactorring your code away from master pages back to the well known dynamic control placement methodology is a nightmare, you will most likely be faced with a choice of either
- Keep it the way it is, leave it as a bastard child
- Pretty much rework the entire front end of your app
We all know the problems with option 1. Option 2 isn't a whole lot better. Better to just stay away while you can :)
Cheers,
Greg