From: Steven Noels [mailto:[EMAIL PROTECTED]
On 3/07/2003 15:18 [EMAIL PROTECTED] wrote:
As you probably read at my previous mail "[Flow] Status"
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
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 http://sourceforge.net/project/stats/index.php?report=months&group_id=18425
I'm just very careful about all this because I see now what harm the dramatic overselling of XMLForms is causing us ATM.
Cheers,
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
