Master Pages and Dynamic Data??

Hi guys
I have been looking into MVC over the last couple of weeks and I think its great. The model for implementation that MS has put forward seems really slick.

I do have a couple of questions though that havent seemed to be answered. The main question that i have at the moment surrounds master pages.

If i have a master page that is used on every page of my site and it has a menu that is dynamically contracted based on data retrieved from the DB, how does MVC deal with this? In that, I know that the control/action is responsible for getting all the data from the model and passing it to the view but this then means that in this case every controller and action within application will need to know to retrieve this data. This may not be too bad at first (no let me rephrase that it is bad...), but what happens if i wanted a news ticker in the master page as well, again populated with data from the DB. From what I know and have read so far, I would need to go to every controller and every action and put in the logic to get this data from the model. This doesn't seem like a very good approach, so I must be missing something here.

Cheers
Anthony

Re: Master Pages and Dynamic Data??

Anthony, I too have struggled with clean code + master pages. I think i read somewhere that masterpages can have their own controller (??!!) but right now, i have to have an abstract controller and all my controllers impliment it. the abstract controller does the 'master page stuff'.

Personally, I think it's (my solution) is poor and lame. That said, i don't have a solution or any better idea's to post, here. I'm not sure what Ruby on Rails does, or anyone else.

Haack -> I would love it, if you could enter this thread and discuss some things we should be doing with Master pages + dynamic data. Suggestions / road maps, etc. Even something as simple as 'we're looking at refactoring the way master pages handle dynamic data BEFORE we MVC goes RTM', so then we can sit back and wait for the refresh-build / blog posts .. or .. if that wasn't going to happen, then seriously chat with yourself and other devs to come up with a viable solution we can all use and promote.

I personally feel that Master Pages and ReUsable mvc controls have been given little love so far and are a critical component in the success of MVC (even though it soooo kicks web forms ass, IMO, right now in it's current beta form :P )

/me sacrifices RAM to the djork gods to get Haack into this conversation :)

Re: Master Pages and Dynamic Data??

To make such global data in each controller(from inherence) and drag it to a master page through the View - really doesn't look good...

One implies that controllers receive some data from users, manage it and generate appropriate responses (with selecting ViewPages=MasterPages). But in Your example the "news ticker" concerns only a master page and it doesn't implement any logic of managing user data or response, so logically nothing stops you from placing a populate code inside your MasterPage. For example you can create some function inside MasterPage's code behind:

public string GetNewsTicker()
{
    //Code that anyhow populates the "news ticker"
}

and place it
<%= GetNewsTicker() %>

Or you can make UserControl to do this more flexible way and place this control inside MasterPage.

Another thing in this approach is a model lifecycle, and a model logic. It is interesting for me, how to implement it better.

Re: Master Pages and Dynamic Data??

@ DmitryRA: true that you can put code in the code-behind of the master page. Personally, i look at this as WEB FORMS programming model, not MVC. Therefore, mixing WEB FORMS with MVC == no no, for me personally. As such, i'm trying to remove myself COMPLETLY from any code behind in any view pages.

As such, it would be every kewler if the MVC team can make it so that we don't even need to create the code behind file! if we could declare what the view 'inherits' in the markup on the html page ... i would be stoked. The view is just that -- UI representation. As such, IMO, the view should only be one page .. the html (or NHaml, Sparkle, insert your fav view engine page type here).

Re: Master Pages and Dynamic Data??

You can do that. My site in progress doesn't have a single code-behind file anywhere. The only trick is that you have to use the CLR generics form for your inherits declaration. Note the `1[[ ]] and that you have to specify the name of the compiled DLL as well. Which also means you don't see intellisense until after you build the project once, but after that it's there.

inherits="System.Web.Mvc.ViewPage`1[[MySite.Web.Models.MyViewData, MySite.Web]]"

As for the topic of the thread, I agree we need a better solution. I don't like the idea of a base controller that has methods on it to generate view components, so I am currently using either jquery to do non-important updates or calling a helper method on =Html to output something as the view is built, and there's also the new RenderAction as well. As has been pointed out, it doesn't really feel quite right though to have the View calling back to the controller to ask for more view. However, this might end up being a bit of 'non-MVC-ness' that we might just have to put up with because having encapsulated logic like that it pretty much necessary in any real-world application.

Re: Master Pages and Dynamic Data??

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 way round.

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.

Cheers
Anthony

Re: Master Pages and Dynamic Data??

snidersh

You can do that. My site in progress doesn't have a single code-behind file anywhere. The only trick is that you have to use the CLR generics form for your inherits declaration. Note the `1[[ ]] and that you have to specify the name of the compiled DLL as well. Which also means you don't see intellisense until after you build the project once, but after that it's there.
inherits="System.Web.Mvc.ViewPage`1[[MySite.Web.Models.MyViewData, MySite.Web]]"

Holy Molly! i never new you could do that! zomg, this is awesome-sauce!

Question: How do u find the exact string for the dll? eg. the '1[[ ]] stuff?

@ vdh_ant: yep .. totally agreed that we need to have a better solution for master pages and component controllers. +1 dude.

Would love to hear what the ASP.NET MVC devs are thinking.....

/me makes more RAM sacrifices the god of djork.

Re: Master Pages and Dynamic Data??

You have to use the full namespaces, and the dll is just the dll that your project outputs where you have your viewdata. So, let's keep it simple and say you have a project with namespace MySite and inside that is a class called MyViewData, and the output of the project is MySite.dll, the code is System.Web.Mvc.ViewPage`1[[MySite.MyViewData, MySite]]. It's ugly, that's for sure, but it's nice not to have all those little .cs stub files that are just defining your inheritance and nothing else. My view folders contain nothing but aspx pages (and master pages). Besides, you define it once at the top of each aspx page and forget about it... it can be as ugly as it wants sitting up there.

Re: Master Pages and Dynamic Data??

pure.krome
Would love to hear what the ASP.NET MVC devs are thinking.....

Agreed... now how do we get them to read this...

Re: Master Pages and Dynamic Data??

ok - that makes sence.

Some questions still (and appologies for getting slightly off-topic)...

1. why do you have a `1 in one of your examples, but not in the one above?
2. What if u want to have your ViewPage have a strong type. eg (if this was in the code behind)

namespace MySite.MyMVCApp
{
    public partial class MyViewPage : ViewPage<MyFooClass>
    {
        ....
    }
}

cheers :)

Re: Master Pages and Dynamic Data??

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.

Re: Master Pages and Dynamic Data??

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.

Re: Master Pages and Dynamic Data??

you pray the gods of djork that they will read and participate :)

Re: Master Pages and Dynamic Data??

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?

Re: Master Pages and Dynamic Data??

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.

Re: Master Pages and Dynamic Data??

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...

Cheers
Anthony

Re: Master Pages and Dynamic Data??

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?

Re: Master Pages and Dynamic Data??

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.

Re: Master Pages and Dynamic Data??

Just bumping this as i am keen to see what people think...

Re: Master Pages and Dynamic Data??

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.