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 haven’t 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.
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 :)
:: Never underestimate the predictability of stupidity ::
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.
@ 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).
:: Never underestimate the predictability of stupidity ::
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.
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.
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.
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.
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.
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 :)
:: Never underestimate the predictability of stupidity ::
vdh_ant
0 Points
56 Posts
Master Pages and Dynamic Data??
Jul 21, 2008 10:09 PM|LINK
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 haven’t 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
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 12:01 AM|LINK
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 :)
DmitryRA
Member
18 Points
11 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 12:14 AM|LINK
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.
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 01:43 AM|LINK
@ 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).
snidersh
Member
75 Points
29 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 03:09 AM|LINK
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.
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.vdh_ant
0 Points
56 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 03:12 AM|LINK
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
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 03:31 AM|LINK
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.
snidersh
Member
75 Points
29 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 03:40 AM|LINK
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.
vdh_ant
0 Points
56 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 03:53 AM|LINK
Agreed... now how do we get them to read this...
pure.krome
Member
532 Points
349 Posts
Re: Master Pages and Dynamic Data??
Jul 22, 2008 04:00 AM|LINK
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 :)