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