Hi, I want the master page to have some dynamic data that will be displayed on all pages that use this master page. For example, I need to display links to latest blog posts on all pages. One obvious way is to pass that data in every acion's RenderView method but it's too repetitive. What is the recommeneded way to pass data to the master page? Please note that master and derived pages should recieve strongly typed data. Thanks!

I'm curious what the recommended method is as well.

For now I've created a "container" class that contains a property for the data needed by the specific view as well as properties for the data needed by the master page.  Then I created my own subclass of Controller and overrode the RenderView method to create this container and pass it along to the view.  That way the RenderView calls in the specific controllers still only concern themselves with passing data needed for that view.

I've also used this technique for passing data to User Controls, but I'm curious if there is a better/recommended way.

@scarpen That's a nice way to do it for the CTP. We're looking at ways to make it more natural, but for now, what you did is what I would recommend.

You could create a UserControl and a "Service" that does this. The "Service" (call it "StatsService" for instance) would get all the information you need to show, the UserControl would render it, and you could add that UserControl to the MasterPage.

 

scarpen:

Then I created my own subclass of Controller and overrode the RenderView method to create this container and pass it along to the view.

Does your RenderView override also know how to retrieve the data? That would feel alittle off.

Looking at the requirement, it seems pretty obvious that retrieving a list of recent blog posts is a seperate action from whatever action you are performing. (Especially true if you work with RESTful applications). One quick solution is to turn that into a seperate AJAX call. Drawback is the complexity of managing the AJAX behavior and the extra workload on the server. Might not be suitable for everyone. Another way I can see this being addressed down the road in the next CTP drop is through some type of post action filter that allows you to specify additional "complimentary" actions to your main action. (I don't know what would be the right term to use here). That way we don't violate SoC, SRP and all that goodness.

Now thinking about this, does RenderView actually spit out the html to the response stream when you call it or does it mark the view you are interested and delay the rendering to a later stage? That will effect what you can do in a post action filter.

robconery:

You could create a UserControl and a "Service" that does this. The "Service" (call it "StatsService" for instance) would get all the information you need to show, the UserControl would render it, and you could add that UserControl to the MasterPage.

 

Would providing that information be the UserControl's own function? I mean, would the UserControl access that "service" in it's codebehind or something?

scarpen:

I'm curious what the recommended method is as well.

For now I've created a "container" class that contains a property for the data needed by the specific view as well as properties for the data needed by the master page.  Then I created my own subclass of Controller and overrode the RenderView method to create this container and pass it along to the view.  That way the RenderView calls in the specific controllers still only concern themselves with passing data needed for that view.

I've also used this technique for passing data to User Controls, but I'm curious if there is a better/recommended way.

As I understand, container class has properties for all the views that controller's actions render. And specific actions fill out only  specific properties needed for the view, right?

uzmobile:

Would providing that information be the UserControl's own function? I mean, would the UserControl access that "service" in it's codebehind or something?

Yep - that's the idea. The service has the logic, the UI spins up the "view" of it. In Rails the UserControl would be called a "Partial" - a reusable bit of UI that you can put in various places.

robconery:

Yep - that's the idea. The service has the logic, the UI spins up the "view" of it. In Rails the UserControl would be called a "Partial" - a reusable bit of UI that you can put in various places.

if the usercontrol calls this service directly (bypassing a controller piece), aren't you breaking MVC? rails partials don't call the model directly if I'm not mistaken. like the usercontrols, they rely on the page to pass them data needed.

uzmobile:

As I understand, container class has properties for all the views that controller's actions render. And specific actions fill out only  specific properties needed for the view, right?

 

Kind of, but not really.  The container class is actually generic for the type of data the view needs.  I couldn't see how to post code snippets in the forums, so I wrote this quick post that shows my current solution: http://geekswithblogs.net/scarpenter/archive/2007/12/14/117724.aspx

shinakuma:

if the usercontrol calls this service directly (bypassing a controller piece), aren't you breaking MVC?

 

Yes and no. Yes in terms of the WebController concept - no in terms of a "ServiceController" concept. If you wanted to keep with the literal MVC here you could - you could have your control use something like Ajax or jQuery to call back to a "StatsController' and make a call to a List method that returns links. This is clean and nice - and works much the same way.

I readily break rules to do what makes sense - Gravatar is an example of this. If you have an app that uses Gravatar, it has to go out to an external service after hashing a user's email, so the process has to go through a code layer in your app. This doesn't fit the MVC pattern exactly - but I think (my opinion) that this is OK, The Service model and MVC can fit together nicely.

It's all up to you and what you think fits your scenario. The good thing is that there are ways to do it elegantly :). 

 Coming from Monorail they have a similar concept with their ViewComponents.  The component has a Initialize and Render method that can be overridden, so you can give your components/controls some logic

Two things strike me as a smelly: 

1) Code Behind.  I don't think there should be any, it will just get confusing and you will end with people doing some crazy stuff trying to mush webforms into mvc.

2) User Controllers.  Out of the box there is no IoC so the default factory will new them up with Activator.Createinstance... bad, bad, bad

So what would my solution be.

I would create a ViewComponent base class for handling all my setup.  It would probably just have an Initialize method taking ControllerContext.  All my presentation logic would go in there so it is testable.  all my domain logic would be done in services that get injected into the constructor of my ViewComponent.

I would have a base ViewComponentControl that simply used IoC to locate the correct ViewComponent class and Initialize it.  Now my UserControls just inherit from my ViewComponentControl, use the view like normal, and create a separate ViewComponent subclass to handle any setup, config, and presentation logic.

I would probably run fxcop rules to ensure my code behind files were empty.

Is in the Preview 2 a new way to passing data to master pages or is the only solution (for now) to use a special control?

What's wrong with ViewData?

(But see here if you want it strongly typed.) 

The problem with viewdata is, that i only use viewdata on view pages.

Each Controller has different Views (with there viewdata) - but the masterpage has no real "master-controller".

That means, each controller must pass the "master-viewdata" for the masterpage - this isn´t a great solution in my opionion.