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]

Reply via email to