Just to be clear on the changes to VC between older MR and MR3: - We (Henry and I) noticed that is fairly common to have VC with "actions", especially when combined with ajax - therefore VC in MR3 is a controller implementing a interface IViewComponent, that defines the default action. - layout wise, they should live in a viewcomponents folder.
The principle remains the same, though. Controllers are flat and vertical, hence not composable. ViewComponents is the way to aggregate content/logic within views. On Mon, Aug 15, 2011 at 2:54 PM, Gauthier Segay <[email protected]> wrote: > I still haven't check the status of MR3 but I'm used to Spark/MR2 and > ViewComponents (which don't have sibling in MS MVC AFAIK) > > Your message makes me wonder if there are changes in VC, but I guess > it's still the nice and plain ones we have in MR2. I've checked > Hammett's post regarding Blade and could definitely concure with you > Tomek that passing template parts as lambda's is not gonna be simply > transposable to Spark. > > That is actually something I've been fighting with Spark, which is > passing parts of templates as expression and I admit I always had to > work around using more verbose. > > Spark uses a macro system which are mere functions taking defined set > of parameters, but there is no way to pass macros as macros for say, I > didn't try to "reverse engineer" (looking at generated code or at > Spark source) what would be the actual delegate signature to make this > hack work; but my feeling is that this could be leveraged to wrap > those lambdas as "anonymous" Spark macros. > > That "template nesting" ability definitely gives an edge to Blade (pun > not intended), and I'm looking forward so that this get's available in > other view engines as I'd like to stick with Spark which is really > nice in every other aspects. > > I'm also curious if it could be baked in spark in a way which remains > agnostic to framework using it as view engine (could work with spark > standalone, MSMVC and MR2 as well), that would be great. > > I guess the implementation detail discussion will probably move to > spark group but I'm trying to get the hold of the top level > implications. > > Tomek, do you feel the "anonymous macro" idea and some way to declare > macro typed parameters to macros would be a good fit ? > > I can also see two issues investigating that way: > > * macro have scoping which avoid referencing anything else than > parameters, it doesn't work as a closure, I guess one reason is that > you can define macros outside of the scope to be used at different > places (Hammett, is this possible with Blade? can you define what you > pass to builder.TemplateFormBuilder outside of the call?) > * macro aren't supporting generic type parameters > > That lambda syntax definitely gives an edge to Blade (pun not > intended), it will probably open nice possibilities to define view > parts that are generic and extensible without necessarily going with > view component or helpers (if MR3 viewengine infrastructure bakes the > concept of declaring those parametric templates as an abstraction > similar to the concept of VC), I have to grasp what's done with > current helpers a bit more to understand better if it could possibly > fit. That would give another edge to MR3 beside Blade. > > On Aug 15, 9:28 pm, Tomek Pluskiewicz <[email protected]> wrote: >> Regarding View Component sections in Spark. >> >> Lambdas may tricky with Spark. Most of it's syntax get wrapped in an >> TextWriter#Write call. Even if it parses into a C#, at the moment complex >> anonymous methods will be tricky. I will be looking to resolve this issue >> with Spark's team. >> >> Anyway I understand that the principle is to pass sections' content template >> to a property and then it would be resolved inside view component's view. Is >> that right? >> >> Spark tries to get as much XML-like as possible and so, viewcomponents look >> similarilly to the below: >> >> <SomeComponent SomeProperty="variable"> >> <SomeSection> >> <td> >> ${item.Name} >> </td> >> </SomeSection> >> </SomeComponent> >> >> In the way MonoRail 1/2 view component sections were openly declared this >> was easy. With the new ways I guess some plumbing is inevitable ;) > > -- > 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.
