> > -0, I can very well imagine VMs updating the parent context (more below).
> > Whereas the tools and defaults set up as a base context should be
> read-only.
>
> Are we talking about the same thing?
don't know? Jose gave the example:
> > > #macro(m1 $p1)
> > > #local($a)
> > > $set( $a = $p1 )
> > > $set( $appVar = $a + $a )
> > > #end
>[snip]
> > Singleton pattern with a private constructor:
Jose's example is not serialization safe, equals() will not work:
> > > public static final Object NULL = new Object();
That's why I provided an example of a *real* singleton in Java.
>[snip]
> > Now it could be simply #if ($foo == $NULL), no change in the parser!
>
> yes, but then we have a 'special' reference we have to document. If it's
> a parser token, then $NULL can be used for other things by the users.
>>[snip in from Jose + geir's response]
>> > ?$foo was thumped but mine was $?foo ;-)
>> or somesuch which is pretty clear - doesn't take much guesswork to
>> figure it out... That would be the case of a manual-free grammar - you
>> don't need a manual.... sorry. couldn't resist.
Well you would have to code the #if($foo==NULL) and then document it
in the VTL Reference Guide. Note that the $NULL context variable is
application specific and is only needed if the template designer
requires this feature!
>[snip]
> > Please note that sometimes returing null is desireable:
> > #set( $dummy = $hastable.put("KEY", "woobie") )
> > Do I have to place a bang into $!hastable to avoid a message?
>
> No, you don't have to put a bang. That is only for rendering, and you are
> not rendering when you are on the RHS of a #set().
>
> And you can return a java null, and we will turn it into the NULL,
> internally. I guess I must not have been clear. Just like the app-level
> context API would convert java-null args to put(), get() to NULL internally,
> we would do the same in #set() for java-null returning refs and methods, as
> well as 'invalid' method invocations.
yes. I did understand it already earlyer.
But how do I avoid a log message if i still want to see other null usages
logged (therefore the bang?).
Using bang and rendering within a string will call the toString() of
the returned object erroneusly; note the undesireable side-effect of
turbines $link.toString():
#set( $dummy = "$!hastable.put("link", $link.clone())" )
>[snip]
> Can you give an example of functionality you wont have if the inner context
> is shielded from put()s by the 0th level context?
Jose gave the VTL examples, and I posted a list of usage examples separately.
>[snip]
> > yes, I will probably need a PD to make keys() visible in the template
> > (to dump the context using a template or WM!).
>
> Really? Why not just do soemthing like
> context.put("contextkeys", context.getKeys() );
> before merging????
won't work because it would not reflect the current context when chaining
is in effect. You are assuming that the context is static/freezed during
rendering! Having something like #local absoletes this assumption.
>[snip]
> > OK, but I would like a way to avoid logs (using bang? - example above).
>
> Turn of the logging? Just a thought...
I thought the bang was to avoid logs when nulls are returned during
a ASTReference.render.
[PROPOSAL] same should apply to a ASTSetDirective.render!
>>[snip in from Jose's mail + geir's response]
>> > Maybe we need something like #ignore( <expr> ) which causes the evaluation
>> > of expression but renders nothing. Well maybe ingore is not the best name
>> > ;-)
The #set (and its ASTSetDirective.render) requires allowing a bang to
avoid log messages; then use:
#macro(ignore $foo)#local($dummy)#set($dummy = $!foo)#end#end
>[snip]
> The local/end thing will be fixed soon w/o new directives (I hope:) There
> are a couple of related issues I want to knock off in one fell swoop.
I'm eager to find out how you will do it. See my note on this in the
"Context chaining examples" post.
I guess it could be what Jose once posted (within the VM rendering):
1. save the arguments that match ones in the current context,
2. evaluate the passes parameters and put them into context
(this would also avoid multiple evaluation of passed parameters)
3. render the macro
4. restore the saved arguments
>
> It's not a proggie lang. When you say 'return values' do you mean objects
> and such? Or can it just alter the context for you?
The 2nd.
The 1rst will allways will be possible! VTL has no influence here:
Note that poor-man's VTL-return-variables could be achieved via:
#macro( get $in $out )$out.add($in)#end
...
#set( $ret = [] ) ##assumes its now using a ArrayList behind sceenes!
#get("bar")
## now $ret.get(0) contains "bar"!
:) Christoph
