Yep, it's a thin line. But the result of not having some ui widget spread across multiple partials/views/controllers in different places is pretty nice imo.
Cheers, Henry Conceição On Mon, Aug 15, 2011 at 8:52 PM, Gauthier Segay <[email protected]>wrote: > Thanks Henry/Hammett, I get it, sounds convenient when it makes sense > to package those relevant actions related to VC behaviour next to "VC > instance" implementation. > > Although it can get confusing if the VC has instance members which > would be technically accessible in action's code without those being > relevant, I would not deem that as being a "best practice" in most of > the case but as a convenience to VC authors so there are less elements > to take care of when incorporating those into applications. > > On Aug 16, 12:26 am, hammett <[email protected]> wrote: > > 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 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.
