views:

2190

answers:

3

I am torn between the idea of using Html.RenderAction vs. Html.RenderPartial for partial views. Using RenderPartial means manipulating and passing ViewModel, something I feel is cumbersome. RenderAction is neat and concise in this case but not included for RC1 (included with futures though).

Why is it so? Any specific reason?

A: 

I don't know the reasons why it was moved (into "futures"); at a guess, it is to make it less "obvious", since it has more cost than RenderPartial (simulating much more of the pipeline, etc).

Marc Gravell
+2  A: 

As far as I remember they decided to move it to futures assembly because they want to release first version of the framework as soon as possible and there are some problems with RenderAction (here is an example). And RenderAction is planned to be included in asp.net mvc version 2. In my opinion it's better to use SubController's from MvcContrib instead of RenderAction.

zihotki
it is now present in MVC version 2 - http://haacked.com/archive/2009/11/18/aspnetmvc2-render-action.aspx
Simon_Weaver
+1  A: 

There are other non-obvious obscure 'problems' such as the POST action being invoked on a child control as well as its parent - when the child was rendered by RenderAction.

I made a post about it here.

While arguably the behavior is by design it is at least confusing and annoying, and at most potentially dangerous and could lead to serious application bugs if you're not vigilent.

I've pretty much reverted to RenderPartial, especially in cases where there is a POST action for the action.

Simon_Weaver
The MVC 2 Beta introduces an action attribute that prevents it from being called except via RenderAction().
No Refunds No Returns