[PROPOSAL] #eval directive [was Re: interpolation]

[Christoph Reck <Ch...@dlr.de>]

It seems that the Anakia requirement and Theo's request (within 
the "Re: interpolation" thread) was misunderstood.

For the automagic XML processing in anakia it would be splendid
to invoke vmacros without having to code each call explicetely.

I will submit an #eval directive implementation if I get some 
+1 votes! (Theo/jon/werken please vote if you think this is a 
valuable addition). You can opt to call it a #match directive 
or wish it as a context tool (e.g. with a configurable default 
macro name to use if no match was found).

I will not consider the previous objections of Daniel and Geir
with the following reasoning (so please re-vote for this proposal):
>Daniel wrote:
> I am -1 on a eval directive--functionality such as that should not be
> available to a template engineer.  They are around to make things look
> pretty, and this is not a tool from their bag of tricks.
That is the reason for having configurable and pluggable directives. 
This feature/trick will be used by anakia and other VSL users and 
not by normal HTML template writers.
>Geir wrote:
> I agree.  When things are getting that complicated in View-land, it's
> time to ask for help from elswhere in the app..
This is why I'm proposing a pluggable directive here. If you mean
elswhere by saying it should be a ContextTool, I'm willing also to
do as sucht if you think that is the right approach. let me know.


Here is the background and usage for the proposal:

To is what XSLT provides with xsl:apply-template and 
xsl:template-match constructs, where each element name is
used to search for a matching template rule:
  <xsl:template match="ElementName">
    <xsl:apply-templates select="./*" />
  </xsl:template>
  <xsl:template match="...any_child_element_name...">
    ...
  </xsl:template>
  ... more tample rules

For VSL this would look like:
  #macro(match_ElementName, $node)
    #foreach($element in $node.Children)
      #eval("#match_${element.Name}($element)")
      ## alternatively: #match($element.Name, $element)
      ## or as: $CallMacro("match_$element.Name", $element)
    #end
  #end
  #macro(match_any_child_element_name, $elements)
    ...
  #end
  ... more match vmacros

Without the #eval directive it would require beforehand to 
code a cascade of #if/#elsif/#end to define all possible child
element names. This would make the code reusal/mantenance 
*much* easyer.

Geir, if you could give me a hint on how to do the #eval
implementation - accessing a macro from the code - without 
having to compile a template with the string and the merging
it, i would be thankful for it.
> Now, this bit about 'functional interpolation' or whatever you want 
> to call something like '#$macroname()' might be very easy to do, but 
Hints if this is easy (e.g. filename/line number for example...)
> is, I believe, currently outside of the general consensus of what 
> VTL allows.  I think that if we do want that sort of facility, it 
> should be a new directive, such as #eval( ... ) or similar to both 
> make clear what the template author intends as well as make easy 
> the ability to shut it off.
This is the proposal I'm making here!

>Theo wrote:
> Yes, I tried the #match_$macroname(), but it does not work,
> the #$macroname() maybe is easy but does not help - it might
> pick up other macro's by mistake.
This is why I propose to create #eval, #match or MatchMacroTool
to do what is needed. Theo, would you be willing to takeover the
implementation, or work together with me (testing what I do with
your examples) in doing it?

:) Christoph

Re: [PROPOSAL] #eval directive [was Re: interpolation]

["Geir Magnusson Jr." <ge...@optonline.net>]

Christoph Reck wrote:

> [snip]
> I will submit an #eval directive implementation if I get some
> +1 votes! (Theo/jon/werken please vote if you think this is a
> valuable addition). You can opt to call it a #match directive
> or wish it as a context tool (e.g. with a configurable default
> macro name to use if no match was found).

I thought we had mentioned this at some point, and it was panned hard by
Daniel and Jon. 

I certainly see the need, and I have a fully working implementation of
#eval().  But I was holding it back because there was pretty strong
opposition, I thought.  I like the idea, but w/o further convincing, I
agree it may not be apropos for VTL.

Anyway, if we want it, its done. And I would prefer to just submit
rather than have you rewrite, as I can then factor common code out of
that and the string literal interp (and maybe parse, but I am
suspicious...)

> I will not consider the previous objections of Daniel and Geir
> with the following reasoning (so please re-vote for this proposal):
> >Daniel wrote:
> > I am -1 on a eval directive--functionality such as that should not be
> > available to a template engineer.  They are around to make things look
> > pretty, and this is not a tool from their bag of tricks.
> That is the reason for having configurable and pluggable directives.
> This feature/trick will be used by anakia and other VSL users and
> not by normal HTML template writers.

Well.... I can't speak for daniel, but this might be the right place to
reconnect the view layer and the app with a context tool.

> >Geir wrote:
> > I agree.  When things are getting that complicated in View-land, it's
> > time to ask for help from elswhere in the app..
> This is why I'm proposing a pluggable directive here. If you mean
> elswhere by saying it should be a ContextTool, I'm willing also to
> do as sucht if you think that is the right approach. let me know.

If we do do this, I think it should be a PD, not a contextTool.  I am -1
about a context tool parsing and rendering, because that is what
Velocity is supposed to be for in the first place :)  We should get
velocity right before that kind of architecture hack.

> [snip]
> Geir, if you could give me a hint on how to do the #eval
> implementation - accessing a macro from the code - without
> having to compile a template with the string and the merging
> it, i would be thankful for it.

I can send you the working implementation :)

I apparently wrote :
> > is, I believe, currently outside of the general consensus of what
> > VTL allows.  I think that if we do want that sort of facility, it
> > should be a new directive, such as #eval( ... ) or similar to both
> > make clear what the template author intends as well as make easy
> > the ability to shut it off.
> This is the proposal I'm making here!

Hm. I  *thought* it had already been suggested.  I couldn't find the
post, so figured that I typed it and erased it, or just imagined it. 
(The little voices confuse me sometimes... :)

I guess if we *really* need this, #eval() is the way to go. 

<long winded commentary>
It certainly works well, but I fear that we are slowly (nay, rapidly)
moving towards YALTEWATTDE ( "Yet Another Large Template Engine Which
Always Tries To Do Everything" ) and I am not for that.  My hopes are a
small, fast and light general/generic template engine that you can embed
in apps, where the app provides use-specfic functionality when needed. 
Of course, I am just one guy, and a latecomer at that, so take the above
for what it's worth.

I know that the primary use of Vel for me is in the web space,
specifically in web development via servlets, and a primary foundation
of the Vel philosophy is to keep things simple and safe  - this is what
attracted me here.

Of course, you can always 'turn off' PDs, so adding it as a PD could
arguably be a config issue.  But to the user, it's a VTL directive.  The
fact that they are cleverly inplemented as PDs doesn't matter.  I know I
made the same argument in favor of VMs, that you can turn them off, but
I think they are different, as I still like to think of them simply as
an auto cut and paste for designers.  Wackos like Jon use them for other
sinister purposes, but, well, that's Jon.  I am glad they are so
flexible.

At some point, we prollie should have a 'user PD library' that is
external to the core Velocity distribution, maybe we maintain/host it,
maybe not, something like the limitless number of perl modules available
via CPAN.  But I don't think the time for that is now.  
</long winded commentary>

geir

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."

Re: [PROPOSAL] #eval directive [was Re: interpolation]

[Jon Stevens <jo...@latchkey.com>]

Sorry Christoph,

I am still strongly -1 on a #eval directive.

However, I do want to have a place on our Velocity website where people can
link to their own websites where they have their own Directives and make
them available for people. I don't want to stifle that type of contribution.

What I want to do with Anakia can be done entirely in Java if I can have
access to the #macro's from within Java. Therefore, that is the approach I
would much rather take. Going with #eval moves us towards a
scripting/procedural language and that is NOT the direction I want to go.

thanks,

-jon

-- 
twice of not very much is still a lot more than not very much