Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7
    • Component/s: Engine
    • Labels:
      None

      Description

      Here's the trivial example,

      #blockmacro(html $style)
      <html style="$style">
      $

      {yield}

      </html>
      #end

      Block Macro Result
      #html("color:red")
      <body>Raghu</body>
      #end

      Full discussion on thread: http://tinyurl.com/ytq3k4

        Issue Links

          Activity

          Hide
          Raghu Rajah added a comment -

          First cut. I have a working version of the blockmacro as discussed.
          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.

          Show
          Raghu Rajah added a comment - First cut. I have a working version of the blockmacro as discussed. 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.
          Hide
          Jarkko Viinamäki added a comment -

          I think the #define directive descibed in VELOCITY-174 can be used to accomplish the same thing (use #define to create some custom AST set and pass it as an argument to a regular macro). IMHO #define seems more general and cleaner solution. Or does this accomplish something that can't be done with #define?

          Show
          Jarkko Viinamäki added a comment - I think the #define directive descibed in VELOCITY-174 can be used to accomplish the same thing (use #define to create some custom AST set and pass it as an argument to a regular macro). IMHO #define seems more general and cleaner solution. Or does this accomplish something that can't be done with #define?
          Hide
          Nathan Bubna added a comment -

          With the addition of #define and the complications involved in this, this probably won't happen in 1.6.

          Show
          Nathan Bubna added a comment - With the addition of #define and the complications involved in this, this probably won't happen in 1.6.
          Hide
          Nathan Bubna added a comment -

          I'm marking this fixed, though it is implemented differently than discussed here. Jarkko's solution in VELOCITY-666 is superior since it allows you to declare macros for which the body is optional and leaves the body/no-body decision to the caller of the macro, distinguishing the those using a body at parsetime by means of a @ between # and macro name (e.g. #@usesbody() tada! #end). Jarkko's solution also provides for configurability of the body reference.

          Show
          Nathan Bubna added a comment - I'm marking this fixed, though it is implemented differently than discussed here. Jarkko's solution in VELOCITY-666 is superior since it allows you to declare macros for which the body is optional and leaves the body/no-body decision to the caller of the macro, distinguishing the those using a body at parsetime by means of a @ between # and macro name (e.g. #@usesbody() tada! #end). Jarkko's solution also provides for configurability of the body reference.

            People

            • Assignee:
              Unassigned
              Reporter:
              Raghu Rajah
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development