[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574
]
Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 4:13 PM:
---
I don't think we understand each other. In my example $test is defined in the
global context, it's an object with a method getName() which return something
(let's say "value"). $other is not defined so it's null.
The calling code does not and should not care about the names of the macro
parameters which is actually my main point here, from its point of view it's
just passing values (one of which is the result of $test.name evaluation). The
problem here is that the macro breaks the input expression passed as second
parameter because it happen to define as first parameter a name that affects
this expression so it really looks like `$test.name` is NOT evaluated
beforehand.
Here a more explicit example:
{code}
#set($test = $someObjectWithAGetNameMethodReturning_value)
#set($other = $someObjectWithAGetNameMethodReturning_something)
#macro (testMacro $test $name)
$name
#end
$test.name
#testMacro($other, $test.name)
{code}
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 was interpreted
based on this new value instead of the one the calling code was expecting.
was (Author: tmortagne):
I don't think we understand each other. In my example $test is defined in the
global context, it's an object with a method getName() which return something
(let's say "value"). $other is not defined so it's null.
The calling code does not and should not care about the names of the macro
parameters which is actually is my main point here, from its point of view it's
just passing values (one of which is the result of $test.name evaluation). The
problem here is that the macro breaks the input expression passed as second
parameter because it happen to define as first parameter a name that affects
this expression so it really looks like `$test.name` is NOT evaluated
beforehand.
Here a more explicit example:
{code}
#set($test = $someObjectWithAGetNameMethodReturning_value)
#set($other = $someObjectWithAGetNameMethodReturning_something)
#macro (testMacro $test $name)
$name
#end
$test.name
#testMacro($other, $test.name)
{code}
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 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
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574
]
Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 4:11 PM:
---
I don't think we understand each other. In my example $test is defined in the
global context, it's an object with a method getName() which return something
(let's say "value"). $other is not defined so it's null.
The calling code does not and should not care about the names of the macro
parameters which is actually is my main point here, from its point of view it's
just passing values (one of which is the result of $test.name evaluation). The
problem here is that the macro breaks the input expression passed as second
parameter because it happen to define as first parameter a name that affects
this expression so it really looks like `$test.name` is NOT evaluated
beforehand.
Here a more explicit example:
{code}
#set($test = $someObjectWithAGetNameMethodReturning_value)
#set($other = $someObjectWithAGetNameMethodReturning_something)
#macro (testMacro $test $name)
$name
#end
$test.name
#testMacro($other, $test.name)
{code}
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 was interpreted
based on this new value instead of the one the calling code was expecting.
was (Author: tmortagne):
I don't think we understand each other. In my example $test is defined in the
global context, it's an object with a method getName() which return something
(let's say "value"). $other is not defined so it's null.
The calling code does not and should not care about the names of the macro
parameters which actually is my main point here, from its point of view it's
just passing values (one of which is the result of $test.name evaluation). The
problem here is that the macro breaks the input expression passed as second
parameter because it happen to define as first parameter a name that affects
this expression so it really looks like `$test.name` is NOT evaluated
beforehand.
Here a more explicit example:
{code}
#set($test = $someObjectWithAGetNameMethodReturning_value)
#set($other = $someObjectWithAGetNameMethodReturning_something)
#macro (testMacro $test $name)
$name
#end
$test.name
#testMacro($other, $test.name)
{code}
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 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
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019574#comment-17019574
]
Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 4:10 PM:
---
I don't think we understand each other. In my example $test is defined in the
global context, it's an object with a method getName() which return something
(let's say "value"). $other is not defined so it's null.
The calling code does not and should not care about the names of the macro
parameters which actually is my main point here, from its point of view it's
just passing values (one of which is the result of $test.name evaluation). The
problem here is that the macro breaks the input expression passed as second
parameter because it happen to define as first parameter a name that affects
this expression so it really looks like `$test.name` is NOT evaluated
beforehand.
Here a more explicit example:
{code}
#set($test = $someObjectWithAGetNameMethodReturning_value)
#set($other = $someObjectWithAGetNameMethodReturning_something)
#macro (testMacro $test $name)
$name
#end
$test.name
#testMacro($other, $test.name)
{code}
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 was interpreted
based on this new value instead of the one the calling code was expecting.
was (Author: tmortagne):
I don't think we understand each other. In my example $test is defined in the
global context, it's an object with a method getName() which return something
(let's say "value"). $other is not defined so it's null.
The calling code does not and should not care about the names of the macro
parameters which actually is my main point here, from its point of view it's
just passing values (one of which is the result of $test.name evaluation). The
problem here is that the macro breaks the input expression passed as second
parameter because it happen to define as first parameter a name that affects
this expression so it really looks like `$test.name` is NOT evaluated
beforehand.
Here a more explicit example:
{code}
#set($test = $someObjectWithAGetNameMethodReturning_value)
#set($other = $someObjectWithAGetNameMethodReturning_something)
#macro (testMacro $test $name)
$name
#end
$test.name
#testMacro($other, $test.name)
{code}
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 then 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
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17019550#comment-17019550
]
Thomas Mortagne edited comment on VELOCITY-904 at 1/20/20 3:18 PM:
---
Not sure what you mean. Are you saying this behavior is expected ? If
`$test.name` was evaluated beforehand I don't see how the name of the previous
macro parameter could have any impact on it. My use case involves
"velocimacro.arguments.preserve_literals", maybe 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
> --
>
> Key: VELOCITY-904
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447
]
Thomas Mortagne edited comment on VELOCITY-904 at 12/13/19 8:23 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 work with history
unfortunately...
Currently trying to think about a cleaner way to deal with this macro return
need which involve a lot less hacking that people would use and which would be
less impacted by Velocity internals.
bq. To answer your question about what you can do to help speed up the release
process, well, all the tests and regressions that you do discover are certainly
helpful to improve the quality of the release, especially about backward
compatibility, and we thank you for them, but I'm not sure they're making the
release process faster...
I must say I was not expecting to find more issues when I asked the question
but yes not exactly the best to speed up the release :)
was (Author: tmortagne):
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...
Currently trying to think about a cleaner way to deal with this macro return
need which involve a lot less hacking that people would use and which would be
less impacted by Velocity internals.
> 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
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995447#comment-16995447
]
Thomas Mortagne edited comment on VELOCITY-904 at 12/13/19 8:12 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 work with history
unfortunately...
Currently trying to think about a cleaner way to deal with this macro return
need which involve a lot less hacking that people would use and which would be
less impacted by Velocity internals.
was (Author: tmortagne):
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...
> 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
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Comment Edited] (VELOCITY-904) Add a flag for better backward compatibility with null macro arguments
[
https://issues.apache.org/jira/browse/VELOCITY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991799#comment-16991799
]
Thomas Mortagne edited comment on VELOCITY-904 at 12/9/19 5:45 PM:
---
I just built velocity-engine SNAPSHOT and it works great indeed. Anything I can
help with to have the 2.2 release ASAP ? ;)
was (Author: tmortagne):
I just built velocity-engine 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
> URL: https://issues.apache.org/jira/browse/VELOCITY-904
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 2.0
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Minor
> Fix For: 2.2
>
>
> See [this
> comment|https://issues.apache.org/jira/browse/VELOCITY-542?focusedCommentId=16621819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16621819]
> :
> {code}
> #macro(testmacro $parameter)
> $parameter
> #end
> #testmacro($return)
> {code}
> bq. which used to print "$return" (when $return is null or undefined) and we
> now get "$parameter".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
