Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Jul 22, 2008 03:12 AM|LINK
I agree... even if there is nothing stopping you from doing this it is going back to the Web Forms approach to the problem and not an MVC approach.
I would almost go as far as to say Master Pages in their current form CAN NOT work in an MVC model. The abstraction that they bring to the table is just wrong in the MVC environment. I think that an alternative is needed.
I think what is needed is something like the following:
When the view is called from within a control class, the RenderView method (or maybe by an event or a listener pattern of some sort), looks at the view that has been requested to be rendered and sees what page wrapper (i.e. master page) is being used. At this
point we are still within the controller 'layer' and the controller for the master page is called. This in turn, when the render view method is called, looks and sees what page wrapper (i.e. master page) is being use (thus supporting master pages). Then once
the parent master page is reached, the render view cascades down, rendering each master page until the actual page is reached and rendered. Now i know in reality the scenarios that Master Pages allows for are complex (i.e. runtime swapping of master pages)
but i think this logic can still be managed. In that, the controller an dynamically change which page wrapper (i.e. master page) is being used, the same way the controller can dynamically choose which view is rendered.
I think something really needs to be done here and ComponentController (http://code-inside.de/blog-in/2008/04/15/aspnet-mvc-display-dynamic-data-on-master-pages/) is not the answer as you have the view calling the controller. The logic needs to be the other
I know we are dead keen to use MVC for our projects, but if a better solution is found for page wrappers (i.e. master pages), I don't see how we can use it.