I'm in favor of changing the API to accommodate more view engines. We could think of something like
ViewComponent.Render<Foo>(vc => vc.DefineSection( @<td> @item.Name </ td>) ) that could be translated into Spark's nested xml.. or something like it. As long as we can present the helper API, i dont care much for how we shape this API. On Mon, Aug 15, 2011 at 3:36 PM, Gauthier Segay <[email protected]> wrote: > Thanks, > > I think support for partials, layouts and simple VC is already pretty > good. > > It might be naive but for VC sections, doesn't it boil down into being > able to invoke the section rendering with a signature similar to those > used to render a plain view but replacing the "read view template to > stream" part with passing a StringReader containing the section? > > I understand this requires some hooks between MR viewengine > infrastructure and the view engine implementation which might be > tricky to get right. > > I'm sorry to bring topic which sounds complex without looking further > at the implications on my own. > > On Aug 16, 12:22 am, Henry Conceição <[email protected]> > wrote: >> For the simple cases (like the one described on the haack's), yes. >> >> But things can get fairly complex if you bring vc sections to the table. And >> I'm not sure if it is worth. >> >> Cheers, >> Henry Conceição >> >> On Mon, Aug 15, 2011 at 7:13 PM, Gauthier Segay >> <[email protected]>wrote: >> >> >> >> >> >> >> >> > I'm wondering if this is (conceptually) supported or not in the >> > current incarnation of MR3 >> >> >http://castle.uservoice.com/forums/38553-monorail-v3/suggestions/4564... >> >> > I'm not sure what's implied with this comment: >> > // we need to make sure this interface allows for recursive view >> > engines >> >> > which is found there: >> >> >https://github.com/castleproject/Castle.MonoRail3/blob/master/src/Cas... >> >> > but it's probably describing something else. >> >> > I think it's an important feature despite I remember Ayende was saying >> > that it was unlikely to happen, on my side I think it's likely to >> > happen and gives choice of the right tool for the right template, and >> > blended migration of template/viewengine in long lived applications. >> >> > This is also a reason for having a set of concepts such as the >> > template lambdas and view components baked at MR level that are able >> > to inter-operate between view engines, something which seems to be >> > lacking in MS MVC viewengine infrastructure. >> >> > I understand it's probably something difficult to get done right if >> > you want to have those framework level concepts to interact properly >> > between view engines, like implementing the include semantic which >> > works across view engine is probably a not easy problem to solve. >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Castle Project Development List" group. >> > To post to this group, send email to [email protected] >> > . >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> >http://groups.google.com/group/castle-project-devel?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > -- Cheers, hammett http://hammett.castleproject.org/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
