You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Christoph Reck <Ch...@dlr.de> on 2001/03/07 09:17:02 UTC
Re: Quiet reference in set
Note that I'm still hoping that the quiet reference for a set directive
finds its way into 1.0. The thread "[PATCH] ASTSetDirective to handle a bang"
was more visited (see summary below). Since there where no -1's, Geir could
you take over the patch.
Here three examples where I need it:
#set( $cache = $!session.getAttribute("applicationCache") )
## start a new cache if not yet defined...
...
#set( $state = $!guideExportStatus.put("state", "locked") )##set the lock
## test the $state if it was already locked...
...
#set( $taskXML = $!Xml.applyXPath($services, $xpathSpec).get(0) )
## now do something if the task was not defined...
In all of these three cases, a null return value is feasible, but
an error message in the log is undesireable.
bob mcwhirter wrote:
>
> Since I reckon I was the one who suggesting $!foo to start with, here's
> my rational of how this should work.
>
> ! applies to the operator it's glued to. $!foo means that if something
> goes wonky during the deref of 'foo', then don't complain.
This is also the way I see it. Bob also said it may be that #!set(...)
would reflect this behaviour, but I'm against making it more complicated.
Jon Stevens replied:
> I like that definition. I would be +1 then to having a #!directive to match
> having $!object for consistency.
Geir Magnusson Jr. replied:
> For references, using $! vs $ is a 'template engineer' decision, where
> they say "I don't want schmoo in the output if the reference isn't
> valid. It's ok if the reference isn't valid - I would check with #if()
> if I cared"
This also gets near to the definition I would like to see, but misses
the fact that a #set(...) is also a 'template engineer' decision,
where he should have the option to avoid log output if "the reference
isn't valid". Look at my examples above, an #if is not possible to check
beforehand (I know this is advanced VTL usage, but its up to the
designer to use it, I'm only recommending to make the $! usage more
homogenoeus throughout VTL).
>
> Whereas #!set($foo = $bar) is problematic, because now the template
> designer has determined that they don't want anything in the *log* if
> the *programmer* made an error, if indeed a null is unexpected.
This is a misinterpretation - due to the #!set(...) approach.
The way I see it is that $!foo stops log messages when it goes wrong
(raises and exception or returns null). As Bob said "don't complain".
I would also accept a form like #set( $!foo = $bar.mayReturnNull() ).
"Geir Magnusson Jr." wrote:
> The solutions I can think of :
>
> 1) Let it just go to the log (I assume you don't want to to do that.)
-1
> 2) Have a switch to turn off log blather in #set() - so do that for
> production.
-0, this is already in. But I want to log erroneus null assignments, only
where the designer knows it may be null (and non-null at other times), it
should be suppressed.
> 3) something like above
> 4) ?
Simply implement (patch has been sent in the past):
#set( $foo = $!bar.mayReturnNull() )
or
#set( $!foo = $bar.mayReturnNull() )
Note that there is no additional security risk, since within an #if() it
already goes by unnoticed.
:) Chirstoph