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) > 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 >> <[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]
