Hi,
Just my 2c. When the idea #macro was introduced I thought that it was a
good idea. I can see how #macro's can save enormous amounts of time and
make everybody's like a little easier.
But after a bit of thought I came up with the problem with maintenance.
Without #macro's in a template you know that the only place something can go
wrong is in the Java code. If you add #macro to templates you inevitably
add the ability to include libraries of #macro's and therefore another layer
of potential bugs.
I guess it is a matter of who is writing templates. It is also a question
of how templates are used: html templates or code generation or whatever. I
believe, like in our own company, a lot of template writing is done by
programmers and ex-programmers.
Would it be possible to add a property to the velocity.properties file that
would allow / disallow #macro's? I feel that this property should disallow
#macro's by default. Only when a guy understands Vel well enough to change
the .properties file is he entitled to use #macro :-)
~ Leon
On the other hand > John McNally wrote:
> >
> > "Geir Magnusson Jr." wrote:
> > >
> > > This is another request for discussion and vote on the topic of a
macro
> > > expansion facility to Velocity. This should be a 'more complete'
> > > definition of the proposal. Currently, code exists to support
> > > everything mentioned in this proposal.
> > >
> > >
> >
> > Can you explain the difference between a Velocimacro and a function in
> > the FreeMarker sense? They seem fairly similar to me. I was under the
> > impression that functions were considered something too complex for a
> > layer meant for use by designers.
>
> To be frank, I am unfamiliar with FreeMarker. I did read what I think
> are the correct docs, and they appear to be fairly similar. I assume
> that with a FreeMarker function, any valid template code is allowed
> within a function?
>
> The only differences I can see are that :
>
> 1) In the present not-yet-approved implementation, VMs don't conflict
> with the reference / 'variable' namespace.
>
> 2) They are accessed like the other directives :
> #foo( $i )
> rather than via an additional construct <set foo( i ) > ( I think this
> is what you do in FreeMarker ).
>
> I guess re the complexity issue, no, I personally don't believe that,
> within limits. Because nothing but template code is used, the toolset
> really isn't expanded : they can't do any more damage than they can with
> cut and paste...
>
> geir
