inline...
On Fri, Mar 6, 2015 at 7:48 AM, Alex Fedotov a...@kayak.com wrote:
One more question. One of the other areas we making changes is around how
macros are called. Right now the lookup process is fairly rigid and can be
inefficient as well. Consider a couple of examples:
1. Scenario
I would treat them as local. Global ones should be defined at runtime
initialization.
On Fri, Mar 6, 2015 at 9:14 AM, Alex Fedotov a...@kayak.com wrote:
There are some open questions though:
There is a very useful method Template.merge(Context, Writer, List
macroLibraries).
Should these
One more question. One of the other areas we making changes is around how
macros are called. Right now the lookup process is fairly rigid and can be
inefficient as well. Consider a couple of examples:
1. Scenario one - overload macro in the template This works now because the
lookup checks the
Sure it can be done.
I would still keep the macros in templates, including the global templates
(i.e. library files). I would maintain the list of global Template objects.
Depending on the settings, during the macro lookup iterate over the global
Template objects first, if not found there do the
There are some open questions though:
There is a very useful method Template.merge(Context, Writer, List
macroLibraries).
Should these macroLibraries be treated as global or local? I believe they
are treated as local now.
Alex
On Fri, Mar 6, 2015 at 12:08 PM, Alex Fedotov a...@kayak.com wrote:
Hi.
We'll publish the 2.0 one day, it's slowly moving...
Thank you for your proposal. Of course, it is interesting for the
project if you can share your 1.7 bugfixes as long as your
synchronization work on the 2.0 branch.
The process is rather easy: patches are to be submitted on JIRA :
Hello Guys,
We use Velocity quite a bit and are considering moving forward and
deploying the trunk build in production even though there never was a 2.0
release. We currently use a custom 1.7 build with a couple of bugs fixed by
us.
One area where we are going to make some changes before it can