Christoph :
> My experience shows me these situations where a NULL can happen.
> a) The template designer has written an invalid identifyer:
> #set( $foo = $bar.woobie )
> where getWoobie() does not exists. here it is sufficient that
> its logged...
Yes, that will be logged. It is actually checked before it's shoved into
the context, so the only issue there is that $foo is still not in the
context if it wasn't, or unchanged if it is. Maybe to support the semantics
of 'no null references' we just remove $foo from the context ?
> b) Sometimes there are existing beans that may return NULL (e.g.
> upon connection timeout, exception, unavailability, etc.), here a:
> #set( $result = $bean.hunt("fox") )
> could return NULL and with your proposal would leave the
> $result reference unexpectedly unchanged.
That's true. I try to get my data setup ahead of time, but I realize that
isn't how everyone wants to work, and certainly is in conflict with the
'pull API' approach. It's just a personal thing, so I can handle error
conditions in Java rather than in the template.
> - This would require error prone review/rewriting of all objects
> and methods used within the context.
true
> + If NULL would be allowed as values, a following:
> #if( $result )
> Your hunt returned $result.brown brown foxes and $result.black
foxes.
> #else
> You returned with empty hands from your hunt.
> #end
> could be used to gracefully handle the problem.
right. Hm. Maybe if you do what amounts to a #set( $foo = <null value
returned from something> ) then we remove $foo from the context if it is
there? That would support the semantics, be predictable, etc. This strikes
me as a little yecchy though, somehow, although in some ways clean : there
are no null objects in the context. It also makes the proposed addition of
#if( $foo == NULL)
as a not-a-reference check clean.
Just to clarify ( as this was another thread at one point ) :
It's seems fine that if something isn't in the context
#if( $foo )
is a valid way to check if you can *use* it. But that's different than if
you really need to answer the question "Is this in the context." They
actually are two different questions, the latter mostly used in debugging or
less obvious applications. The former is the most common.
> A more sensible example within a turbine application would be:
> #set( $cachedObject = $data.Session.getAttribute("name") )
> #if ( !$cachedObject )
> #set( $cachedObject = $Factory.createObject() )
> #set( $dummy = $data.Session.setAttribute("name", $cachedObject) )
> ## rather use #call( $data.Session.setAttribute("name",
$cachedObject) )
> #end
> ## now you can use the $cachedObject any way you want...
So 'setting $cachedObject to null' via removal from the context by #set()
would solve that but we would still need to decide on what to do about
#if(!$cacheObject) as you can't trust it. It's not a null checker, it's a
boolean evaluator. (See above )
More inline:
> "Geir Magnusson Jr." wrote:
>>
> > We had a bit of discussion before the holidays, and figure we should
revisit
> > the following :
> >
> > How should we define the Context handling of null keys and values? Lets
> > forget about if we are implemented via a HashMap, a Hashtable or a DB
> > (because after tonight, you can use and mix all three..) but how we
want
> > the Context API to be formally defined.
> >
> > I think :
> >
> > 1) If you try a put( null, obj ) or put( key, null ) or put(null,
null)
> > then nothing should be altered in the context, and conditionally, this
would
> > be logged as a warning. (Condition is a switch in the props file,
default
> > off or on or whatever :)
> +1 for avoiding put( null, obj )
meaning "If you just return null and drop it, that's ok" ?
> -1 for inhibitting put( key, null ).
Why? I don't get the value of adding null into the context. I mean, we
could support it, just pushing the onus (I like to be able to use that word
outside of sailboat racing...) on the Context implementor. HashMap deals,
and that's what the new VelocityContext is, but if someone tried to do a
Hashtable based impl, they would need a magic cookie to store in the context
as a placeholder. Easy to do, I guess.
But I still don't get why I would need this.
I guess it's 'complete' from the java sense, but from the template /
designer side, does this make sense? Further, then if we want to support
the notion of 'Is this reference in the context?', we have another check
thatn #if( $foo == NULL) or decide it's a meaningless and confusing
question, in that while semantically they aren't the same, functionally they
are.
>>
>> 2) if you do a get( null ) you should be returned null and conditionally
>> have this logged.
> +1 This would be a feasible approach. For development this sould do logs,
> whereas in the runtime it could be disabled. Allowing the (template)
>developers track problems, and then leave the runtime performant.
Yep, exactly.
[SNIP]
>Somebody already said in this list "NULL is your friend".
That was Jose or Daniel, I think. I don't quite get why though. I do in
Java, but in template land? I guess one will be able to find uses, but if
you formalized things from the Java side by adding booleans to tell you
about valid data... I dunno. That's extra work. Just hoping to get things
clean, and describable in documentation in as few lines as possible.
geir
