Hmm. Do you have directive.set.null.allowed = true in your velocity.properties?
If so, then yes, please open a bug report. But also, please consider testing this with 1.6 (unreleased), to see if it still exists there. You can find an unreleased test build of 1.6-beta1 here: http://people.apache.org/~nbubna/velocity/engine/1.6-beta1/ On Tue, Sep 16, 2008 at 8:08 AM, Guillaume Polet <[EMAIL PROTECTED]> wrote: > Hi list, > > I have been using Velocity for quite a while and we have recently gone to > the 1.5 version (from a custom 1.4 version). We also have completely > refactored our code and our templates and we use velocity quite intensively > to generate code. We now have a model-driven code generation that uses > macros combined with #parse to generate our code. > Basically, I have one or several templates for each type of object of our > model, and I render each object by merging it with a template. > I have a macro that is call "render" to which I pass an object and the macro > is responsible to render that object. The macro knows which template goes > with which object and invoke the #parse() directive with the proper > template. This goes recursively until my whole object tree has been parsed > and rendered. > > However, I found out recently that when you do a #set($something = $null), > if $something was declared in a higher template and $null is undefined, > $something will not take the null value but simply tries to remove the > reference from the vmproxyhash Hashmap. Although $something may be defined > in another context (for example the innerContext) and therefore I obtain > very strange behaviors because you expect something to be null. This little > snippet illustrates those strange behaviors: > > ## $something has been declared in another template (potentially the same, > since the way I use Velocity template is recursive) > #set($something = $myObject.getSomething()) ## getSomething() returns null > #if($something) > foo bar > ... > #end > > even if getSomething() returns null, $something won't be null and the > #if-block after will be rendered. This is of course unwanted and quite hard > to predict. > So far, the only solution I have found is to set the variable to false > before invoking the method, but I find it rather ugly. > > IMHO, the method remove(Object) in VMContext should be similar to the > get/put methods. A cleaner way to do all this, should be a new property that > allows us to use or not chained-context. > > Is there a way to bypass chained-context? or a way to set null values on the > contexts embedded by the VMContext? should I fill a bug report? > > > Thank in advance, > > > -- > Guillaume Polet > > > */Denali /*/s.a., "Human centred solutions that bridge the gaps between > Business, IT and Management"/ > Rue de Clairvaux 8, B-1348 Louvain-la-Neuve, Belgium > Office: +32 10 43 99 51 Mob: *+32 495 57 51 84* Fax: +32 10 43 99 52 > Web: www.denali.be <http://www.denali.be/> www.flexoBPM.com > <http://www.flexoBPM.com> > Email: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
