[jira] [Commented] (VELOCITY-967) Allows passing a list of Template instances to Template#merge

"Thomas Mortagne (Jira)" <[email protected]>
Newsgroups gmane.comp.jakarta.velocity.devel
Message-ID <[email protected]>
    [ https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876991#comment-17876991 ] 

Thomas Mortagne commented on VELOCITY-967:
------------------------------------------

bq. Couldn't you use some kind of context chaining?

It's not very clear to me what you have in mind exactly.

> Allows passing a list of Template instances to Template#merge
> -------------------------------------------------------------
>
>                 Key: VELOCITY-967
>                 URL: https://issues.apache.org/jira/browse/VELOCITY-967
>             Project: Velocity
>          Issue Type: Improvement
>          Components: Engine
>    Affects Versions: 2.3
>            Reporter: Thomas Mortagne
>            Priority: Major
>
> Instead of the list of template names.
> In [XWiki|https://www.xwiki.org] it's possible to define Velocity macros in all kind of locations (files, pages, attachment in a page, object fields, etc.), they can include each other but more importantly you can have several Velocity scripts in the same page (or a page which included several other pages and now has several scripts) with one of the scripts reusing macros defined in a previous one.
> So far, it was not too much of a problem, I just kept reusing the same Template instance:
> {code}
> currentTemplate.setResourceLoader(new SingletonResourceReader(script));
> currentTemplate.process();
> currentTemplate.merge(context, out);
> {code}
> repeat...
> But I'm starting to work on caching compiled Velocity (i.e. {{Template}} instances) and execute them later in various different contexts. It's not a problem for variables since they are stored in the context, but there is still a problem for which I don't have a clean solution: passing current macros (gathered from previous executed templates) to the currently executed one. I first thought I could just call VelocityContext#setMacroLibraries before template.merge(mergeContext, out); but unfortunately, merge "breaks" the current context (it replaces the context macro libraries by an empty list) and using template.merge(mergeContext, out, names); and a custom ResourceManager would add too much complexity for various use cases.
> My current workaround is to pass a custom Velocity context which overwrite setMacroLibraries and ignore any call with an empty list as parameters (yeah, not a huge fan either).
> The simplest for us would be to pass directly the macro libraries Template instances to Template#merge (to be perfectly honest, passing just the macros is our real need but passing a Template list is more generic and in line with what Template#merge is already doing in practice).
> My plan is to write a (very easy) pull request, but I wanted to discuss the idea first to see how well it's received.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.