locked
CALL TO ACTION: Master pages need some love RRS feed

  • Question

  • User-785853015 posted

    Hi guys
    I dont know about the rest of you (I guess this is why i writing this post) but the more and more I use MVC the more I feel master pages/templates need some real love dedicated to them before the framework goes live. I think the framework is great... but this is the one place were things go flat... imho

    SO this is a call to action... the voices of the masses must be heard and judging from posts like this http://weblogs.asp.net/stephenwalther/archive/2008/08/12/asp-net-mvc-tip-31-passing-data-to-master-pages-and-user-controls.aspx and http://forums.asp.net/t/1293325.aspx I am not alone.

    I am convinced that we can make a difference and get things changed. Microsoft says that they are listening to what people have to say so lets see what we can do.

    Cheers
    Anthony

    Friday, August 22, 2008 9:30 AM

All replies

  • User-2004887772 posted

    MVC is intended to be a community-involvemnet project via the MVC Contrib.  Don't "call to action", and ask MS to fix something, just write up a proposal of what you'd like and submit it...

    Saturday, August 23, 2008 6:17 AM
  • User-1876899917 posted

    @Paul, I don't think it's really fair to describe ASP.NET MVC  as a "community involvement" project. It isn't open source (well, you can read the source, but you can't contribute to it). Remember that MVC Contrib is an unofficial project run outside Microsoft and not everyone, certainly not every company, is going to want to use it. There are plenty of good reasons to hope for the real ASP.NET MVC framework to meet your requirements and not have to find solutions in unofficial third-party code.

    @vdh_ant, how would you like master pages to work better? As I've been building apps with ASP.NET MVC, I was quite happy with how master pages work. I'm not sure why people are troubled about it (the pages you link to both make things seem more complicated than they need to be) - have you tried using Html.RenderAction() to put "controls" into master pages, or populating ViewData from an action filter? Either technique works nicely in the scenarios I was in. What specifically isn't working right for you?

    Saturday, August 23, 2008 8:34 AM
  • User-785853015 posted
    Hi Steve thanks for your reply.

    First off I agree with your comments about Pauls post and your constructive post. I think an ultimate solution needs to be found in the real framework and that just because something is open source doesn't make it a community project. Even if I did program a 'solution' for this, I really doubt that the MVC team would pick it up and use it. Hence why I am trying to get a discussion over this.

    Overall the problem I have is that there doesn't seem to be a well defined recommended way of dealing with this problem. What I mean by this is that Phil Haack says that action filters should be used, others say sub classing should be used and yet others say renderaction should be used. Now, I am not saying that there should be 1 way of solving a problem. But in this case it I really think there is a lot of confusion and I think it is over the fact that a good solution hasn't been found for this problem. In my view, all 3 of these solutions (in regards to master pages) have come about by people realising that master pages are an issue, not really thinking about the problem and just reacting. Currently the reaction says use something that currently exists and try bend it until it kinda works.

    In terms of why I don’t like these solutions are as follows:

    Filter - Now my in depth knowledge of filters is not 100% but to me filters seem a bit static. Meaning that what happens in scenarios where you have master pages which are dynamic determined, which are actually nested master pages where it’s master page is dynamically determined. Even though you can tell the view what direct master page it should use, there doesn't seem to be a way of telling that master page what parent master it should use. Also there this "Unfortunately, and this is a big unfortunately, this solution is not very testable. The action filters don’t get executed when you call action methods within a unit test." Part of the reason to change to MVC is for the testability.

    Sub Classing - To me this seems even more static that filters. Once you have a controller that inherits from a parent, there is no dynamically changing the master page of a controller at runtime (unless you can dynamically change what a class inherits from at run time...)

    RenderAction - Firstly there seems to be questions over whether this will even be in the first release of the framework, as from what I can tell it currently seems to be in 'Futures'. But besides this even if it is in the main framework I really don’t like the fact that we have a controller calling a view which calls a controller which passes data back to the view. Now I am not one of these MVC die hards who says that implementation has to be 100% pure. But in this case I think we are going just a bit to ofar over the line of what would be considered a good compromise. Like I know people say when you use ajax its not MVC anymore but I believe this is different.

    In any case this pro's a con's of these approaches is summed up much better than I can here (http://weblogs.asp.net/stephenwalther/archive/2008/08/12/asp-net-mvc-tip-31-passing-data-to-master-pages-and-user-controls.aspx - make sure you read the comments), I would really encourage people to take a look at this. Although I have added my 2 dollars wrother here about the dynamic aspects of master pages.

    My proposed solution (as discussed here http://forums.asp.net/t/1293325.aspx) would be as follows. When the view method is called the framework looks at the view that it is going to run and asks the view for the details of the master page that it is going to use in the current context. It then invokes the controller for the master page (before running any views). It then repeats this process until all nested master pages controllers have been run. At this stage all the controllers for all the master pages that are going to be needed for this view have been run and all data prepared. The view can then be executed and the view can put out the data that has been prepared as needed. This allows for the dynamic selection of views, the only data that is prepared is the data that is required (meaning that you aren’t preparing data that isn’t needed which is possible with the filter option), you are sticking with the MVC model (not having the view calling the controller), etc, etc.

    Now I am not saying that this is without flaws, but I am simply trying to say that I think the issue needs to be relooked at, firstly with testability in mind, secondly with the model of MVC in mind and thirdly with the dynamic and nesting aspects of these types of templates.

    Please note I am not trying to turn this into a religious debate. I am just trying to make sure 'we' (i.e. Microsoft) consider this problem now, before the masses start using it and finding that we have shot ourselves in the foot.

    Cheers
    Anthony
    Saturday, August 23, 2008 11:14 AM
  • User-1876899917 posted

    When the view method is called the framework looks at the view that it is going to run and asks the view for the details of the master page that it is going to use in the current context. It then invokes the controller for the master page
     

    Your idea is neat but it still involves the view taking charge over the controllers. If the view gets to choose its own master page, it's effectively choosing which "master page controller" the framework should invoke next.

    But still, what is this fear about "breaking MVC"? The original MVC pattern was defined in 1978 and looks **nothing like** the MVC pattern implemented in ASP.NET MVC. We're always changing the definition of MVC according to the technology at hand. It's supposed to serve us; we don't serve it. The real goal is clean separation of concerns, and tidy maintainable testable code, however that works out. Would you refuse to have a dynamically-generated image, because you have to put an <img> tag in the view which effectively calls back to a controller? Or would you object to using Ajax for the same reason? Of course not!

    When you have some kind of "widget" that's totally independent of the concerns of the current action method (such as a navigation control that appears on every page), it would be horrible to mix the widget's concerns with the unrelated controller. So in that case it's a far better design to use Html.RenderAction() - the fact that the widget appears at all is logically the view's choice and concern, just like it's also the view's choice to output some static text (who cares that displaying the widget involves running an internal request to some other controller?).

    However, when you have a "widget" that is related to the concerns of the current action method (such as paging controls at the bottom of a grid), then naturally your action method is already supplying the right ViewData so you can render the widget as a user control or whatever.

    Saturday, August 23, 2008 1:05 PM
  • User-785853015 posted

    Hey Steve thanks for the reply.

    Now I am not saying that this is without flaws, but I am simply trying to say that I think the issue needs to be relooked at, firstly with testability in mind, secondly with the model of MVC in mind and thirdly with the dynamic and nesting aspects of these types of templates.

    1) As I said its not without flaws... I just want this issue looked at. And i agree you have to go with what the technology allows for.


    Overall the problem I have is that there doesn't seem to be a well defined recommended way of dealing with this problem. What I mean by this is that Phil Haack says that action filters should be used, others say sub classing should be used and yet others say renderaction should be used. Now, I am not saying that there should be 1 way of solving a problem. But in this case it I really think there is a lot of confusion and I think it is over the fact that a good solution hasn't been found for this problem. In my view, all 3 of these solutions (in regards to master pages) have come about by people realising that master pages are an issue, not really thinking about the problem and just reacting. Currently the reaction says use something that currently exists and try bend it until it kinda works.

    2) How do you explain this. Playing devils advocate at the moment, just because you recommend renderaction wouldn't one be inclined to go with what the Phil Haack says. Yet I think we would agree that filters aren't the best solution.

    3) Also how do you explain the lack of a cohesive view on this topic.

    4) Next, if there is no problem how do you explain this http://weblogs.asp.net/stephenwalther/archive/2008/08/12/asp-net-mvc-tip-31-passing-data-to-master-pages-and-user-controls.aspx.

    5) I can just see it now... there are at least 6 different MVC books on the way, one by yourself, one with scott and phil and a few other. Based on the above quote (which is pointing out the lack of a cohesive view) I bet each one of these books will recommend a different solution to this problem.

    6) And before you say it, remember I have said "Now, I am not saying that there should be 1 way of solving a problem. But in this case it I really think there is a lot of confusion and I think it is over the fact that a good solution hasn't been found for this problem."


    Firstly there seems to be questions over whether this will even be in the first release of the framework, as from what I can tell it currently seems to be in 'Futures'.

    7) If this is the best solution to the problem why put it into the 'futures' release. If this is really needed to solve the problem, it should be promoted and everyone should be saying that this is the clear way to go. Yet it’s in 'futures' (afak) and there are debates like this one and others like stephens blog.

    8) To me there has to be something that will provide a better solution to this problem, I am simply trying to get a discussion going. And to be honest I really do agree with you about the MVC model and when it was created and its relevance in it most pure form. I just think the solution should be in the spirit of MVC or at least when designing a solution if you start with this in mind the solution would have to be a good one.

    9) In the end I dont really mind as long as the solution is, firstly, built with testability in mind, secondly with the model of MVC in mind and thirdly with the dynamic and nesting aspects of these types of templates.


    Please note I am not trying to turn this into a religious debate. I am just trying to make sure 'we' (i.e. Microsoft) consider this problem now, before the masses start using it and finding that we have shot ourselves in the foot.


    10) I really do mean that I am not trying to turn this into a religious debate, just to get a good solution.

    Cheers
    Anthony

    Saturday, August 23, 2008 7:34 PM
  • User-1876899917 posted

    Anthony, thanks for your well-considered reply! I'm not trying to prevent any discussion on this subject - I was trying to contribute to the discussion by putting forward my experiences and views.

    I wasn't saying that RenderAction should be used in *all* circumstances - I was only saying that RenderAction works well when you have widgets that are logically independent of the rest of your output. In these cases it gives you a nice separation of concerns between that widget and whatever primary controller is running. The other techniques can also be useful too, and it's up to you to pick whatever is most appropriate in your particular circumstance.

    As for why this whole issue keeps causing confusion and debate, I would say it's because the whole business of independent controls doesn't naturally mesh with MVC - look at other MVC platforms such as Rails and you'll see the same contention there. Some folks have bought into the idea that MVC instantly solves all problems, but in fact while it has loads of strengths it also has a few weaknesses. The real world never quite fits into a neat theoretical box, so while it's good to promote a solid adherence to a consistent architectural approach, that approach has to be broad enough to let you get good results.

    Monday, August 25, 2008 7:18 AM
  • User-785853015 posted

    Hey Steve
    Again thanks for the reply.

    Its interesting to know that others (like those in the rails community) also have this issue and I understand what your saying about the RenderAction.

    It's a pity though, I thought that more people would be concerned with this issue. But by looking at the amount of responses this is getting maybe others aren't as worried about this as me. Although when I see this http://weblogs.asp.net/stephenwalther/archive/2008/08/12/asp-net-mvc-tip-31-passing-data-to-master-pages-and-user-controls.aspx it makes me think that it is an issue. Maybe this just isn't the place... although I don't know of anywhere else.

    I guess I just thought that if enough smart people put their minds together a good solution might be out there.

    Anyway if anyone from Microsoft read this a least let it be know that at least one person would like some more love given to this is in the MVC framework itself.

    Cheers
    Anthony

    Monday, August 25, 2008 8:32 AM
  • User1535844800 posted

    So what can we learn from the Rails project? How did they end up solving this problem? How about MonoRail? Java MVC frameworks?

    I could not find much from Rails about this, but I think they use a pattern that can be compared to using Filter attributes in ASP.NET MVC.

    From what I've seen, RenderAction should be sufficient, if it's not 'MVC' but it works really well, then what about it? If you have an Ajax call on your page that calls to an endpoint (url, basically the acion of a controller) and receives some HTML or JSON, that seems to me the exact same pattern as RenderAction.

    Wednesday, September 24, 2008 6:01 AM