Actually, I was saying the opposite. We can keep the calling semantics, as is. I might have to use an alternate directive (other than #macro) for definition. The definition parsing would become non-deterministic otherwise We already have block handling for directives within the parser grammar, that I can overload for handling block macro usage as well.
On Will's suggestion, I personally would prefer to keep the calling semantics between #macro and #blockmacro (or #block) the same. That would give us interesting opportunities to genericize the VTL language in the future (if we can address the block-breaking structure like elseif) and perhaps provide support for alternate DSLs. I prefer "yield" too. I will stick with that for the moment. Should be an easy one to change if there is disagreement over it Thanks, Raghu. On 1/7/08 6:22 AM, "Claude Brisson" <[EMAIL PROTECTED]> wrote: > Yes, Raghu, I'm "+1" if we find a mean of implementing it and agree > about the syntax. > > It's the use of the macro that should be differenciated between block > and non-block versions, not definition (for definition, I guess we can > keep #macro), for the parsing process to be deterministic. > > It looks like using a special directive to call the macro -as Will > suggests- is the only way to go. And yes, block macros should having > both a body and (a variable number of) arguments. > > #call? #block? #blockmacro? I like #block. > > #block(onemacro) without arg #end > #block(anothermacro,$arg1) only one arg #end > #block(themacro,$arg1,$arg2) etc... #end > > Concerning the name of the reference holding the body: it should anyway > be made configurable. $bodyContent looks heavier than $yield but much > more explicit. > > Claude > > Le dimanche 06 janvier 2008 à 21:18 -0800, Will Glass-Husain a écrit : >> I like this idea. Similar to JSP tags that have attributes and body. >> >> Question--- would a block macro be able to have both arguments and a >> body? I'd think this would be useful. >> >> Second, to clarify Claude's point about the difficulty. The issue is >> that the parser needs to call the block-macro, but since the actual >> macro is defined at run-time, the parser doesn't know whether to call >> a regular macro (no #end required) a block macro (needs an end) or >> just pass through verbatim (e.g. not defined macro). I guess to make >> this work the parser would need to open up a macro node any time a >> #abc() is included and just have all the following VTL be children. >> (either to an #end statement or to the end of the file. Not sure if >> this is workable, though it might be. >> >> An alternative would be to use a unique way of identifying block >> macros that could be recognized by the parser. Maybe a special >> directive to call the macro? In other words, to call the block macro >> "strong" the syntax would be >> >> #call(strong) >> >> #end >> >> WILL >> >> On Jan 6, 2008 6:06 PM, Raghu Rajah <[EMAIL PROTECTED]> wrote: >>> Nathan - Overloading #macro would be rather hard, especially since VTL does >>> not have a begin token for blocks, the parser lookahead would become >>> non-deterministic, I think. I can call the inner call "contentBody", "yield" >>> is rather commonly used term for this purpose in the ruby world. >>> >>> Claude - Was that a +1? Trust you are a committer. >>> >>> Raghu. >>> >>>> Subject: Re: Blocks in Velocimacros >>>> From: [EMAIL PROTECTED] >>>> To: [email protected] >>>> Date: Sun, 6 Jan 2008 23:39:43 +0100 >>> >>>> >>>> I agree, this would be useful. But since the parser would have to know >>>> macros definitions to detect blocks, I'm pretty sure it's very hard to >>>> implement. >>>> >>>> The way to go is the custom directive - that's much easier. >>>> >>>> >>>> Claude >>>> >>>> Le dimanche 06 janvier 2008 à 14:13 -0800, Nathan Bubna a écrit : >>>>> Yeah, i'm at least interested. If it works well and we have some good >>>>> tests for it (and, of course, all existing tests pass), i would even >>>>> support putting it into Velocity 1.6 (rather than wait for 1.7). >>>>> We've already got a lot of macro improvements in, this would Though, >>>>> i'd want the support of at least one other committer before doing >>>>> that. I do have one question and one suggestion at this point: Would >>>>> it work to overload the #macro directive instead of using #blockmacro? >>>>> (Not that big a deal to me, but people will ask.) And i would >>>>> suggest using $bodyContent as the default, instead of $yield since >>>>> that is more familiar to people. >>>>> >>>>> This is a great idea though! People have talked about it, but no one >>>>> has ever taken it upon themselves to work on it. >>>>> >>>>> On Jan 6, 2008 12:19 PM, Raghu Rajah <[EMAIL PROTECTED]> wrote: >>>>>> If I offer to implement block support, is there any interest in absorbing >>>>>> this contribution into the codebase. >>>>>> >>>>>> Here's what I intend to do, >>>>>> >>>>>> 1. Add a new directive called "blockmacro", along the same lines as >>>>>> macro, subclassing behavior from the current macro processing both in the >>>>>> directive and the JJT. >>>>>> 2. In order to render the content of the block, one could use a special >>>>>> context variable called "yield", that could be customized as whatever in >>>>>> the properties. >>>>>> >>>>>> The net definition would look something like, >>>>>> >>>>>> #blockmacro strong >>>>>> <strong>${yield}</strong> >>>>>> #end >>>>>> >>>>>> and usage would look like >>>>>> >>>>>> #strong >>>>>> This is a strong text for #if (${user.male}) Mr. #else Ms. #end >>>>>> ${user.name}. >>>>>> #end >>>>>> >>>>>> Regards, >>>>>> Raghu. >>>>>> >>>>>>> From: [EMAIL PROTECTED] >>>>>>> To: [EMAIL PROTECTED] >>>>>>> Subject: RE: Blocks in Velocimacros >>>>>>> Date: Thu, 3 Jan 2008 17:49:07 -0500 >>>>>> >>>>>>> >>>>>>> I think I will go the custom directive route. >>>>>>> >>>>>>> Thanks for all the pointers. I especially like the Hacking Velocity >>>>>>> presentation - rather groovy. It addresses nearly all the issues I had. >>>>>>> >>>>>>> Raghu. >>>>>>> >>>>>>> >>>>>>>> Date: Thu, 3 Jan 2008 14:37:35 -0800 >>>>>>>> From: [EMAIL PROTECTED] >>>>>>>> To: [EMAIL PROTECTED] >>>>>>>> Subject: Re: Blocks in Velocimacros >>>>>>>> >>>>>>>> Of course, you would then have to be sure to escape all " characters >>>>>>>> in your body content: >>>>>>>> >>>>>>>> #set( $Q = '"' ) >>>>>>>> >>>>>>>> #myForm( " >>>>>>>> <!-- some ${Q}arbitrary${Q} --> >>>>>>>> " ) >>>>>>>> >>>>>>>> so that you don't prematurely end your $body parameter. this is >>>>>>>> obviously not ideal, but may be easier than writing a custom >>>>>>>> directive, depending on the specifics of your case(s). >>>>>>>> >>>>>>>> On Jan 3, 2008 2:35 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote: >>>>>>>>> Also note that as of Velocity 1.5, you can include line breaks in >>>>>>>>> strings, making it reasonable (though not as pretty to do something >>>>>>>>> like: >>>>>>>>> >>>>>>>>> #macro( myForm $body ) >>>>>>>>> <form...> >>>>>>>>> $body >>>>>>>>> </form> >>>>>>>>> #end >>>>>>>>> >>>>>>>>> #myForm(" >>>>>>>>> <!-- some arbitrary html here --> >>>>>>>>> ") >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 2, 2008 7:13 PM, Raghuram Rajah <[EMAIL PROTECTED]> wrote: >>>>>>>>> >>>>>>>>>> Can I use a block within a velocimacro? Basically, I am trying to >>>>>>>>>> create a macro that will emit a XHTML tag with some javascript out. I >>>>>>>>>> would hate to create a begin macro and an end macro to accomplish >>>>>>>>>> this. That would be rather error prone. >>>>>>>>>> >>>>>>>>>> I would ideally like to do something like, >>>>>>>>>> >>>>>>>>>> #myForm(...) >>>>>>>>>> <!-- some arbitrary html here --> >>>>>>>>>> #end >>>>>>>>>> >>>>>>>>>> generating something like >>>>>>>>>> >>>>>>>>>> <form .... >>>>>>>>>> <!-- some arbitrary html here --> >>>>>>>>>> </form> >>>>>>>>>> >>>>>>>>>> Any suggestions would be greatly appreciated. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Raghu. >>>>>>>>>> >>>>>>>>>> _________________________________________________________________ >>>>>>>>>> Share life as it happens with the new Windows Live. >>>>>>>>>> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_ >>>>>>>>>> 122007 >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>> >>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> i'm is proud to present Cause Effect, a series about real people making >>>>>>> a difference. >>>>>>> http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect >>>>>> >>>>>> _________________________________________________________________ >>>>>> Watch "Cause Effect," a show about real people making a real difference. >>>>>> http://im.live.com/Messenger/IM/MTV/?source=text_watchcause >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>> >>> _________________________________________________________________ >>> Get the power of Windows + Web with the new Windows Live. >>> http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
