"Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
> "Daniel L. Rall" wrote:
> >
> > "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
> > [ snip aimless chatter ;) ]
> > > I don't quite get you here. Can you provide an example? Are you saying
> > > something like :
> > >
> > > #set $foo = #tablerow( $a $b )
> > >
> > > such that
> > >
> > > <table>
> > > $foo
> > > </table>
> > >
> > > outputs (for example)
> > >
> > > <table>
> > > <tr><td color=$a>$b</td></tr>
> > > </table>
> > >
> > > (assuming what tablerow does, of course...)
> > >
> > > Actually, that's *very* possible, if you want the LHS of the #set
> > > assignment simply to 'catch' what the VM would render. If time allows,
> > > I will try to hack that together tonight and see how well it works.
> > > This is, of course, subject to no great opposition from the list
> > > members, but I don't think this is very far at all from #set $foo =
> > > $somecontexttool.blargh($a,$b), so I can't see why it would be a bad
> > > thing.
> >
> > With the introduction of a feature like this, next thing you know,
> > people will start "programming" in VTL. I thought that the whole idea
> > behind the Velocimacro was to present an actual interface to reusable
> > VTL snippets that would otherwise just be #parse'd templates with
> > misc. variables set in the containing template evaluated in the #parse'd
> > markup (i.e. to prevent coupling).
>
> Dead-on true, but people already program in VTL. I mean, we have
> control structures and assignments in VTL.
>
> > I like the interface that Velocimacros give to #parse, but worry about
> > the introduction of too many programmatic features to a templating
> > system. I think that LHS assignment of a Velocimacro evaluation may be
> > going too far.
>
> I figured there would be a protest. I don't feel strongly about this,
> but I thought it an intriguing idea, and if it has a use w/o clouding or
> confusing Velocity's simplicity and usability, I guess I am for it.
>
> My main counter-argument to the above (and I'll try to avoid that
> aimless chatter... :) is the notion of context-tools. [I want to discuss
> this as Velocity standalone - lets not mix in a framework like
> Turbine...]
>
> The problem I have with context-tools is when they return formatted
> output: if that doesn't break MVC from the 'person-role' aspect (Java
> programmer vs. template designer), it really blurs the boundary.
> I mean, context-tools are cool for all sorts of uses, utilities like
> string manipulation, algorithmic assistance (like rotating through a set
> of values, for ex. rowcolors in a table). But I think they are a
> piss-poor solution to producing formatted output. Of course, in some
> instances there may be no choice w/o making the template language
> complicated. Life isn't simple, I guess.
>
> Now, if one puts aside the MVS theology for a sec, and accept the need
> for a context tool that produces formatted output on the RHS of a #set,
> then it would seem natural that you should allow the designer the
> ability to create that 'context tool', since that *is* the job of the
> designer, which could be a VM, or VM-like entity.
>
> One alternative, maybe, to keep things clear would be to both access VMs
> as directives so you could invoke a VM inplace as #<VMNAME>() or as a
> reference as $<VMNAME>() in anyplace a reference can be used (such as
> the RHS of a #set assignment...). Dunno.
>
> Good subject for discussion, I guess.
You win as usual, +1. ;)
Daniel
p.s. Sorry for the late reply.
