Christoph Reck wrote:
> 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.
ok.
> >[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!
the coding I am not worried about, although I see what you are saying.
just strikes me as kinda squishy to have it as a reference, that's all.
> >[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.
true : do this ->
context.put("context", context );
then in the template :
#foreach( $i in $context.getKeys() )
> >[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!
No. The bang says to velocity, "If this isn't a reference, don't render
the literal". So if a template was
-------
$blargh
$!blargh
--------
and blargh was not in the context, you would get
------
$blargh
------
becuase of the ! on the second blargh. Currently, we can't tell if
someting is not in the context, or it's value operation returns null, so
they get treated the same.
> >>[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
>
But that's not formally what bang does. The log is a separate issue.
An invalid render or #set is logged w/ or w/o the !. You can control
the logging from properties.
> >[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
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
