[xwiki-devs] surprise change velocity 1.5 => 1.7
Hello fellow developers, I am working on upgrading our core, based on xwiki 1.5.4 to xwiki 3.2. Quite a jump. Among the least jump, velocity seems to have jumped from version 1.5 to version 1.7. Nonetheless, this seems to cause a surprising effect: while macros could redefine the value of parameters they were passed, and that change was honoured after the macro, they cannot anymore. The following script:
#macro(redefine $var) #set($var="redefined") #end
#set($x="original")
x is $x
#redefine($x)
x is $x
gives the following output in a new core:
x is original
x is original
and the following in our old core:
x is original
x is redefined
This has all sorts of consequences including such macros as the navigation not receiving the result of normalizelink... Did I miss an optional parameter of velocity to revert to the old method? paul
On 01/03/2012 07:07 PM, Paul Libbrecht wrote:
Hello fellow developers,
I am working on upgrading our core, based on xwiki 1.5.4 to xwiki 3.2. Quite a jump.
Among the least jump, velocity seems to have jumped from version 1.5 to version 1.7.
Nonetheless, this seems to cause a surprising effect: while macros could redefine the value of parameters they were passed, and that change was honoured after the macro, they cannot anymore.
The following script:
#macro(redefine $var) #set($var="redefined") #end
#set($x="original")
x is $x
#redefine($x)
x is $x
gives the following output in a new core:
x is original
x is original
and the following in our old core:
x is original
x is redefined
This has all sorts of consequences including such macros as the navigation not receiving the result of normalizelink...
Did I miss an optional parameter of velocity to revert to the old method?
Hi Paul, Yes, this is something known, and there are workarounds to the change, but there's no easy way of reverting to the old behavior. The way we used macros wasn't something (at least some of) the Velocity developers expected to actually happen, and they didn't want to support the old way macros were evaluated, so this change had to happen. Here you can see the problem explained in more details, along with some solutions: http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise30#HT... -- Sergiu Dumitriu http://purl.org/net/sergiu/
hello XWikiers, I started writing an analyzer based on velocidoc. It gives me the line-numbers and file-names as in an error report, easy to click to. I'll try to put it into: https://github.com/xwiki-contrib/sandbox/tree/master/velocidoc quite soon. Unfortunately, I do not have a tool yet to extract the source from the xwiki-pages massively... Another surprise change is: #if($!request.language!="") has-language #else has-no-language #end was returning has-no-language if the language parameter was not included but now returns has-language. The simple workaround is to put quotes around the left-hand-side thus making sure strings are compared. Acknowledge? I'll put this into the web-page then. paul Le 4 janv. 2012 à 04:01, Sergiu Dumitriu a écrit :
Yes, this is something known, and there are workarounds to the change, but there's no easy way of reverting to the old behavior. The way we used macros wasn't something (at least some of) the Velocity developers expected to actually happen, and they didn't want to support the old way macros were evaluated, so this change had to happen.
Here you can see the problem explained in more details, along with some solutions: http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise30#HT...
On Tue, Mar 13, 2012 at 9:40 PM, Paul Libbrecht <[email protected]> wrote:
hello XWikiers,
I started writing an analyzer based on velocidoc. It gives me the line-numbers and file-names as in an error report, easy to click to. I'll try to put it into: https://github.com/xwiki-contrib/sandbox/tree/master/velocidoc quite soon. Unfortunately, I do not have a tool yet to extract the source from the xwiki-pages massively...
Another surprise change is: #if($!request.language!="") has-language #else has-no-language #end was returning has-no-language if the language parameter was not included but now returns has-language. The simple workaround is to put quotes around the left-hand-side thus making sure strings are compared.
Acknowledge?
Hi, FWIW I've always used and seen this comparison, even prior to the velocity upgrade you mention: #if("$!request.language" != '') JV.
I'll put this into the web-page then.
paul
Le 4 janv. 2012 à 04:01, Sergiu Dumitriu a écrit :
Yes, this is something known, and there are workarounds to the change, but there's no easy way of reverting to the old behavior. The way we used macros wasn't something (at least some of) the Velocity developers expected to actually happen, and they didn't want to support the old way macros were evaluated, so this change had to happen.
Here you can see the problem explained in more details, along with some solutions: http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise30#HT...
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean-Vincent Drean, XWiki.
Hi paul, There should be some code for adapting the curriki code to this in the trunk. Ludovic Envoyé de mon iPhone Le 4 janv. 2012 à 02:07, Paul Libbrecht <[email protected]> a écrit :
Hello fellow developers,
I am working on upgrading our core, based on xwiki 1.5.4 to xwiki 3.2. Quite a jump.
Among the least jump, velocity seems to have jumped from version 1.5 to version 1.7.
Nonetheless, this seems to cause a surprising effect: while macros could redefine the value of parameters they were passed, and that change was honoured after the macro, they cannot anymore.
The following script:
#macro(redefine $var) #set($var="redefined") #end
#set($x="original")
x is $x
#redefine($x)
x is $x
gives the following output in a new core:
x is original
x is original
and the following in our old core:
x is original
x is redefined
This has all sorts of consequences including such macros as the navigation not receiving the result of normalizelink...
Did I miss an optional parameter of velocity to revert to the old method?
paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
That'd be fantastic, 1) what would be the replacement (some scope variables in macros?) 2) please point me to such code, we have quite a few other maintenance needs for the velocity code and tool-supporting this would be really helpful! paul Le 4 janv. 2012 à 08:24, Ludovic Dubost a écrit :
Hi paul,
There should be some code for adapting the curriki code to this in the trunk.
Ludovic
Envoyé de mon iPhone
Le 4 janv. 2012 à 02:07, Paul Libbrecht <[email protected]> a écrit :
Hello fellow developers,
I am working on upgrading our core, based on xwiki 1.5.4 to xwiki 3.2. Quite a jump.
Among the least jump, velocity seems to have jumped from version 1.5 to version 1.7.
Nonetheless, this seems to cause a surprising effect: while macros could redefine the value of parameters they were passed, and that change was honoured after the macro, they cannot anymore.
The following script:
#macro(redefine $var) #set($var="redefined") #end
#set($x="original")
x is $x
#redefine($x)
x is $x
gives the following output in a new core:
x is original
x is original
and the following in our old core:
x is original
x is redefined
This has all sorts of consequences including such macros as the navigation not receiving the result of normalizelink...
Did I miss an optional parameter of velocity to revert to the old method?
paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Le 4 janv. 2012 à 11:13, Paul Libbrecht a écrit :
1) what would be the replacement (some scope variables in macros?)
I got it, thanks Sergiu for the URL:
http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise30#HT...
which allows me to rewrite my test macro working the old way with the following: #macro(redefine $var) #set($result="redefined") #set ($var = $util.null) #setVariable ("$var" $result) #end #set($x="original") x is $x #redefine($x) x is $x
2) please point me to such code, we have quite a few other maintenance needs for the velocity code and tool-supporting this would be really helpful!
This remains an interesting open question. I know we have quite a few other velocity analysis needs (e.g. the fact that some calls to msg.get are not sufficiently escaped for some languages). thanks for hints. Paul
Hello fellow developers, please let me insist here. What kind of tool is available out there to analyze velocity sources? I tried going by hand through all the macros of just macros.vm and this is porky long and Curriki has about 100 times this. A tool to detect (in this case) calls to the set directive on a variable name that is a parameter would really be useful! I'd have enough with an access to some structure tree given a .vm input-stream. thanks in advance paul Le 4 janv. 2012 à 12:16, Paul Libbrecht a écrit :
2) please point me to such code, we have quite a few other maintenance needs for the velocity code and tool-supporting this would be really helpful!
This remains an interesting open question. I know we have quite a few other velocity analysis needs (e.g. the fact that some calls to msg.get are not sufficiently escaped for some languages).
On Feb 29, 2012, at 10:36 PM, Paul Libbrecht wrote:
Hello fellow developers,
please let me insist here. What kind of tool is available out there to analyze velocity sources?
None that I know of (haven't googled though). Ludovic had created a velocity javadoc tool to document velocimacros (velocidoc) but that's the only one I know of.
I tried going by hand through all the macros of just macros.vm and this is porky long and Curriki has about 100 times this. A tool to detect (in this case) calls to the set directive on a variable name that is a parameter would really be useful!
I'd have enough with an access to some structure tree given a .vm input-stream.
Since Velocity is based on a javacc parser there might be possibilities to access the internal structure tree. -Vincent
thanks in advance
paul
Le 4 janv. 2012 à 12:16, Paul Libbrecht a écrit :
2) please point me to such code, we have quite a few other maintenance needs for the velocity code and tool-supporting this would be really helpful!
This remains an interesting open question. I know we have quite a few other velocity analysis needs (e.g. the fact that some calls to msg.get are not sufficiently escaped for some languages).
participants (5)
-
Jean-Vincent Drean -
Ludovic Dubost -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol