+1, to add the #local directiove to the core; quoting from below:
"find it very usefull to develop reusable macro libraries" ...
without having to prefix "all local variable names to avoid
collisions."
Being honest, I haven't tested it yet, currently I'm doing it
the hard way - using prefixes, then after the template doing
$context.remove(...) on them to avoid polluting the keyspace.
That is why I'm asking if it is sensible to use chained contexts
and allowing an empty #local()...#end that makes all variables
defined or modified inside the block (macro or parse) to no touch
the globals - this would be the most common case then.
Blocks that need to return an updated variable can use an INOUT
ArrayList:
#set( $returnValue = [] )
#myMacroCall( $foo $bar $returnValue )
#if( ! $returnValue.isEmpty )
## do something...
#end
--
:) Christoph Reck
Claude Brisson wrote:
- #local directive
no... :)
Okay.
:)
Sorry - I didn't mean to be that abrupt. See above re the tools - are
there really enough people using #local that it warrants inclusion in
the core? I threw that together in about 10 minutes, if I remember.
That people are using it is thrilling (and scary... :) but I think that
tools would be a great place.
I do agree that tools could be the place for it, but Local.java has to be located in a core package, as long as
directives.properties.
I did not encounter any bug with it (you achived a quick and clean coding shot, Geir :-) and find it very usefull to develop
reusable macro libraries, to my mind (a good alternative to the necessity of prefixing all local variable names to avoid
collisions...).
CloD
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
:) Christoph Reck
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
