Yep. Since the vc itself is a controller, the actions are accessible like any other controller. You just have to have a route for the vc area.
Cheers, Henry Conceição On Mon, Aug 15, 2011 at 7:16 PM, Gauthier Segay <[email protected]>wrote: > 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. > > -- 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.
