t kind of expected but not directly tested ones after
all XWiki integration tests are executed in a couple of hours.
Looks OK on that front too from what we can see. Well done :)
> Regression: Macro arguments names cannot collide with external referen
sted expected Velocity behaviors (AKA
xwiki-commons-velocity unit tests). We'll know more about kind of expected but
not directly tested ones after all XWiki integration tests are executed in a
couple of hours.
> Regression: Macro arguments names cannot collide with external referen
kind enough to test this snapshot version before I
push out the RC? Thanks.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
&g
$null)
$foo
Will always display 'foo' (w or w/o bc mode), while 1.7 did display $foo
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
>
0 AM:
--
When a naming collision occurs, there is a side effect which is that in 1.7,
global context values become default values for *missing* macro arguments.
Two people reported usecases where backward compatibility was broken because of
this 1.7 _undocumented feature_, so it
context values become default values for *missing* macro arguments.
Two people reported usecases where backward compatibility was broken because of
this 1.7 _undocumented feature_, so it's worth addressing.
The plan is to deprecate the 2.1 flag
{{velocimacro.arguments.preserve_literals}} in fav
it does not cover the other use cases discussed on the mailing list
regarding the macro local context it's still better than nothing.
> Regression: Macro arguments names cannot collide with external references
> names
> --
ussed on the mailing list
regarding the macro local context it's better still better than nothing.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
>
nothing.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELO
where you expect a
macro to keep its locally set values even if they are modified by external
macros or parsings.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
ntext which you said you did not wanted anymore even as a retro compatible
option.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VE
ehavior in 1.7 is a side effect of the local macro context which does not
exist anymore and I guess it not really easy to get back this behavior without
getting back the local macro context which you said you did not wanted anymore
even as a retro compatible option.
> Regression: Macro argument
yes I don't
have a strong use case to describe but any weird behavior always end up being
expected and used in 10 years :)
> Regression: Macro arguments names cannot collide with external references
> names
> --
ed in 10 years :)
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VE
had a side effect:
The following:
{code}
#macro (myMacro $myvar)
$myvar
#end
#set ($myvar = "value")
#myMacro()
{code}
produces:
* Before VELOCITY-926 and in 1.7: "value"
* After VELOCITY-926: $foobar
> Regression: Macro arguments names c
his kind of code in our codebase.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issue
would be useful, as opposed to just
supposing that it could perhaps break something somewhere. Again, since we're
*not* passing the argument, there is a strong logic in the fact that it remains
null inside the macro.
> Regression: Macro arguments names cannot collide with external re
ected and will break things.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apa
mple where the former behavior would be important
for backward compatibility?
Any change is important for backward compatibility. As usuall I'm not
discussing how valid this behavior is but the fact that this behavior is
expected and will break things.
> Regression: Macro arguments
t mention is that it also impacts the global
variables, so the following:
{noformat}
#macro (myMacro $myvar)
#end
#set ($myvar = "value")
#myMacro()
$myvar
{noformat}
also produces:
* Before VELOCITY-926 and in 1.7: "value"
* After VELOCITY-926: $myvar
> Regressi
vior. How, otherwise, would the macro know if it
has been given an argument?
Could you give me an example where the former behavior would be important for
backward compatibility?
> Regression: Macro arguments names cannot collide with external references
fect:
The following:
{code}
#macro (myMacro $myvar)
$myvar
#end
#set ($myvar = "value")
#myMacro()
{code}
produces:
* Before VELOCITY-926 and in 1.7: "value"
* After VELOCITY-926: $foobar
> Regression: Macro arguments names cannot collide with e
omas Mortagne for finding this bug.
Thanks you for the quick fix !
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
>
finding this bug.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/b
[
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELOCITY-926:
Fix Version/s: 2.2
> Regression: Macro arguments names cannot collide with exter
}}bar bar{{code}}, as if the first inner
{{code}}$foo{{code}} macro argument was overwritting the second argument
evaluation.
> Regression: Macro arguments names cannot collide with external references
> names
> --
Claude Brisson created VELOCITY-926:
---
Summary: Regression: Macro arguments names cannot collide with
external references names
Key: VELOCITY-926
URL: https://issues.apache.org/jira/browse/VELOCITY-926
e to explain :)
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
>
roduce it and move it to a new issue if confirmed.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/
last example [~cbrisson] ?
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
&g
The result I get is
Velocity 1.7: "value" followed by "value"
Velocity 2.2: "value" followed by "something"
So it's very clear for me that the first parameter of the macro was set to
$other and only then the expression passed as second parameter w
The result I get is
Velocity 1.7: "value" followed by "value"
Velocity 2.2: "value" followed by "something"
So it's very clear for me that the first parameter of the macro was set to
$other and only then the expression passed as second parameter w
result I get is
Velocity 1.7: "value" followed by "value"
Velocity 2.2: "value" followed by "something"
So it's very clear for me that the first parameter of the macro was set to
$other and then the expressed passed as second parameter w
en the expressed passed as second parameter was interpreted based
on this new value instead of the one the calling code was expecting.
> Add a flag for better backward compatibility with null macro arguments
> --
>
>
use case. You'll have to be more explicit, then.
What is defined beforehand and what is not? Which object does have a {{name}}
property?
> Add a flag for better backward compatibility with null mac
eans that the calling code uses names which are defined *inside*
the macro. Binding the calling code to the inner macro names means that you
wouldn't be able to rename macro arguments names without breaking calling code.
> Add a flag for better backward compatibility with null mac
ybe you are talking about the
default behavior ?
was (Author: tmortagne):
Not sure what you mean. Are you saying this behavior is expected ?
> Add a flag for better backward compatibility with null macro arguments
> -
you saying this behavior is expected ?
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/
ions than macros. Especially, the current
documentation is wrong on this subject and needs to be updated. It's not that
the `$test` argument shadows `$test.name`, it's that `$test.name` is evaluated
beforehand.
> Add a flag for better backward compatibility with nul
fore "$test.name" is interpreted so it breaks it (works fine when
>renaming the first parameter into $test2 or if $test is the parameter
>receiving the expression).
> Add a flag for better backward
ard compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Is
ity with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
>
ard compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue
want to provide such backward compat flags? Until
3.0?
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apa
ard compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Is
name
for booleans and numbers only - otherwise (for strings, arrays and maps) it's
the input argument literal itself...
This behavior can be implemented *except* for arrays and maps (there's a limit
to backward compatibility...).
> Add a flag for better backward compatibili
take that into account.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
&g
impact when
velocimacro.arguments.preserve_literals is true, since allowing nested macro
calls implies maintaining a stack of arguments literals for each argument.
> Add a flag for better backward compatibility with null macro argume
3 AM:
bq. I can't also help thinking that your use of null macro arguments is
somewhat a corner case of macro usages which is very specific to xwiki, but at
least it makes xwiki a good regression candidate.
Yeah I'm not very proud of that either but I have to wor
2 AM:
bq. I can't also help thinking that your use of null macro arguments is
somewhat a corner case of macro usages which is very specific to xwiki, but at
least it makes xwiki a good regression candidate.
Yeah I'm not very proud of that either but I have to wor
thinking that your use of null macro arguments is
somewhat a corner case of macro usages which is very specific to xwiki, but at
least it makes xwiki a good regression candidate.
Yeah I'm not very proud of that either but I have to work with history
unfortunately...
> Add a flag fo
can't also help thinking that your use of null macro arguments is somewhat a
corner case of macro usages which is very specific to xwiki, but at least it
makes xwiki a good regression candidate.
> Add a flag for better backward compatibility wi
t}
1: $param
2: $param2
1: $return
{noformat}
The sub macro call "break" the parameter.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
&g
; Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
gine SNAPSHOT and it works great indeed. Anything I can
help to have the 2.2 release ASAP ? ;)
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
>
gt; Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
>
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson reopened VELOCITY-904:
-
> Add a flag for better backward compatibility with null macro argume
ard compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Is
ard compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Is
; Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Proje
for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
>
Claude Brisson created VELOCITY-904:
---
Summary: Add a flag for better backward compatibility with null
macro arguments
Key: VELOCITY-904
URL: https://issues.apache.org/jira/browse/VELOCITY-904
hen i implemented it.
>>
>> And Claude, thanks again for all the work on this. Velocity may not be
>> critical to my work these days, but it is still good to see it being
>> updated.
>>
>> On Tue, Sep 13, 2016 at 11:23 AM, Claude Brisson
>> wrote:
>>
the patch from VELOCITY-841 (commit 1753788).
> Evaluation of macro arguments
> -
>
> Key: VELOCITY-752
> URL: https://issues.apache.org/jira/browse/VELOCITY-752
> Project: Velocity
>
e. I was
never quite certain about that default when i implemented it.
And Claude, thanks again for all the work on this. Velocity may not be
critical to my work these days, but it is still good to see it being
updated.
On Tue, Sep 13, 2016 at 11:23 AM, Claude Brisson wrote:
It may be the last big s
se. I was
never quite certain about that default when i implemented it.
And Claude, thanks again for all the work on this. Velocity may not be
critical to my work these days, but it is still good to see it being
updated.
On Tue, Sep 13, 2016 at 11:23 AM, Claude Brisson wrote:
> It may be th
It may be the last big subject to address before releasing 2.0: how to
handle macro arguments?
Those three issues exhibit nasty side effects of the current behavior:
https://issues.apache.org/jira/browse/VELOCITY-683
https://issues.apache.org/jira/browse/VELOCITY-684
https
ibleProblem to fail
since the behaviour is now different. Nathan, what do you think?
> Evaluation of macro arguments
> -
>
> Key: VELOCITY-752
> URL: https://issues.apache.org/jira/browse/VELOCITY-752
> Project
Evaluation of macro arguments
-
Key: VELOCITY-752
URL: https://issues.apache.org/jira/browse/VELOCITY-752
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 1.6.2
ckly
> BlockMacros fail with strict number of macro arguments
> --
>
> Key: VELOCITY-685
> URL: https://issues.apache.org/jira/browse/VELOCITY-685
> Project: Velocity
>
[
https://issues.apache.org/jira/browse/VELOCITY-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELOCITY-685.
---
Resolution: Fixed
> BlockMacros fail with strict number of macro argume
testing!
Here's a patch that should fix the issue.
> BlockMacros fail with strict number of macro arguments
> --
>
> Key: VELOCITY-685
> URL: https://issues.apache.org/jira/browse/VELOCITY-685
&
BlockMacros fail with strict number of macro arguments
--
Key: VELOCITY-685
URL: https://issues.apache.org/jira/browse/VELOCITY-685
Project: Velocity
Issue Type: Bug
Components
[
https://issues.apache.org/jira/browse/VELOCITY-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-210.
---
> #macro arguments space-separated, not comma-separa
[
https://issues.apache.org/jira/browse/VELOCITY-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen closed VELOCITY-430.
---
> Allow commas or spaces to separate macro argume
76 matches
Mail list logo
