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.
