You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by bluejoe2008 <bl...@gmail.com> on 2010/04/29 05:14:43 UTC
#@vmname() does not work properly
dear all,
i tried to use #@vmname() to write pages those imports another layout, and i did as follows:
first, i defined a macro named 'layoutAs' in a macro.vm:
#macro(layoutAs $layout)
#parse($layout)
#end
then, i wrote 2 files, a.vpage and b.vpage
=====a.vpage=====
#@layoutAs("b.vpage")
this is a string in a.vpage
#end
=====b.vpage=====
<div style="color:red">
$!bodyContent
</div>
yes, it worked. however, when i modified b.vpage, let it use another layout:
=====b.vpage=====
#@layoutAs("c.vpage")
<div style="color:red">
$!bodyContent
</div>
#end
=====c.vapge=====
<table border="1">
<tr>
<td>$!bodyContent</td>
</tr>
</table>
as a result, a.vpage can not be rendered properly.
is it a bug of velcocity or not? i really need a simple way to realize such purpose
2010-04-29
bluejoe2008
Re: Re: Re: #@vmname() does not work properly
Posted by bluejoe2008 <bl...@gmail.com>.
yes, i see
thank you very much!
best regards
bluejoe2008
2010-05-04
bluejoe2008
发件人： 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 )
#end
Then when you use it, do
----- b.vpage ----
#@layoutAs( 'c.vpage' )
<div>
$macro.get('b.vpage.body')
</div>
--- c.vpage ---
<table>
<tr><td>$macro.get('c.vpage.body')</td></tr>
</table>
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 <bl...@gmail.com> 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: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Re: #@vmname() does not work properly
Posted by Nathan Bubna <nb...@gmail.com>.
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 )
#end
Then when you use it, do
----- b.vpage ----
#@layoutAs( 'c.vpage' )
<div>
$macro.get('b.vpage.body')
</div>
--- c.vpage ---
<table>
<tr><td>$macro.get('c.vpage.body')</td></tr>
</table>
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 <bl...@gmail.com> 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: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org
Re: Re: #@vmname() does not work properly
Posted by bluejoe2008 <bl...@gmail.com>.
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...
Re: #@vmname() does not work properly
Posted by Nathan Bubna <nb...@gmail.com>.
well, how does it render?
On Wed, Apr 28, 2010 at 8:14 PM, bluejoe2008 <bl...@gmail.com> wrote:
> dear all,
>
> i tried to use #@vmname() to write pages those imports another layout, and i did as follows:
>
> first, i defined a macro named 'layoutAs' in a macro.vm:
>
> #macro(layoutAs $layout)
> #parse($layout)
> #end
>
> then, i wrote 2 files, a.vpage and b.vpage
>
> =====a.vpage=====
> #@layoutAs("b.vpage")
> this is a string in a.vpage
> #end
>
> =====b.vpage=====
> <div style="color:red">
> $!bodyContent
> </div>
>
> yes, it worked. however, when i modified b.vpage, let it use another layout:
>
> =====b.vpage=====
> #@layoutAs("c.vpage")
> <div style="color:red">
> $!bodyContent
> </div>
> #end
>
> =====c.vapge=====
> <table border="1">
> <tr>
> <td>$!bodyContent</td>
> </tr>
> </table>
>
> as a result, a.vpage can not be rendered properly.
> is it a bug of velcocity or not? i really need a simple way to realize such purpose
>
> 2010-04-29
>
>
>
> bluejoe2008
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org