[
https://issues.apache.org/jira/browse/VELOCITY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mortagne updated VELOCITY-967:
-------------------------------------
Description:
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 of 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.
was:
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 of 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.
> 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 of 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
