velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Reck <Christoph.R...@dlr.de>
Subject Re: Quiet reference in set
Date Wed, 07 Mar 2001 08:17:02 GMT
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

Mime
View raw message