Velocity
  1. Velocity
  2. VELOCITY-529

Set a macro library programmatically for each individual page request

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6
    • Component/s: None
    • Labels:
      None

      Description

      I'd like to see Velocity allow developers to specify one or more macro files programmatically when a page is processed. The resulting behavior would be the same as if the user had used #parse to load the macro file at the top of the page. (assuming VELOCITY-362 was fixed and this worked).

      Velocity currently allows a developer to specify a VMGlobal library which loads a common set of macros applied for all pages. This is different because the macro file could be different for different pages.

      Probably the best way for this to work would be to use a structure similar to the event handlers which specifies a macro file name and attaches it to the context. When the page is processed, Velocity would use the resource loaders to load both the page and the macro file. (taking advantage of the resource caching mechanism for optimal performance).

      Why is this useful? There may be cases where different parts of an application require different sets of macros. In some cases, you may have many different parties developing different parts of the application. (For example in my primary app, we have large amounts of users regularly uploading Velocity pages to separate accounts). It's good practice to separate out modules from the main file. If this could be specified programmatically then template writers could upload both a macro file as well as a set of templates that use them.

      1. template_macro_lib.patch
        36 kB
        Supun Kamburugamuva

        Activity

        Hide
        Supun Kamburugamuva added a comment -

        I have done an implementation for including macro libraries programmatically. But the implementation is different from what Will has previously suggested.
        In this implementation the getTemplate function of the RuntimeServices interface is overloaded to include macro libraries.
        RuntimeServices.getTemplate(String templateName, List macroLibaryNames);

        This call will build the template with the macros from macroLbraries argument.
        I have chosen this method instead of overloading Template.merge method for one reason (I have done an implementation of overloading merge and it seems like it is impossible to give a proper solution). If we include the macro libraries in the merge method we only see the Macro definitions at the merge time. But we are building the template AST before we see the macro definitions. At this point we don't know weather calls to macros defined in a library are actual macros or not, even worse we cannot guarantee that there will be macro definitions for the macro calls in the library. So we have to include the macro libraries before we build the AST for the Temaplate.
        I have attached a patch which contains the implementation. If this approach is not suitable I'm ready to re-implement using another method.

        Show
        Supun Kamburugamuva added a comment - I have done an implementation for including macro libraries programmatically. But the implementation is different from what Will has previously suggested. In this implementation the getTemplate function of the RuntimeServices interface is overloaded to include macro libraries. RuntimeServices.getTemplate(String templateName, List macroLibaryNames); This call will build the template with the macros from macroLbraries argument. I have chosen this method instead of overloading Template.merge method for one reason (I have done an implementation of overloading merge and it seems like it is impossible to give a proper solution). If we include the macro libraries in the merge method we only see the Macro definitions at the merge time. But we are building the template AST before we see the macro definitions. At this point we don't know weather calls to macros defined in a library are actual macros or not, even worse we cannot guarantee that there will be macro definitions for the macro calls in the library. So we have to include the macro libraries before we build the AST for the Temaplate. I have attached a patch which contains the implementation. If this approach is not suitable I'm ready to re-implement using another method.
        Hide
        Will Glass-Husain added a comment -

        Supun has posted a new patch for this at Velocity-362.

        Show
        Will Glass-Husain added a comment - Supun has posted a new patch for this at Velocity-362.
        Hide
        Will Glass-Husain added a comment -

        patch applied from VELOCITY-362. Nice work.

        Show
        Will Glass-Husain added a comment - patch applied from VELOCITY-362 . Nice work.

          People

          • Assignee:
            Unassigned
            Reporter:
            Will Glass-Husain
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development