As I understand it, VC with actions sound like a nice way to pack what I would have done with VC + dynamic action providers in MR2, which incurs declaring the provider on controllers using the VC.
Is my understanding right? if it's right, how are the actions made accessible through routing? On Aug 16, 12:05 am, hammett <[email protected]> wrote: > 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 > > athttp://groups.google.com/group/castle-project-devel?hl=en. > > -- > Cheers, > hammetthttp://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.
