You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Guillaume Polet <gu...@gmail.com> on 2008/09/16 17:08:35 UTC
VMContext does not set null values
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: guillaumedenali@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: VMContext does not set null values
Posted by Guillaume Polet <gu...@gmail.com>.
Nathan Bubna a écrit :
> On Wed, Sep 17, 2008 at 8:34 AM, Nathan Bubna <nb...@gmail.com> wrote:
>
>> On Wed, Sep 17, 2008 at 3:49 AM, Guillaume Polet
>> <gu...@gmail.com> wrote:
>>
>>> Yes the property "directive.set.null.allowed" was set to true in my property
>>> file.
>>> I have replaced the jar velocity-1.5.jar by the 1.6-beta1, and this works
>>> fine now. So thanks very much for such a quick answer. Indeed, the method
>>> remove(Object) in VMContext (now ProxyVMContext) has been modified to be
>>> similar to get/put methods.
>>>
>> excellent!
>>
>>
>>> I have a few other questions though:
>>> 1) Is the 1.6-beta1 release of velocity reliable? I have made a few tests
>>> which seems conclusive but are there any known bugs?
>>>
>> https://issues.apache.org/jira/browse/VELOCITY-587
>> (but this was present in prior versions as well)
>>
OK, 9 issues seems quite acceptable (I have over 400 in my app, so I
don't mind a few more, especially so minor ones )
>>
>>> 2) How do I generate #something(Stuff) without having a '\' rendered in
>>> front of it? If I simply put in the template #something(Stuff), I get a
>>> parse exception (which did not occur before in 1.5), and if I put
>>> \#something(Stuff), it is rendered as \#something(Stuff) (but I don't want
>>> the '\' to be rendered actually)
>>>
>> i would argue that you have found another bug. here's a quick workaround:
>>
>> #set( $H = '#' )## this could be set anywhere
>> ${H}something(Stuff)
>>
Didn't think about that, but excellent idea.
>> Still, would you open a bug report on this?
>>
Ok, I opened the bug report.
>>
>>> Also, I was surprised that macros were depth-limited by default to 20
>>> although before it wasn't the case. I have found that I could set the
>>> property "velocimacro.max.depth" to 0 to have it unlimited but it is kind a
>>> weird to set that value to 20 by default. The same goes for parse (but that
>>> was already the case in 1.4 and 1.5). Btw, there is no way to make an
>>> unlimited depth for parse, although one could expect to have a similar
>>> behavior to the one used by macros.
>>>
>> Do you have a better default value suggestion for limiting macro depth?
>> Also, it would not be hard to make it so that parse allows infinite
>> recursion when
>> the value is <= 0, would this really be useful to you?
>>
>
> i went ahead and made it so a directive.parse.max.depth <= 0 will turn
> off the parse depth limit.
>
You 're the best! This is actually useful for me because I have no
limits in my model, so, technically, I cannot predict a maximum limit
(but I think it is correct to say that I will never exceed a few thousands).
Again, many thanks,
Guillaume
>
>>> Anyway, many thanks for this great job. Keep it up that way.
>>>
>>>
>>> Guillaume
>>>
>>> Nathan Bubna a écrit :
>>>
>>>> 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
>>>> <gu...@gmail.com> 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: guillaumedenali@gmail.com
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: VMContext does not set null values
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Sep 17, 2008 at 8:34 AM, Nathan Bubna <nb...@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 3:49 AM, Guillaume Polet
> <gu...@gmail.com> wrote:
>> Yes the property "directive.set.null.allowed" was set to true in my property
>> file.
>> I have replaced the jar velocity-1.5.jar by the 1.6-beta1, and this works
>> fine now. So thanks very much for such a quick answer. Indeed, the method
>> remove(Object) in VMContext (now ProxyVMContext) has been modified to be
>> similar to get/put methods.
>
> excellent!
>
>> I have a few other questions though:
>> 1) Is the 1.6-beta1 release of velocity reliable? I have made a few tests
>> which seems conclusive but are there any known bugs?
>
> https://issues.apache.org/jira/browse/VELOCITY-587
> (but this was present in prior versions as well)
>
>> 2) How do I generate #something(Stuff) without having a '\' rendered in
>> front of it? If I simply put in the template #something(Stuff), I get a
>> parse exception (which did not occur before in 1.5), and if I put
>> \#something(Stuff), it is rendered as \#something(Stuff) (but I don't want
>> the '\' to be rendered actually)
>
> i would argue that you have found another bug. here's a quick workaround:
>
> #set( $H = '#' )## this could be set anywhere
> ${H}something(Stuff)
>
> Still, would you open a bug report on this?
>
>> Also, I was surprised that macros were depth-limited by default to 20
>> although before it wasn't the case. I have found that I could set the
>> property "velocimacro.max.depth" to 0 to have it unlimited but it is kind a
>> weird to set that value to 20 by default. The same goes for parse (but that
>> was already the case in 1.4 and 1.5). Btw, there is no way to make an
>> unlimited depth for parse, although one could expect to have a similar
>> behavior to the one used by macros.
>
> Do you have a better default value suggestion for limiting macro depth?
> Also, it would not be hard to make it so that parse allows infinite
> recursion when
> the value is <= 0, would this really be useful to you?
i went ahead and made it so a directive.parse.max.depth <= 0 will turn
off the parse depth limit.
>> Anyway, many thanks for this great job. Keep it up that way.
>>
>>
>> Guillaume
>>
>> Nathan Bubna a écrit :
>>>
>>> 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
>>> <gu...@gmail.com> 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: guillaumedenali@gmail.com
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: VMContext does not set null values
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Sep 17, 2008 at 3:49 AM, Guillaume Polet
<gu...@gmail.com> wrote:
> Yes the property "directive.set.null.allowed" was set to true in my property
> file.
> I have replaced the jar velocity-1.5.jar by the 1.6-beta1, and this works
> fine now. So thanks very much for such a quick answer. Indeed, the method
> remove(Object) in VMContext (now ProxyVMContext) has been modified to be
> similar to get/put methods.
excellent!
> I have a few other questions though:
> 1) Is the 1.6-beta1 release of velocity reliable? I have made a few tests
> which seems conclusive but are there any known bugs?
https://issues.apache.org/jira/browse/VELOCITY-587
(but this was present in prior versions as well)
> 2) How do I generate #something(Stuff) without having a '\' rendered in
> front of it? If I simply put in the template #something(Stuff), I get a
> parse exception (which did not occur before in 1.5), and if I put
> \#something(Stuff), it is rendered as \#something(Stuff) (but I don't want
> the '\' to be rendered actually)
i would argue that you have found another bug. here's a quick workaround:
#set( $H = '#' )## this could be set anywhere
${H}something(Stuff)
Still, would you open a bug report on this?
> Also, I was surprised that macros were depth-limited by default to 20
> although before it wasn't the case. I have found that I could set the
> property "velocimacro.max.depth" to 0 to have it unlimited but it is kind a
> weird to set that value to 20 by default. The same goes for parse (but that
> was already the case in 1.4 and 1.5). Btw, there is no way to make an
> unlimited depth for parse, although one could expect to have a similar
> behavior to the one used by macros.
Do you have a better default value suggestion for limiting macro depth?
Also, it would not be hard to make it so that parse allows infinite
recursion when
the value is <= 0, would this really be useful to you?
> Anyway, many thanks for this great job. Keep it up that way.
>
>
> Guillaume
>
> Nathan Bubna a écrit :
>>
>> 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
>> <gu...@gmail.com> 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: guillaumedenali@gmail.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: VMContext does not set null values
Posted by Guillaume Polet <gu...@gmail.com>.
Yes the property "directive.set.null.allowed" was set to true in my
property file.
I have replaced the jar velocity-1.5.jar by the 1.6-beta1, and this
works fine now. So thanks very much for such a quick answer. Indeed, the
method remove(Object) in VMContext (now ProxyVMContext) has been
modified to be similar to get/put methods.
I have a few other questions though:
1) Is the 1.6-beta1 release of velocity reliable? I have made a few
tests which seems conclusive but are there any known bugs?
2) How do I generate #something(Stuff) without having a '\' rendered in
front of it? If I simply put in the template #something(Stuff), I get a
parse exception (which did not occur before in 1.5), and if I put
\#something(Stuff), it is rendered as \#something(Stuff) (but I don't
want the '\' to be rendered actually)
Also, I was surprised that macros were depth-limited by default to 20
although before it wasn't the case. I have found that I could set the
property "velocimacro.max.depth" to 0 to have it unlimited but it is
kind a weird to set that value to 20 by default. The same goes for parse
(but that was already the case in 1.4 and 1.5). Btw, there is no way to
make an unlimited depth for parse, although one could expect to have a
similar behavior to the one used by macros.
Anyway, many thanks for this great job. Keep it up that way.
Guillaume
Nathan Bubna a écrit :
> 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
> <gu...@gmail.com> 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: guillaumedenali@gmail.com
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: VMContext does not set null values
Posted by Nathan Bubna <nb...@gmail.com>.
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
<gu...@gmail.com> 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: guillaumedenali@gmail.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org