cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: Stabilizing flow in order to release
Date Tue, 04 Mar 2003 18:11:33 GMT
Stefano Mazzocchi wrote:
> Some like the flow, some don't know it enough to dislike it but won't 
> try it out until we have a release. In the meanwhile, we are adding 
> functionality without stabilizing it.
> 
> I believe we should work toward release Cocoon 2.1, this is our priority 
> at the moment: restore a saner and faster release cycle, possibly much 
> better integrated with continous integration and unit testing.

I strongly agree that the flow layer needs testing.

But I have to tell you the main reason I started proactively adding 
features recently is that few people seemed to be able to use it in its 
current state.

Even now I see a lot of "you've done a great job with the flow, but I've 
never actually tried it".

If you're right that it's just a lack of documentation then let's 
correct that.

> 
> Now: I considered lack of callable pipelines and lack of xmlform-flow 
> integration and lack of velocity views all showstoppers, now we have it 
> so I'm calling a feature freeze of the flow layer for Cocoon 2.1, plus 
> internal redesign to match the points that Sylvain outlines.

Has anyone (besides me) actually tested the xmlform-flow integration or 
velocity integration? I haven't received any feedback.

> 
> This means that I would like to see flow-database stuff removed from the 
> main trunk.

I can do that, but I'd prefer to move it elsewhere in the main trunk 
where people could still use it to get started with using the flow layer.

> 
> While I really appreciated Chris' effort to provide a solution to the 
> data connection problems we will be facing, I think that providing a 
> braindead way to 'write SQL into your flow' is *EXACTLY* what I don't 
> want to see.
> 
> 
> Yet, the simplicity of adding stuff with the flow layer and its object 
> model should *NOT* trigger easy solutions to complex problems just for 
> show off, like this database flow layer does.
> 
Look, I work for an Enterprise Application Integration company. I know 
what it means to build large-scale applications and I think I know 
what's brain dead and what isn't. That's not the point. The purpose of 
the database api wasn't to show off, or to provide a brain dead solution 
for building large scale applications, but instead to lower the 
immediate barrier to entry of the flow layer so that more people would 
use it - and test it.

Regards,
Chris


Mime
View raw message