Christopher Oliver wrote:
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.
I think that is a problem whose scope is much broader than VelocityGenerator, and I don't think it's appropriate to use that as an excuse for -1-ing the integration of the Velocity generator with the flow layer. For what it's worth, the current flowscript implementation already uses JXPath and Rhino, so no new dependencies are really being introduced by VelocityGenerator.
I could be wrong, but from my experience with the existing Velocity generator, I would guess that there are few if any users of it. The complete lack of meaningful error reporting makes it pretty much unusable. That being said, I attempted to preserve backward compatibility, as far as I could understand the documentation. If I missed something, then those users will complain and we can fix it. Or if you are aware of a problem, please fix it.
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.
Regards,
Chris
