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

Will Glass-Husain commented on VELOCITY-615:
--------------------------------------------

Have you tried this with the upcoming v 1.6 (download from subversion)?  
There's been a lot of work to shore up the macro infrastructure.

WILL

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

Reply via email to