Not sure I follow. For all (Http) effects, a VC is just a controller, with its own name and actions.
On Mon, Aug 15, 2011 at 3: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. > > -- 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.
