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]
