Vadim Gritsenko wrote:
Christopher Oliver wrote:
FlowVelocityGenerator to replace VelocityGenerator
-1 to replacing: FlowVelocityGenerator introduces dependencies on org.apache.commons.jxpath and org.mozilla.javascript
Sorry, org.mozilla.javascript is not a problem, my fault: I was still under the impression that it is optional stuff.
which where missing in original VelocityGenerator.
Why is that a problem?
First we are creating blocks for more modular design and the next thing is we are coupling everything back into monolith. I feel that's not the right way to go.
We've got more than 5Mb worth of optional JARs (not counting blocks' libs) and if you think one of them -- like jxpath -- belongs to the core than we better poll opinions of all devs here and move it there.
Also, does it support functionality which is present in original VelocityGenerator? I can make out of the diff that "objectExports" are completely gone, and I'm not sure whether other features are still there or they have changed.
I'm +1 on extending VelocityGenerator but not at expense of breaking compatibility. I.e., it should not be hard to include couple of more objects in velocity context -- flowmap and continuation; and session too -- but preferably this should be done without introducing new dependencies or breaking existing templates our users may have.
Vadim
I agree that backwards compatibilty should be maintained. I don't see why it should be a problem to do that.
Umm... Can't link these two sentences together.
Sorry, but I don't agree with your design on extending VelocityGenerator, however.
I had no design in mind; just suggestion :)
Anyways, what's wrong with it? How new design is better? Sorry if this is described somewhere already -- just throw url in my direction.
Vadim
