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 references
>
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 references
>
this snapshot version before I
push out the RC? Thanks.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
>
), while 1.7 did display $foo
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apac
:
--
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's worth addressing.
The plan
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 favor
iling list
regarding the macro local context it's still better than nothing.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-
regarding the macro local context it's better still better than nothing.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
>
?focusedCommentId=17023076=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17023076.
Even if it does not cover the other use cases discussed on the mailing list
regarding the macro local context it's better still better than nothing.
> Regression: Macro arguments na
locally set values even if they are modified by external
macros or parsings.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Ke
anymore even as a retro compatible
option.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https:/
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 arguments names cannot collide with external referen
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
> ---
>
> Ke
case
What I can tell you is that we did fixed several codes in XWiki Standard doing
that but I agree with you that it was mistakes in both cases. So 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: Ma
he 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 canno
r codebase.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCI
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 references
>
.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issues.apache.org/jira/browse/VELOCITY-926
>
this bug.
Thanks you for the quick fix !
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key: VELOCITY-926
> URL: https://issu
for 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
{{code}}$foo{{code}} macro argument was overwritting the second argument
evaluation.
> Regression: Macro arguments names cannot collide with external references
> names
> ---
>
> Key:
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
Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocit
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/jira/brow
e"
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 was interpreted
based on this new value instead of the one the c
e"
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 was interpreted
based on this new value instead of the one the c
e"
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 was interpreted based
on this new value instead of the one the c
preted 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
> --
>
> Key: VELOCITY-904
>
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 macro arguments
> --
>
> K
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 macro argume
e
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
> --
>
>
this behavior is expected ?
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
>
. 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 null macro argume
s 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 compatibility with null macro arguments
> --
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
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
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
:
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 work with history
unfortunately
:
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 work with history
unfortunately
: $return
{noformat}
The sub macro call "break" the parameter.
> Add a flag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https
ter backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Is
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
>
lag for better backward compatibility with null macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
>
[
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
ull macro arguments
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
>
lag 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
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 <cla...@renegat.net>
>> wrote:
>>
>> It may b
by 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
>
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 <cla...@renegat.net> wrote:
It may be the last big subject to address before releasing 2.0: how
ess 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://issues.apache.org/jira
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
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: Velocity
Issue Type: Bug
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
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
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
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
Project
[
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 arguments
[
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 arguments
64 matches
Mail list logo
