[ 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