atom feed6 messages in com.googlegroups.mvccontrib-discuss[mvccontrib-discuss] SubController De...
FromSent OnAttachments
hend...@gmail.comMar 8, 2009 7:09 am 
hend...@gmail.comMar 8, 2009 7:10 am 
Hendry LukMar 8, 2009 7:16 am 
Jeremy SkinnerMar 8, 2009 7:53 am 
Hendry LukMar 9, 2009 12:59 am 
Jeremy SkinnerMar 10, 2009 8:33 am 
Subject:[mvccontrib-discuss] SubController Design
From:hend...@gmail.com (hend@gmail.com)
Date:Mar 8, 2009 7:10:43 am
List:com.googlegroups.mvccontrib-discuss

Hi, there are several things I dont get about subcontroller. I'm noob, and would appreciate if anybody can help clearing these up: 1. Why do we need subcontroller library at first place? I mean, why do we need to pass delegate of subcontroller through ViewData to the View? Why don't we call subcontroller from directly from controller, and pass rendered HTML to the ViewData? 2. Since SubController instance is passed thorugh action method, how do you use HTML.ActionLink's lambda parameter for this action method? What should we pass to its subcontroller parameters? 3. Which brings me to this question. What's the justification to pass subcontroller as method parameter instead of constructor injection? Wouldn't it be more natural, and it becomes possible to use IoC support directly without hacking through ModelBinder 4. Why do we use naming convention and limit only 1 action per subcontroller class? And this also makes passing model parameters bit counter-intuitive using setter injection on Model property. Wouldn't it better that as opposed to this: ViewData["subcontrollerResult"] = subController.GetResult(this); we use this instead: ViewData["subcontrollerResult"] = subController.GetResult(this, x => x.ActionName(param, otherParam, andSoOn)); This way we can have more than 1 actions per subcontroller (just like a normal Controller), and more consistent way of passing models (again, just like a normal Controller, e.g. in HTML.ActionLink()). It also highlights point #3 in the case of subcontroller having further subcontrollers.

I'm just trying to understand the rationale behind SubController, and why it's designed the way it is.

Additionally, I have a question about how would you implement a common view part that always exists in most Views? Well, 2 popular approaches are: 1. If the common part is surrounded by the views, then use subcontroller (e.g. product info "widget") 2. If the common part is surrounding the views, then use master-page (i.e. menu, login info, footer, etc)

The problem with #2 is, masterpage doesn't have controller associated with it. This is a very basic and common problem to solve when I start writing a web-app, and the solution that I always take is to have the master-page "almost empty" delegating most of its work to subcontrollers. Hence, almost ALL controllers will have to use these subcontrollers, and for this, I therefore create a base controller (which incidentally would be cleaner if subcontroller were constructor injected, hence point #3 above). Is this an approach you would normally go for? Do you have better approach to have "master-page-controller"?

Thanks before

--~--~---------~--~----~------------~-------~--~----~ Contact Jeffrey Palermo or Eric Hexter with specific questions about the
MvcContrib project. Or go to http://mvccontrib.org

To unsubscribe from this group, send email to
mvcc@googlegroups.com For more options, visit this group at
http://groups.google.com/group/mvccontrib-discuss?hl=en -~----------~----~----~----~------~----~------~--~---