"Geir Magnusson Jr." wrote:
>
> Below is a (long) proposal for macro capabilities for Velocity. I have
> attached code that works with the current CVS tree. Please give a read
> through, ask questions if interested and try it if you have the time. I
> am looking for list approval to get this integrated into Velocity.
>
> Introduction
> ------------
> Recently, during the discussion extensions to the Velocity template
> language, the subject of adding a macro capabilities to the language was
> introduced, and a few solutions were offered :
>
> 1) Reference-accessed toolsets : $toolset.foo( $i ) : This involves
> using a set of objects presumably written in Java provided for the
> designer that do certain things. In the case of the problem that
> started the discussion ($!email), then $toolset.isnull( $email ) would
> result in $email being output into the output stream if it was a valid
> reference in the context, or an empty string if not.
>
> 2) Velocimacros : another approach ( offered by me), recognizes that in
> this case, $!email, the solution can be represented entirely w/in
> Velocity template language (hereafter VTL) :
>
> #if( $email )
> $email
> #end
>
> Further, when exploring this subject in much animated detail on the
> list, it grew apparent, at least to me, that there is a need for
> allowing a VTL macro expansion facility to allow those people
> responsible for the View layer of the M-V-C design pattern to
> encapsulate VTL snippets into named entities and use them within their
> templates.
Actually there was third one discussed here: formatters;
This problem can be gracefully solved within formatter concept by defining formatters
for all null values or for null values for variables matching particular mask.
It is completely configuration-based so this need not be taken care of by template
designer and you can configure different behavior in different environments (display
err message in development but silently skip it in production) without _any_ changes in
templates. I believe such behavior is often desirable.
I remember people criticizing, for example, freemaker for the ability to define
functions, and I totally agree with it. KISS. Let's not make Velocity another mammoth.
Macroses just do not belong here.
So, as you could guess I am strongly -1 if I have a vote.
WBR, fedor.
