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

Nathan Bubna commented on VELOCITY-686:
---------------------------------------

Curse my semi-offline semi-vacation!  :) I was bored and away from wifi last 
night and took a stab at this myself, only to find you did too.   I hate 
duplicating effort, but oh well.   We approached it much the same, expect that 
i kept $bodyContent as a proxy arg rather than put it in the context, because i 
was concerned about the effect on nesting body macros.   I also consolidated 
some duplicated stuff from Define.   I hope you don't mind, but i currently 
prefer my implementation.  I'll check it in shortly.  Please let me know what 
you think of it.

> BlockMacro renders $bodyContent on #set
> ---------------------------------------
>
>                 Key: VELOCITY-686
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-686
>             Project: Velocity
>          Issue Type: Bug
>          Components: Engine
>            Reporter: Byron Foster
>             Fix For: 1.7
>
>         Attachments: velocity-686.patch
>
>
> Given the following VTL:
> #macro(foo)#set($x = $bodyContent)#end
> #...@foo()bar#end
> renders to:
> bar
> I wonder about calling render on JJTBLOCK types in the ProxyVMContext get 
> method.  Do you think it would be better in ASTReference render?
> There is an interesting use case for BlockMacros which looks something like 
> this:
> #macro(escXML)$tool.escXml($bodyContent)#end
> The above definition could be used to create a filter like the following:
> #...@escxml
>   ## ... rendered stuff to be escaped
> #end
> $tool.escXml can intercept the writer and create a filter.  But as it stands 
> referencing $bodyContent renders the content making this use case impractical.

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