Nathan Bubna a écrit :
On Wed, Sep 17, 2008 at 8:34 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
On Wed, Sep 17, 2008 at 3:49 AM, Guillaume Polet
<[EMAIL PROTECTED]> 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
<[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]
---------------------------------------------------------------------
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]
