[
https://issues.apache.org/jira/browse/VELOCITY-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654534#action_12654534
]
Nathan Bubna commented on VELOCITY-615:
---------------------------------------
So, i can understand why you would expect this to work, but it sure ain't
pretty to have everything named $foo. You have a global $foo, then 'dave'
proxied as a $foo macro argument and then changing the value of $foo. It
appears that this is confusing ProxyVMContext. I think you'll notice some
errors in your logs letting you know this isn't working for it. So, at least
there's a warning about this.
You'll find that changing it to:
#set($steve="old value")
#macro(tmpMacro $bob)
#set($steve="new value $bob")
$steve
#end
#tmpMacro("dave")
Should fix your problem.
In the meantime, i'll see if i can impart some greater wisdom to ProxyVMContext
regarding the tangled web you've woven. I can't see any good reason this
should be disallowed, tangled though it is.
i also don't see how this latest example has anything to do with cached vs
non-cached modes. I can replicate it just fine in non-cached mode. this is
clearly different than the original bug you experienced in 1.5.
> Inconsistent macro bahaviour in cached and non-cached modes
> -----------------------------------------------------------
>
> Key: VELOCITY-615
> URL: https://issues.apache.org/jira/browse/VELOCITY-615
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Windows XP, Tomcat 6.x, JVM 1.6
> Reporter: Steve O'Hara
> Fix For: 1.6
>
>
> Here's the scenario; we have a framework that allows us to reload the
> Velocity runtime so that we can tinker with caching etc at runtime. We
> normally run development with template caching turned off and deliver to the
> client with caching turned on.
> There is a problem with inline macros (probably macro libraries too, not
> sure) whereby they will behave differently once they are compiled and cached
> then when they are interpreted at runtime. It is all to do with the
> re-assignment of parameter variables within the macro.
> Here is a very simple example;
> #macro(tmpMacro $FieldNames)
> #set($FieldNames="ingredient." +
> $FieldNames.replaceAll(",",",ingredient."))
> .....
> #end
> #tmpMacro("one,two,three")
> This works fine when the template is not cached - as soon as you turn on
> caching, the macro becomes unreliable.
> My original prognosis was that we were upsetting the variable types by
> converting strings into lists but as you can see, that isn't the case in this
> example. The problem is solved by changing the assignment to;
> #set($Names="ingredient." + $FieldNames.replaceAll(",",",ingredient."))
> I can appreciate that maybe this type of "re-assignment" of parameters might
> be an issue, but the real problem is the inconsistency between the cached and
> non-cached behaviours.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
