velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bluejoe2008" <>
Subject Re: Re: Re: #@vmname() does not work properly
Date Tue, 04 May 2010 02:46:00 GMT
yes, i see
thank you very much!

best regards



发件人: Nathan Bubna 
发送时间: 2010-05-01  03:32:29 
收件人: Velocity Users List 
主题: Re: Re: #@vmname() does not work properly 
Ah, yeah, that makes sense.   When it comes to render the "c" page,
the most recently set bodyContent value is that of the "b" page, whose
$bodyContent reference will then also use the current bodyContent
value, making it recursive.  It then stops rendering at the default
recursion limit.  Remember, the context is global, so the $bodyContent
references are being temporarily overridden in your nested situation.
We've moved toward explicit scoping only.  So, you too, will have to
be explicit.  Turning on the $macro scope object can help you here
(set the "macro.provide.scope.control" property to true) to do
something less confusing, like this:
#macro( layoutAs $layout)
$!macro.put("${layout}.body", $bodyContent)
#parse( $layout )
Then when you use it, do
----- b.vpage ----
#@layoutAs( 'c.vpage' )
--- c.vpage ---
And hopefully, this should be more readable/usable due to its
explicitness.  Explicit namespacing like this may not be very fancy or
clever and could become unwieldy in more advanced languages, but for
VTL, i'm convinced it is a good thing.  It has always been our goal to
encourage and enable simple, clear and maintainable templates, and
this explicitness should help.
Does that help?
On Thu, Apr 29, 2010 at 9:46 PM, bluejoe2008 <> wrote:
> for unknown reasons, it prints many "<div>..." repeatly
> ...
> <div style="color:red">
> <div style="color:red">
> <div style="color:red">
> <div style="color:red">
> <div style="color:red">
> ...
> more...
To unsubscribe, e-mail:
For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message