Actually, I'd really like to keep the master framework as part of it. Not for the page master concept, but to extend that same concept down to the panel level.
The Master Page is not a holder of the other page, but a skin or layout that the page selects. This becomes much clearer when you start looking at panels rather than pages.
If we had the multi-level system as you describe it then a page might be rendered with 10 or more panels on it. Some would be rendered in context specific ways with associated formatting (for example forcing a panel to appear as a side-bar) Others though
would be called for with little or no knowledge by the page of their nature. In their case it would be up to each panel to select the relevant master-template that it was to be drawn with (note: not page-template, but panel/control template).
The inability to use templates at the control level is one of the worst features of the MVC implementation as it stands. It forces developers to bury layout in code if they don't want to reproduce the same layout in every panel (with all the issues that
implies)
At first I had disliked the structures you (and others) were suggesting as they looked at a glance to be a misinterpretation of the MVC model, but in cases such as Content Management Systems and other such sites they would be immensely useful.
The one thing I would suggest is that the internal call (to the panels) should not be too strongly decoupled. I think I'd favour a model where each panel could access it's model, or it's parent (at least enough so to be able to ask it's parent for data.)
In fact what I'd most favour is a chain of Page->Panel->sub-panel->sub-sub-panel etc. with each item able to ask for info from any point up the chain (so the sub-sub-panel can ask the page for model information in a call like "this.context.page.model.UserName()
or similar.
Anyway, just my 10c worht.
- Keith
Keith Ealanta
"Any sufficiently understood magic is indistinguishable from science"
Hi abombss, I realize this is an old thread but I think the concept discussed here is still relevant (This is the most detailed thread I have seen try to tackle this topic.. and I don't know if there are any new additions to the framework that have settle
this issue since then)..
Anyway my point is that I'm curious about the methods you outlined above especially #2 although I'm not quite sure I understand the details of how you are going about it.. I'm wondering if you could care to explain option #2 in a little more detail (I think
future readers might find that useful as well)
I'm also curious if you have found/settled on a different approach to the problem since this post... or alternatively any links that you may have that deal with this topic in more detail..
keith.ealant...
Member
6 Points
5 Posts
Re: How about a very complex page which need many "MVC modules/parts" ?
May 22, 2009 12:30 AM|LINK
Actually, I'd really like to keep the master framework as part of it. Not for the page master concept, but to extend that same concept down to the panel level.
The Master Page is not a holder of the other page, but a skin or layout that the page selects. This becomes much clearer when you start looking at panels rather than pages.
If we had the multi-level system as you describe it then a page might be rendered with 10 or more panels on it. Some would be rendered in context specific ways with associated formatting (for example forcing a panel to appear as a side-bar) Others though would be called for with little or no knowledge by the page of their nature. In their case it would be up to each panel to select the relevant master-template that it was to be drawn with (note: not page-template, but panel/control template).
The inability to use templates at the control level is one of the worst features of the MVC implementation as it stands. It forces developers to bury layout in code if they don't want to reproduce the same layout in every panel (with all the issues that implies)
At first I had disliked the structures you (and others) were suggesting as they looked at a glance to be a misinterpretation of the MVC model, but in cases such as Content Management Systems and other such sites they would be immensely useful.
The one thing I would suggest is that the internal call (to the panels) should not be too strongly decoupled. I think I'd favour a model where each panel could access it's model, or it's parent (at least enough so to be able to ask it's parent for data.) In fact what I'd most favour is a chain of Page->Panel->sub-panel->sub-sub-panel etc. with each item able to ask for info from any point up the chain (so the sub-sub-panel can ask the page for model information in a call like "this.context.page.model.UserName() or similar.
Anyway, just my 10c worht.
- Keith
"Any sufficiently understood magic is indistinguishable from science"
FadiRezq
Member
2 Points
5 Posts
Re: How about a very complex page which need many "MVC modules/parts" ?
May 26, 2010 11:16 PM|LINK
Hi abombss, I realize this is an old thread but I think the concept discussed here is still relevant (This is the most detailed thread I have seen try to tackle this topic.. and I don't know if there are any new additions to the framework that have settle this issue since then)..
Anyway my point is that I'm curious about the methods you outlined above especially #2 although I'm not quite sure I understand the details of how you are going about it.. I'm wondering if you could care to explain option #2 in a little more detail (I think future readers might find that useful as well)
I'm also curious if you have found/settled on a different approach to the problem since this post... or alternatively any links that you may have that deal with this topic in more detail..
Thanks!
MVC usercontrols modules advanced