The more I think about this, the less sense it makes. These concepts are all very muddy and open to interpretation.
Ok, so here's an interesting question: In a pure MVC ideal, *all* data bits that the View will need are supplied by the Controller before passing control to the View. Once control is passed, you should, in theory, be able to completely disconnect the Controller
and Model from the application and the View will happily render. So, aren't you breaking that model every time you call Html.ActionLink? A url is just a text data bit, and you're letting the View ask for that data bit. You can say, the HtmlHelper lives
in the View-space, but it still is calling back to the engine asking to create a url based on the routing rules, and if it didn't callback that would be worse because the View would be generating data. Seems like, in a pure MVC ideal, you should be constructing
those urls in the Controller before packaging it and sending it off to the View. But again, that's completely impractical.
You can say that a url isn't the same as asking RenderAction to return a whole slew of data, but it's breaking the ideal either way. Drawing a line to say 'this much breaking is ok' and 'this much is bad' is completely arbitrary. And that's not even getting
into how much you break the model everytime you use AJAX to inject pieces of a View without user interaction.
I think I'm going to start the Save RenderAction Even Though Haack Doesn't Like It Campaign Fund. :)
Hello again. well, I'd say no, but as you correctly say, it's all a matter or interpretation. I think that getting the link info isn't really an interaction with the controller, though I admit that some do view it like that. Again, in an ideal world you would
have a lot of problems that exist in our real world, right?
--
Regards,
Luis Abreu
email: labreu_at_gmail.com
EN blog:http://msmvps.com/blogs/luisabreu
I use a BaseViewData class for masterpages and a class that inherits from that for each page. I then just use a helper method to populate the BaseViewData when I initialize the view data in each action. Is there anything wrong with this approach?
BaseViewData:
public class BaseViewData {
public IList<Categories> TopCategories { get; set; }
}
ProductViewData:
public class ProductViewData : BaseViewData { public Product Product { get; set; } }
Site.Master.cs:
public partial class Site : ViewMasterPage<BaseViewData> {
Product.aspx.cs:
public partial class Product : ViewPage<ProductViewData> {
I think that's a one good approach that a lot of people will use. It's very MVC zen. I personally don't like the InitBaseViewData() in every action, and I think it could get pretty complicated as you start adding case scenarios in your BaseViewData, but
the logic here is defined well in the MVC pattern I think and it is pretty easy to follow the logic train of thought to find where the values are being set. BaseController, BaseViewData, BaseAction, ActionFilter, and just plain setting the values in each
Action method... those all are very MVC ways of doing this. You're packaging the values before you send it off to the view, so nothing wrong with that per se in my opinion, I just think it could become unmanageable as you start to create different parts of
your site. You may end up needing multiple BaseViewDatas for specific purposes.
The concept of ActionFilters is: do some commonn stuff for every controller/method that implements it. So having common ViewData entries seems a perfect match for ActionFilters to me. If that data will be used in masterpages, it's a view concern only.
The only problem right now is that the ViewData isn't accessible from the filterContext so I don't really know how to implement it.
I think Phil answered this?
Phil Haack
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.
:: Never underestimate the predictability of stupidity ::
I agree as I am not yet convinced that filtering will work in all situation (i.e. nested master pages, dynamically changing view from within the controller, dynamically changing the master page from within the view, dynamically changing a master pages parent
master from within a master page, etc, etc), maybe i just don't know enough about filters yet but they seem too static to be able to handle a variety of situations well (again this may be my misunderstanding)...
I personally don't like the InitBaseViewData() in every action
I guess if the logic in InitBaseViewData was truly common to all controllers (for example checking if a user is logged in etc.) it could be performed in the default constructor of BaseViewData.
snidersh
Member
75 Points
29 Posts
Re: Master Pages and Dynamic Data??
Jul 25, 2008 06:27 PM|LINK
The more I think about this, the less sense it makes. These concepts are all very muddy and open to interpretation.
Ok, so here's an interesting question: In a pure MVC ideal, *all* data bits that the View will need are supplied by the Controller before passing control to the View. Once control is passed, you should, in theory, be able to completely disconnect the Controller and Model from the application and the View will happily render. So, aren't you breaking that model every time you call Html.ActionLink? A url is just a text data bit, and you're letting the View ask for that data bit. You can say, the HtmlHelper lives in the View-space, but it still is calling back to the engine asking to create a url based on the routing rules, and if it didn't callback that would be worse because the View would be generating data. Seems like, in a pure MVC ideal, you should be constructing those urls in the Controller before packaging it and sending it off to the View. But again, that's completely impractical.
You can say that a url isn't the same as asking RenderAction to return a whole slew of data, but it's breaking the ideal either way. Drawing a line to say 'this much breaking is ok' and 'this much is bad' is completely arbitrary. And that's not even getting into how much you break the model everytime you use AJAX to inject pieces of a View without user interaction.
I think I'm going to start the Save RenderAction Even Though Haack Doesn't Like It Campaign Fund. :)
Luis Abreu
All-Star
25674 Points
5369 Posts
MVP
Re: Master Pages and Dynamic Data??
Jul 25, 2008 10:19 PM|LINK
Regards,
Luis Abreu
email: labreu_at_gmail.com
EN blog:http://msmvps.com/blogs/luisabreu
JontyMC
Member
394 Points
144 Posts
Re: Master Pages and Dynamic Data??
Jul 26, 2008 02:03 AM|LINK
I use a BaseViewData class for masterpages and a class that inherits from that for each page. I then just use a helper method to populate the BaseViewData when I initialize the view data in each action. Is there anything wrong with this approach?
BaseViewData:
public class BaseViewData { public IList<Categories> TopCategories { get; set; } }snidersh
Member
75 Points
29 Posts
Re: Master Pages and Dynamic Data??
Jul 26, 2008 03:01 AM|LINK
I think that's a one good approach that a lot of people will use. It's very MVC zen. I personally don't like the InitBaseViewData() in every action, and I think it could get pretty complicated as you start adding case scenarios in your BaseViewData, but the logic here is defined well in the MVC pattern I think and it is pretty easy to follow the logic train of thought to find where the values are being set. BaseController, BaseViewData, BaseAction, ActionFilter, and just plain setting the values in each Action method... those all are very MVC ways of doing this. You're packaging the values before you send it off to the view, so nothing wrong with that per se in my opinion, I just think it could become unmanageable as you start to create different parts of your site. You may end up needing multiple BaseViewDatas for specific purposes.
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
Jul 26, 2008 04:56 AM|LINK
I think Phil answered this?
Sgro
Participant
782 Points
352 Posts
Re: Master Pages and Dynamic Data??
Jul 26, 2008 04:41 PM|LINK
A couple of lines of code, an example, would be better :)
Web Developer
IWA Member
vdh_ant
0 Points
56 Posts
Re: Master Pages and Dynamic Data??
Jul 26, 2008 11:53 PM|LINK
I agree as I am not yet convinced that filtering will work in all situation (i.e. nested master pages, dynamically changing view from within the controller, dynamically changing the master page from within the view, dynamically changing a master pages parent master from within a master page, etc, etc), maybe i just don't know enough about filters yet but they seem too static to be able to handle a variety of situations well (again this may be my misunderstanding)...
rweaver
Member
2 Points
1 Post
Re: Master Pages and Dynamic Data??
Jul 31, 2008 09:07 AM|LINK
I guess if the logic in InitBaseViewData was truly common to all controllers (for example checking if a user is logged in etc.) it could be performed in the default constructor of BaseViewData.