You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Raghu Rajah <rr...@hotmail.com> on 2008/01/25 18:57:19 UTC
(Unknown)
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 ofdays. 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 theregular macro would.- Created a new proxy for this and dealt with creating this one for blockmacros. I am yet to finish up some things, - Making yield variable configurable- want to make the proxy class interceptable (I need this ability tointercept and manipulate content)- the default templatetests doesn't seem to be comparing with the cmps. Isthere something I need to do special to make this work. If I replace thecontent of any existing content with garbage, the tests still pass. Wouldappreciate help in pointing me in the right direction here.- refactor my current tests to be in alignment with other tests within theproject 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 ifthe macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINEwhich will make template parsing fail. There are four alternatives, I canthink 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 thingabout 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.
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
RE: Blocks in Velocimacros
Posted by Claude Brisson <cl...@renegat.net>.
The best and preferred way is to add an entry in the JIRA bug report
system, with an attachment.
Claude
Le vendredi 25 janvier 2008 à 13:01 -0500, Raghu Rajah a écrit :
> The attachment gets stripped. Is there a recommended way to send the patch over?
>
> Thanks,
> Raghu.
>
>
> From: rraghuram@hotmail.com
> To: dev@velocity.apache.org
> Subject:
> Date: Fri, 25 Jan 2008 12:57:19 -0500
>
>
>
>
>
>
>
>
> 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 ofdays. 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 theregular macro would.- Created a new proxy for this and dealt with creating this one for blockmacros. I am yet to finish up some things, - Making yield variable configurable- want to make the proxy class interceptable (I need this ability tointercept and manipulate content)- the default templatetests doesn't seem to be comparing with the cmps. Isthere something I need to do special to make this work. If I replace thecontent of any existing content with garbage, the tests still pass. Wouldappreciate help in pointing me in the right direction here.- refactor my current tests to be in alignment with other tests within theproject 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 ifthe macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINEwhich will make template parsing fail. There are four alternatives, I canthink 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 thingabout 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.
>
> Shed those extra pounds with MSN and The Biggest Loser! Learn more.
>
> _________________________________________________________________
> Connect and share in new ways with Windows Live.
> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
RE: Blocks in Velocimacros
Posted by Raghu Rajah <rr...@hotmail.com>.
The attachment gets stripped. Is there a recommended way to send the patch over?
Thanks,
Raghu.
From: rraghuram@hotmail.com
To: dev@velocity.apache.org
Subject:
Date: Fri, 25 Jan 2008 12:57:19 -0500
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 ofdays. 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 theregular macro would.- Created a new proxy for this and dealt with creating this one for blockmacros. I am yet to finish up some things, - Making yield variable configurable- want to make the proxy class interceptable (I need this ability tointercept and manipulate content)- the default templatetests doesn't seem to be comparing with the cmps. Isthere something I need to do special to make this work. If I replace thecontent of any existing content with garbage, the tests still pass. Wouldappreciate help in pointing me in the right direction here.- refactor my current tests to be in alignment with other tests within theproject 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 ifthe macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINEwhich will make template parsing fail. There are four alternatives, I canthink 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 thingabout 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.
Shed those extra pounds with MSN and The Biggest Loser! Learn more.
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008