cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: [proposal] move stuff from scratchpad into the trunk
Date Wed, 28 May 2003 14:22:56 GMT
Vadim Gritsenko wrote:

> 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.

>
>
>>> 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.
>
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.


Regards,

Chris


Mime
View raw message