Nathan Bubna (JIRA) wrote:
[ https://issues.apache.org/jira/browse/VELOCITY-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663451#action_12663451 ]
Nathan Bubna commented on VELOCITY-666:
---------------------------------------
I share your skepticism about committing this. I don't know that
#macro( strong $txt $bodyContent )
<strong>$bodyContent</strong> $txt
#end
#define( $bodyContent )
<u>This text is underlined and bold</u>
#end
#strong( $foobar $bodyContent )
Is awkward or long enough to warrant another directive just to shorten it to
this
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.
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeCC Parser Generator, http://code.google.com/p/freecc
FreeMarker vs. Velocity, 5 years of practical experience
http://freemarker.blogspot.com/2007/12/velocity-of-freemarker-looking-at-5.html
#macro( strong $txt )
<strong>$bodyContent</strong> $txt
#end
#call( 'strong' $foobar )
<u>This text is underlined and bold</u>
#end
It is hard to find the right balance in these things. Right now, i am inclined
to leave this out, as it doesn't seem to provide any needed function, just a
somewhat better syntax. And i think what we really want syntactically is this:
#macro( strong $txt )
<strong>$bodyContent</strong> $txt
#end
#strong( $foobar )
<u>This text is underlined and bold</u>
#end
If that happens, #call will just be a complication for us to deprecate and for
users to change uses thereof.
I also happen to know that there are longtime users who are in the habit of
using a #call( $tool.doThis() ) macro and recommending that practice to others.
Adding this directive will surely break things for people upgrading.
I think the bottom line for me is that each directive we add risks conflict
with existing macros, increases the famously-low learning curve for Velocity
and--as you said--increases the internal complexity/size of Velocity. If we
are going to add a new directive, then i think we should be sure that it is
well worth the cost. I don't think #call has crossed that threshold, unless i
am missing something it can do.
If it could be implemented in such a way that it didn't require so many
internal patches, it would be fine as an optional user directive (like #local).
I'm not sure, though, if that is possible for this.
RFC: new directive: #call
-------------------------
Key: VELOCITY-666
URL: https://issues.apache.org/jira/browse/VELOCITY-666
Project: Velocity
Issue Type: Improvement
Affects Versions: 1.6.2, 1.7
Reporter: Jarkko Viinamäki
Attachments: velocity-call-directive.patch
Inspired by VELOCITY-583 (BlockMacro support) I implemented the same
functionality in a slightly different way.
This patch introduces a new directive #call("mymacro" $arg1 $arg2 ... ) any
valid Velocity content here #end
This directive causes a call to defined macro with given arguments AND passes
the enclosed AST as an argument which can be referenced with $bodyContent
(default, name is configurable).
An example:
#set($foobar = "yeah!")
#macro(strong $txt)
<strong>$bodyContent</strong> $txt
#end
#call("strong" $foobar)
<u>This text is underlined and bold</u>
#end
Will print:
<strong><u>This text is underlined and bold<u></strong> yeah!
Like I commented in VELOCITY-583 the same thing can be done by first using #define to build up some custom AST and then pass that AST as an argument to some macro. While it works, it's not as convenient as this syntax. This patch however increases the amount of code lines in Velocity and the implementation is a bit "hackish" so even I'm not totally convinced whether we should commit this.
But anyway, here it is, I'd love to hear your comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
