Web MVC and View Composition

[Daniel Jin]

http://forums.asp.net/t/1196142.aspx

In one of the discussions over at asp.net mvc forum. The now obsolete
RoR render_component came up. After some playing around, I was able to
prototype out a crude implementation based off of the ctp drop. (code
is posted in the thread, you can try it out at your leisure).

Now I'm just curious on what the crowd here thinks of the concept. Did
Monorail ever consider this approach? It's pretty clear where RoR
stands on this. I just want some more opinions, and possibly what
would be a acceptable and clean alternative to render a composite
view. (think of portals with customization with different plugins).

[Colin Ramsay]

ViewComponents are the Monorail solution to this problem.

[Daniel Jin]

Not the same. render_component will allow you to have multiple independent actions executed within the same httprequest. think of a personalized portal page that allows various plugins including those from 3rd party providers. One action that knows about all the plugins' data doesn't make much sense in this case.

[Ayende Rahien]

Doesn't this mean that you run business logic in the view?
Deciding what actions to run certain strikes me as business logic.

[Daniel Jin]

thus far I've been looking at it as a master view instructing multiple sub views each with its own mvc cycle. but there is the coupling in the view knowing what controller and action to invoke, which definitely goes beyond plain view logic. is that pure business logic? maybe. (but then so is any similar ajax approach you could use to render the same composition) however, it's better than what rob conery seems to suggest, having reusable partials (user controls) that directly invoke services, which brings us right back to the page controller world.

the thing that bugs me about the action filters is that the view (subview?) and it's controlling piece is not longer a tightly connected whole. in the master-detail page example I used in that thread, any time you want to switch up half of the pages to a different layout, you have to go through a lot of the actions to affect that change. not as clean as it could be I think.

[Hamilton Verissimo]

On 12/24/07, Daniel Jin <danie...@gmail.com> wrote:

> One action that knows about all the plugins' data doesn't make much sense in
> this case.

ViewComponents do not require an action to set something so it can
consume. It can be totally standalone. It's up to the programmer to
decide the best approach for his scenario. And yes, we could have 3rd
party VCs implemented

--
Cheers,
hamilton verissimo
ham...@castlestronghold.com
http://www.castlestronghold.com/

[Hamilton Verissimo]

Yours suggestion is the extremist PoV regarding MVC. I havent read the
thread, but I would go ahead and agree with Conery's suggestion.

Also, if RoR has done it in some specific way, does it mean is the
right/best way? I dont think so.

[Daniel Jin]

I'm not sure if I agree with this being an extremist view regarding mvc. I just feel that what rob was suggesting is basically giving you a mix of mvc and page controller, 2 patterns mixed in one architecture. (of course whether that's a problem or not all depends on how much you use it). RoR in fact has made this approach obsolete. I just thought this could be useful in certain situations.

also I assume by standalone, you mean the ViewComponent will directly consume a service. without the usual mvc cycle, correct?

[Hamilton Verissimo]

Correct.