Not quite sure if I follow how this would work. I'm guessing you'll have to do some tricks with the parser nodes to make this work (since at parse time the repository of macros is not yet defined). There's probably a couple of ways of structuring this.
Look forward to seeing some code. Thanks again for your interest in contributing! WILL On Jan 7, 2008 8:35 AM, Claude Brisson <[EMAIL PROTECTED]> wrote: > That does make sense. Thanks. > > > Since I would have the > > repository of the defined velocimacros already, I can easily determine if > > the current macro is a block. > > That is the specific point I was missing in your approach. Looks totally > feasible. > > > Claude > > Le lundi 07 janvier 2008 à 10:29 -0500, Raghu Rajah a écrit : > > > Maybe we are talking two different things. > > > > 1. I don't intend to distinguish the content variable (yield or bodyContent) > > from any other reference. It is just another reference as far as the parser > > is concerned. The only variation is in the proxy directive, which would wrap > > the context to add the capability to yield (trap get on "yield" and render > > content in-place). > > > > 2. I did not intend to add the block-macros as part of the parsing > > environment. The parser will treat the block macro usage as yet another > > velocimacro, this one just happens to be a block. Since I would have the > > repository of the defined velocimacros already, I can easily determine if > > the current macro is a block. All the Parser does here is to add the content > > as the child of the current AST, as opposed to a peer. > > > > 3. The real problem is to distinguish during definition if a macro is a > > block-macro or a single-line one. Since there is no begin syntax for the > > block I (as the parser) won't know for sure if the next line is a beginning > > of a block or simply another peer node. Which is why I need a new directive > > "#block" > > > > Does this make sense? Let me know what you feel about this. > > > > Raghu. > > > > > > On 1/7/08 9:52 AM, "Claude Brisson" <[EMAIL PROTECTED]> wrote: > > > > > Le lundi 07 janvier 2008 à 07:34 -0500, Raghu Rajah a écrit : > > >> 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 > > > > > > I don't agree, or maybe I don't understand. In the definition code, > > > block macros [may] make use of a specific reference that contains the > > > block itself. At parsing time, nothing makes this reference different > > > from the others, that is, $yield or $bodyContent or whatever you call it > > > is just a reference with no specific meaning from the parser point of > > > view. How comes you would want to introduce a difference here? Why do > > > you see it as introducing a non-deterministic behaviour? > > > > > >> We already have block handling for directives within the parser grammar, > > >> that I can overload for handling block macro usage as well. > > > > > > Standard and custom directives, that alter the behaviour of the parser, > > > are defined prior to any parsing. We shall call this the parsing > > > environment. Macros are not part of this environment since they are > > > defined in parsed files. What I do call determinism in this context is > > > the fact that in a specific parsing environment, every file can be > > > parsed independantly from the others. > > > > > > I may be wrong but I think that your proposal implies that block > > > directives be defined only in a preloaded velocimacro library, > > > conceptually making the library part of the parsing environment if you > > > want to be able to state that the parsing is deterministic. it means > > > that block macros cannot be defined inline. I'm not stricly opposed to > > > it, but I think it'd be easier to use an alternate syntax so that block > > > macro definitions don't have to be predefined prior to the parsing > > > stage, and can be defined inline. > > > > > > > > > Claude > > > > > >> 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_sharelif > > >>>>>>>>>>>> e_ > > >>>>>>>>>>>> 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] > > >> > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
