First cut. I have a working version of the blockmacro as discussed.
Patch attached. Here's the trivial example,
Block Macro Result
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
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
OPTION-1: Put a 'do' after my parameters.
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")
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros.
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.