[
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: [email protected]
For additional commands, e-mail: [email protected]
