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
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
etc...
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.
I don't know if this makes sense, but if ViewData was visible in ActionFilters we could just write a MasterPageFilter to initialize ViewData dictionary entries that will be used by the masterpage.
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
is rendered.
As evident by the above, I think it would be possible to do this in an MVC way, It just requests that we think about the concept of a master page/template differently.
The view can still dictate what template it wants to use it just requires that the controller (or the controller plumbing) to have the ability to ask the view what template it is using. Once this is determined the controller (or the controller plumbing) calls
the controller of the template, and so on. If the problem is attacked this way (which is conceptually a very different approach to the way that master pages work - or the approach that was suggested above) we can stay true to MVC, have our templates, have
nested templates, have reusable components, have dynamically selected templates, etc, etc.
I am still keen to see what the devs think... if anyone knows one...
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?
:: Never underestimate the predictability of stupidity ::
That was just an idea. ActionFilters are, at the moment, the closest thing to "code that can be executed for every request". Obviously a speficic brand new solution for MasterPages would be the best thing. Let's see what the MVC devs will come up to.
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
controllers, right?
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.
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
snidersh
Member
75 Points
29 Posts
Re: Master Pages and Dynamic Data??
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.
vdh_ant
0 Points
56 Posts
Re: Master Pages and Dynamic Data??
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.
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 05:49 AM|LINK
you pray the gods of djork that they will read and participate :)
DmitryRA
Member
18 Points
11 Posts
Re: Master Pages and Dynamic Data??
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
etc...
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?
Sgro
Participant
782 Points
352 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 08:02 AM|LINK
Web Developer
IWA Member
vdh_ant
0 Points
56 Posts
Re: Master Pages and Dynamic Data??
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.
As evident by the above, I think it would be possible to do this in an MVC way, It just requests that we think about the concept of a master page/template differently.
The view can still dictate what template it wants to use it just requires that the controller (or the controller plumbing) to have the ability to ask the view what template it is using. Once this is determined the controller (or the controller plumbing) calls the controller of the template, and so on. If the problem is attacked this way (which is conceptually a very different approach to the way that master pages work - or the approach that was suggested above) we can stay true to MVC, have our templates, have nested templates, have reusable components, have dynamically selected templates, etc, etc.
I am still keen to see what the devs think... if anyone knows one...
Cheers
Anthony
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
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?
Sgro
Participant
782 Points
352 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 01:47 PM|LINK
Web Developer
IWA Member
vdh_ant
0 Points
56 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 10:08 PM|LINK
Just bumping this as i am keen to see what people think...
Haacked
Contributor
6901 Points
412 Posts
Re: Master Pages and Dynamic Data??
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 controllers, right?
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.
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?