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
<[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
