[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)