What's with the tone? Are you angry about something? There is war and
famine in this world, issues that are much more worthy of your anger
then template syntax. Sheesh...
I don't see why #if($cond $content) has an advantage over #if($cond)
$content#end. If your implication is that $content should be passed
to a macros as a parameter, well then yes, we are discussing the
mechanism for doing this.
A little friendlier next time please...
On Jan 15, 2009, at 19:48 , Jonathan Revusky wrote:
How can you guys be supposedly working in the template engine space
and not understand the motivation for basic features that have
existed in competing tools for the past 5 years at least? That's
such a long time. Sheesh.
I am going to throw you a bone, try to give you a hint. Here goes:
Why don't you ask yourself now why built-in directives like #if and
#foreach can have nested content? Wouldn't it be simpler to just
allow instead:
#if ($condition $content)
or:
#foreach ($listOrIterator $content)
You see, the issue, geniuses, is essentially the same as with the
built-in directives: macros with body content can be nested one
within the other to any arbitrary depth.
Anyway, why are you talking about this in a complete vacuum? You can
look at how it works in FreeMarker -- or JSP even. A description of
the feature and how it works in FreeMarker is here:
http://freemarker.org/docs/dgui_misc_userdefdir.html
Towards the bottom of the page, the heading is "Nested Content".
You'll also see that another aspect of this is that the #nested
directive can be invoked with parameters, IOW the macro can pass
back parameters to the nested content block.
But the whole notion that this feature is some little thing that is
unnecessary is 180 degrees away from the truth. There are all kinds
of templating patterns that are essentially impossible without this
feature. It's a basic feature in any modern templating tool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org