[
https://issues.apache.org/jira/browse/VELOCITY-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663842#action_12663842
]
Nathan Bubna commented on VELOCITY-666:
---------------------------------------
It wouldn't be hard to allow #define'd blocks to take parameters. Just add a
public Block context(Map) method or even a public Block put(key,val) method.
Then you could do:
#define( $intro )$greeting, $audience!#end
$intro.context({'greeting' : 'Hello', 'audience' : 'World'})
Really, now that i mention it, i think i may add these when i get a chance; i
can already see a place i might use it. :)
That said, i'd actually argue that #define adds a great deal of new
functionality. You can now assign blocks as references, test for their
existence, pass them directly as macro or tool arguments, and we can easily add
features like the methods suggested above. I also really appreciate the
conceptual separation it gives me. Now, i use #define for inline blocks, and
try to limit macros to the global library. This makes it easy for me to know
where things come from and where they are going.
I'm not thrilled about the idea of changing macro syntax to $bold('text'),
mostly because we've already trained people the other way, and i don't see much
value in being able to assign macros when we can already assign #define blocks.
I do, however, think there is potential in the
#bold("text")#begin<strong>$txt</strong>#end
idea. Though i think i would prefer the slightly shorter and more instructive
#body. I also wonder if it might not be easier for #body to know to look back
in the AST for it's macro than for the macro to know to look forward. Anyway,
it's an intriguing idea. Obviously, it's still not as ideal as
#bold('text')<strong>$txt</strong>#end
but
#bold('text')#body<strong>$txt</strong>#end
seems more feasible given the current parser and also seems somehow cleaner and
clearer than #call. #body also isn't known to be a popular macro name. I'm
still not really sure it adds that much, but the cost feels lower at first
glance.
> 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.
--
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-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
