cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: [Vote] Move flow related "packages"
Date Fri, 04 Jul 2003 08:39:47 GMT
On 4/07/2003 10:02 Reinhard Pötz wrote:

>>From: Steven Noels [] 
>>On 3/07/2003 15:18 wrote:
>>>As you probably read at my previous mail "[Flow] Status"
>>>there are 3 flow related "packages" which should go to the 
>>main trunk:
>>Where in the 'main trunk'? Are we talking about blocks here?
> Good question ...
> I would add the JXTemplateGenerator/Transformer to the core. If we ever
> decide to move the flow related stuff into its own block this would be
> the best place. But we should move this discussion to the time after 2.1
> is released because IIRC it is not so easy to move the flow into it's
> own block because of its relations to the sitemap (but possible).

It's some 120K of code being added to the core. Syntactical sugar for 
the flow in the sitemap is essentially orthogonal to 
JXTransformer/-Generator (and agreed upon IIUC), but moving this into 
its own block might grow a better community wrt. documentation, coherent 
samples and support.

> The Petstore could move to the flow examples. 

I'd like to see this being put into its own (perhaps flow-centric 
sample-only) block.

> About the JXForms I'm not sure at the moment. Of course it should go
> into it's own block and IMO it would be best if they go into the
> XMLForms block. This would not confuse our users and from a technical
> point of view it is also correct because AFAIK JXForms are only a
> wrapper to XMLForms to make it easier to use them from within your flow
> scripts. And so the XMLForms action (probably it must be rewritten in
> some parts) is still available for all people who have already used the
> unreleased XMLForms or for people who do not want to rely on the flow.
> What do you think?

This Form stuff is troubling me more and more, but I can't see ATM how 
we can consolidate easily while maintaining backwards compatibility & 
offering an abundance of choice. It's not only about XMLForms and 
JXForms, it's also about Woody (which might also be integrated with the 
Flow in the future), and various other, smaller Form-related actions and 
components dispersed across Cocoon CVS.

Part of myself feels like axing and actively deprecating older (and less 
actively used) Form frameworks, and demanding some sort of collaboration 
between the various Form frameworks. But maybe Darwin will do that for 
us. Then again, not believing in fate and all that, I'm sure we can be 
masters of our own destiny.

But as Bruno, sitting next to me, is suggesting, is that there's quite 
some other areas of functionality overlap & duplication in Cocoon, and 
apparently only Forms is enough of a common concern so that people 
actually care about consolidation. Basides the story behind XMLForms, of 
course, which sadly reflects now in the last column of

I'm just very careful about all this because I see now what harm the 
dramatic overselling of XMLForms is causing us ATM.


Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at  
stevenn at                stevenn at

View raw message