[ 
https://issues.apache.org/jira/browse/VELOCITY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024414#comment-17024414
 ] 

Claude Brisson commented on VELOCITY-926:
-----------------------------------------

What I'm ready to do is review the compatibility option(s) so that global 
values provide defaults for missing arguments. It looks like you are not the 
only ones hitting this problem, as Greg Huber reported a similar one. That 
should fix the recently found differences. I don't know yet if it will be a new 
{{velocimacro.arguments.global_defaults}} or if it is preferable to deprecate 
{{velocimacro.arguments.preserve_literals}} and gather both BC behaviors in a 
new {{velocimacro_enable_bc_mode}} flag. The later has the advantage that it 
can incorporate other adjustments, like a macro being able to set to null a 
global reference by setting to null an argument with the same name.

What is certain is that reinserting the ProxyVMContext is to be avoided. It had 
been identified as a major performance bottleneck, and removed for a reason. So 
beyond the behaviors that won't be emulated is the usecase 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
> -------------------------------------------------------------------------------
>
>                 Key: VELOCITY-926
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-926
>             Project: Velocity
>          Issue Type: Bug
>          Components: Engine
>    Affects Versions: 2.0, 2.1
>            Reporter: Claude Brisson
>            Assignee: Claude Brisson
>            Priority: Major
>             Fix For: 2.2
>
>
> Consider the following example:
> {code}
> #macro( test $foo $bar )
>   $foo $bar
> #end
> #set($foo = 'foo')
> #set($bar = 'bar')
> #test( $bar, $foo )
> {code}
> The expected result would be "{{bar foo}}", but since 2.0 we get the 
> incorrect result "{{bar bar}}", as if the first inner {{$foo}} macro argument 
> was overwritting the second argument evaluation.



--
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

Reply via email to