Apologies for a delayed response on this thread. Was buried in some work for
the past couple of weeks. Was able to spend some time on this past couple of
days. Here's what I have,
I have a working version of the blockmacro as discussed in this thread.
Patch attached. Here's the trivial example,
#blockmacro(html $style)
<html style="$style">
${yield}
</html>
#end
Block Macro Result
#html("color:red")
<body>Raghu</body>
#end
In broad brush strokes, here's what I did,
- Modified the grammar to look for blockmacro and register just like the
regular macro would.
- Created a new proxy for this and dealt with creating this one for block
macros.
I am yet to finish up some things,
- Making yield variable configurable
- want to make the proxy class interceptable (I need this ability to
intercept and manipulate content)
- the default templatetests doesn't seem to be comparing with the cmps. Is
there something I need to do special to make this work. If I replace the
content of any existing content with garbage, the tests still pass. Would
appreciate help in pointing me in the right direction here.
- refactor my current tests to be in alignment with other tests within the
project and add more complex tests.
Bumped in to a catch though,
- If the block macro is used before it is declared, I would have no idea if
the macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINE
which will make template parsing fail. There are four alternatives, I can
think of,
OPTION-1: Put a 'do' after my parameters.
#html("something") do
#end
Of course, 'do' could be optional, if html is defined already. The bad thing
about this is it introduces new language semantics into VTL
OPTION-2: Create a call semantic for blockmacros
#callBlockMacro (html "something")
#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros.
#forwardBlock html
#forwardLine strong
OPTION-4 (My preference): A configurable convention on prefix & suffix
(thank you, Conor, for the suggestion)
Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated.
Thanks,
Raghu.
On 1/7/08 11:48 AM, "Will Glass-Husain" <[EMAIL PROTECTED]> wrote:
> 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]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
