"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.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
