SubController implementation now in MvcContrib

[Jeffrey Palermo]

Guys,

I'm still hoping that SubControllers make it into the MVC Framework release, but my company is doing several client projects right now using the MVC Framework.  These projects are enterprise applications, not smaller websites, so subcontrollers are absolutely necessary to handle the complext logic and permissions.  I've create an implementation of subcontrollers and added it to MvcContrib.  It is pulling its weight on one client project, so I'm happy with it.  It can be made better, and I'm hoping the team can take my first draft and incorporate it into the product.

Here is the revision that added SubController support to MvcContrib:  http://code.google.com/p/mvccontrib/source/detail?r=508

I have included a full sample with 3 levels of nested subcontrollers and an example of a nested subcontroller owning a form and posting to itself without the parent controllers caring:
http://code.google.com/p/mvccontrib/source/browse/trunk/src/Samples/MvcContrib.Samples.SubControllers/Website?spec=svn508&r=508

Feel free to pull down the source and let me know what you think.  Even better, if you find an idea for improvement, please submit a patch.

I have leveraged the IModelBinder so that subcontrollers can be passed directionly into action methods, and you can hook your IoC container up so that it creates the subcontrollers and the dependencies.

Decomposing complex screens infinitely increases maintainability, so this is why I consider subcontrollers a critical feature.

Even if this doesn't make it into the product, the team has done a good job making the framework extensible, so I was able to implement subcontrollers in less than 150 lines of code.   I welcome your thoughts and opinions. 

You can pull down the source for MvcContrib by pointing your TortoiseSVN client to http://mvccontrib.googlecode.com/svn/trunk/ Note that this is a SVN URL, not a web page URL

--
Best regards,
Jeffrey Palermo, Microsoft MVP, MCSD.Net
CTO, Headspring Systems
agile. software. consulting.
512-459-2260 x 712

[Fredrik Kalseth]

Great stuff!

Just submitted a patch (#1859) which allows a sub controller to have
multiple actions; essentially just changed the Action returned by
GetResult to an Action<string>.
Also added an extension method so that invoking a sub controller
action can be done like this:

<% this.InvokeSubController("SubController", "Action"); %>

Cheers,

Fredrik Kalseth
Blog: http://iridescence.no

On Sep 8, 4:15 am, "Jeffrey Palermo" <Jeff...@Palermo.cc> wrote:
> Guys,
> I'm still hoping that SubControllers make it into the MVC Framework release,
> but my company is doing several client projects right now using the MVC
> Framework.  These projects are enterprise applications, not smaller
> websites, so subcontrollers are absolutely necessary to handle the complext
> logic and permissions.  I've create an implementation of subcontrollers and
> added it to MvcContrib.  It is pulling its weight on one client project, so
> I'm happy with it.  It can be made better, and I'm hoping the team can take
> my first draft and incorporate it into the product.
>
> Here is the revision that added SubController support to MvcContrib:http://code.google.com/p/mvccontrib/source/detail?r=508
>
> I have included a full sample with 3 levels of nested subcontrollers and an
> example of a nested subcontroller owning a form and posting to itself

> without the parent controllers caring:http://code.google.com/p/mvccontrib/source/browse/trunk/src/Samples/M...

>
> Feel free to pull down the source and let me know what you think.  Even
> better, if you find an idea for improvement, please submit a patch.
>
> I have leveraged the IModelBinder so that subcontrollers can be passed
> directionly into action methods, and you can hook your IoC container up so
> that it creates the subcontrollers and the dependencies.
>
> Decomposing complex screens infinitely increases maintainability, so this is
> why I consider subcontrollers a critical feature.
>
> Even if this doesn't make it into the product, the team has done a good job
> making the framework extensible, so I was able to implement subcontrollers
> in less than 150 lines of code.   I welcome your thoughts and opinions.
>
> You can pull down the source for MvcContrib by pointing your TortoiseSVN

> client tohttp://mvccontrib.googlecode.com/svn/trunk/Note that this is a

[Jeffrey Palermo]

Fredrik,
Thanks for the contribution, but this puts control in the view.  The view should not be deciding what action to call.  The view should merely render.  The decision about what to render should lie with the parent controller or subcontroller.

--
Best regards,
Jeffrey Palermo, Microsoft MVP, MCSD.Net
CTO, Headspring Systems
agile.  software.  consulting.
512-459-2260 x 712

[Anthony Bouch]

Ah I think the penny just dropped... so the same applies to
RenderAction("Action", "Controller") as well then.

I'd like to create a helper class that can invoke SubControllers from
NVelocity Jeff... the "key" in the ViewData (in order to find the
Action delegate) is just the name(s) of the parameter for the
SubController in the calling action correct?

[Anthony Bouch]

Hi Jeff

Was experimenting with registering ModelBinders.

Am I correct in understanding that there are two options for
registering the SubControllerBinder.

Either as the default binder...

ModelBinders.DefaultBinder = new SubControllerBinder();

Or by registering each SubController derived type?

ModelBinders.Binders[typeof(FirstLevelSubController)] = new
SubControllerBinder();
ModelBinders.Binders[typeof(SecondLevelSubController)] = new
SubControllerBinder();
...

I was tempted to try and register the SubController base class.. but
it didn't work. In Scott Guthrie's Preview 5 post.. he mentioned that
there were still a few changes coming to ModelBinders. Could
supporting the registering of a base class be one of them?

On Sep 8, 9:15 am, "Jeffrey Palermo" <Jeff...@Palermo.cc> wrote:
> Guys,
> I'm still hoping that SubControllers make it into the MVC Framework release,
> but my company is doing several client projects right now using the MVC
> Framework.  These projects are enterprise applications, not smaller
> websites, so subcontrollers are absolutely necessary to handle the complext
> logic and permissions.  I've create an implementation of subcontrollers and
> added it to MvcContrib.  It is pulling its weight on one client project, so
> I'm happy with it.  It can be made better, and I'm hoping the team can take
> my first draft and incorporate it into the product.
>
> Here is the revision that added SubController support to MvcContrib:http://code.google.com/p/mvccontrib/source/detail?r=508
>
> I have included a full sample with 3 levels of nested subcontrollers and an
> example of a nested subcontroller owning a form and posting to itself

> without the parent controllers caring:http://code.google.com/p/mvccontrib/source/browse/trunk/src/Samples/M...

>
> Feel free to pull down the source and let me know what you think.  Even
> better, if you find an idea for improvement, please submit a patch.
>
> I have leveraged the IModelBinder so that subcontrollers can be passed
> directionly into action methods, and you can hook your IoC container up so
> that it creates the subcontrollers and the dependencies.
>
> Decomposing complex screens infinitely increases maintainability, so this is
> why I consider subcontrollers a critical feature.
>
> Even if this doesn't make it into the product, the team has done a good job
> making the framework extensible, so I was able to implement subcontrollers
> in less than 150 lines of code.   I welcome your thoughts and opinions.
>
> You can pull down the source for MvcContrib by pointing your TortoiseSVN

> client tohttp://mvccontrib.googlecode.com/svn/trunk/Note that this is a

[Anthony Bouch]

Was looking at Subcontrollers again.

I think I understand one of the problems solved using SubControllers..
in that with a ViewExtension method like RenderAction(action,
controller) - we're naming a controller in the view directly - so the
view is now tightly coupled to a controller.

But with SubControllers we're still telling the parent controller to
put 'something' into the ViewData... even if it's only the action
delegate. I can see the improvement, since the controller is deciding
what, if any, SubControllers will be available to the view, and the
SubController, when invoked, can create any additional ViewData it
needs on demand (as well as use any view template it wants to arrange
the output).

I think in my widget strategy I was aiming for independence from both
the parent view and parent controller by being able to drop a helper
method onto any view like... html.GetWidget('mywidget') - and have a
totally independent controller/view result rendered onto the page.

Would another option be to register widgets somewhere else.. like a
Route? Maybe then we'd achieve independence on both counts. I took a
quick look at the idea of registering widgets with the RouteCollection
- but in order for this to work the helper widget method would have to
fake an HttpContext (and url) in order to find the registered widget
RouteData.

I guess an alternative would be to create a static
Dictionary<widgetname, RouteDictionary> collection that could be used
to register widgets... and then feed them back into the ViewExtensions
helper method via RenderRoute(this HtmlHelper helper,
RouteValueDictionary values).

[Ben Scheirman]

Remember that the parent contrller can use [SubControllerToViewData]
and it will be automatic.

On your widget example your view is in control, so why not just use
render action?

Sent from my iPhone

On Oct 5, 2008, at 9:41 PM, Anthony Bouch <anthon...@gmail.com>
wrote:

[Anthony Bouch]

Ok thanks Ben.. I'd missed that the parent controller has access to
[SubControllerToViewData]

And you're right...in my registered widget collection I could just
call RenderAction(action, controller). I guess the main point was that
by registering a collection of named widgets in a configuration class
(outside of any controller)... we decouple the view template from a
named controller, and html.GetWidget("mywidget") will always work
even if the controller or action are refactored at a later time (by
updating the configuration class).

On Oct 6, 9:51 am, Ben Scheirman <subdigi...@gmail.com> wrote:
> Remember that the parent contrller can use [SubControllerToViewData]  
> and it will be automatic.
>
> On your widget example your view is in control, so why not just use  
> render action?
>
> Sent from my iPhone
>

> On Oct 5, 2008, at 9:41 PM, Anthony Bouch <anthony.bo...@gmail.com>