Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Jul 31, 2008 09:07 AM by rweaver
Jul 22, 2008 04:21 AM|LINK
I want the devs to come in on the original question, so I don't want to hijack this thread. I'll post the answer in a new thread.
Jul 22, 2008 05:14 AM|LINK
Thanks I want the Devs to come in on this to... Maybe the other posts can be editied out if a new thread is being created for it??
Now how do we get the devs to take a look at this.
Jul 22, 2008 05:49 AM|LINK
you pray the gods of djork that they will read and participate :)
Jul 22, 2008 07:54 AM|LINK
Almost in any web development one needs a page template (lets call it so) and MasterPages do this good. But we apply WebPages to them independently from controller (and in many cases it is good too). So we have movement something like
model -> controller -> response - > View Page -> Master Page
In this talks one wants (actually) to pass some (separated from current controller action) model part to master page. We could have:
model-> superController (prepares data for MasterPage) -> controller -> response - > View Page -> Master Page
But for example we have 3 MasterPages and each of them needs to populate a different thing depending on a model. From the super controller one cannot decide even what ViewPage would it be to prepare the data. So there becomes one of :
model ->controller ->response - >ViewPage -> MasterPage_1 <-> RenderAction() <- someController.Action_1() <- model
model ->controller ->response - >ViewPage -> MasterPage_1 <-> CustomHelper_1 or MVCUserControl_1 <- model
model ->controller ->response - >ViewPage -> MasterPage_1 <-> MasterPage_1.PopulateFunction() <- model
many things - one name: we call something from MasterPage and this "something" makes operations with model ( i've meant this in my previous post). This is "a little non-MVC-ness" - true. We can avoid it if we refuse the MasterPage engine. But MasterPages
are too helpfull to refuse them. On the other hand we can try to decide in superController what the MasterPage would it be. In my opinion it is more complex and unclear.
Some other think?
Jul 22, 2008 08:02 AM|LINK
Jul 22, 2008 08:34 AM|LINK
Thanks for the for the response and i know what you mean but i dont think you see where i am coming from.
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
Jul 22, 2008 01:27 PM|LINK
Interesting concept Sgro .... very interesting. Still, this means we have to decorate all the controllers still, which might be an overkill if the master pages logic could be encapsulated somewhere better. maybe?
Jul 22, 2008 01:47 PM|LINK
Jul 22, 2008 10:08 PM|LINK
Just bumping this as i am keen to see what people think...
Jul 23, 2008 04:56 PM|LINK
The way I see it (and I'm keeping an open mind), the controller should know what data the view needs, but it shouldn't know anything about the layout of the view. That's a view concern which should be totally separated from the controller.
For example, suppose I start off not using masterpages at all and I build out a site with 10 actions and views and deploy that. Later, I decide I want to change my site to have 3 columns instead of two columns. I shouldn't have to change and recompile my
Now suppose I decide to refactor common layout information into a set of user controls and a masterpage. I should be able to do that in complete separation from my controllers, right? It would be odd if making stylistic changes to my view required me to
change my backend. That would violate separation of concerns that is the hallmark of the MVC architecture.
So in determining the solution to this problem, I try to forget about master pages and think of it as a problem of how do you pass common data to multiple views without every action needing to package up that data?
Right now, action filters are a good approach for that. Individual filters can store their own ViewDataDictionary within the ViewDataDictionary.SubDataItems dictionary using a key specific to that filter. The point of that dictionary is to provide a place
for subcomponents to put their own view data in isolation from the main viewdata.