[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-dev
Subject:    [jira] Updated: (VELOCITY-686) BlockMacro renders $bodyContent on
From:       Jarkko_Viinamäki_(JIRA) <dev () velocity ! apache ! org>
Date:       2009-01-25 15:42:59
Message-ID: 747866218.1232898179629.JavaMail.jira () brutus
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/VELOCITY-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Jarkko Viinamäki updated VELOCITY-686:
--------------------------------------

    Attachment: velocity-686.patch

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


[prev in list] [next in list] [prev in thread] [next in thread]