You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Jarkko Viinamäki (JIRA)" <de...@velocity.apache.org> on 2009/01/24 17:12:59 UTC

[jira] Commented: (VELOCITY-686) BlockMacro renders $bodyContent on #set

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

Jarkko Viinamäki commented on VELOCITY-686:
-------------------------------------------

This is not actually a bug. It's a design decision. $bodyContent is not a normal reference because it can contain any complex set of AST nodes and logic. It just marks where the passed body should be rendered. Therefore you can't use it like a normal reference.



> 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
>
>
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org