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...
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.
- This would require error prone review/rewriting of all objects
and methods used within the context.
+ 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.
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...
"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 )
-1 for inhibitting put( key, null ).
>
> 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.
>
> In other words, I can't think of a valid reason to accept null as either key
> or value. One could say that it's meaningful to distinguish between
> something being in the context and null, and not being in the context, but I
> don't personally see it. It sounds like we are encouraging a dependency
> upon a side effect of sorts.
>
> Further, to keep the implementation of new kinds of contexts easier, having
> these restrictions results in simpler requirements for context
> implementation.
Somebody already said in this list "NULL is your friend".
>
> geir
:) Christoph
