4 Jan
2012
4 Jan
'12
1:07 a.m.
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
4 Jan
4 Jan
4:01 a.m.
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:
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#H…
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
#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?
13 Mar
13 Mar
9:40 p.m.
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#H…
14 Mar
14 Mar
11:47 a.m.
On Tue, Mar 13, 2012 at 9:40 PM, Paul Libbrecht <paul(a)hoplahup.net> 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 :
--
Jean-Vincent Drean,
XWiki.
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#H…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
4 Jan
4 Jan
8:24 a.m.
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 <paul(a)hoplahup.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:13 a.m.
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 <paul(a)hoplahup.net> 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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs #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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:16 p.m.
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:
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
29 Feb
29 Feb
10:36 p.m.
New subject: [xwiki-devs] Velocity analysis tools? (was: Re: surprise change velocity 1.5 => 1.7)
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). 
1 Mar
1 Mar
8:24 a.m.
New subject: [xwiki-devs] Velocity analysis tools? (was: Re: surprise change velocity 1.5 => 1.7)
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).
4569
days inactive
4639
days old
8 comments
5 participants
participants (5)
-
Jean-Vincent Drean -
Ludovic Dubost -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol