cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From reinhard_po...@gmx.net
Subject Re: [Vote] Move flow related "packages"
Date Fri, 04 Jul 2003 11:20:37 GMT
From: Steven Noels

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

After sending the mail I thought the same. So I'm +1 that  the
JXTemplateGenerator/Transformer, all flow examples, the flow documentation
and the Petstore go into this new "fow" block.

So the sitemap related classes, the interpreter and the rhino-continuations
library
stay in the core until we refactor the core with the blocks implementation
we hopefully start soon after the 2.1 release.

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

see above

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

What do we have now?

 - Ivelin implemented XMLForms and after some time we moved them into
   its own block.
   
 - After some time Ivelin decided to start xmlform.org. This step has
   not led to the success he had expected and Christopher decided
   that he doesn't want JXForms depend on an external community.
 
 - Bruno started another, very different form framework some month
   ago. It doesn't  follow any spec and is currently alpha.


So what should we do?

I think it is very easy to integrate XMLForms and JXForms because
a look into the sources showed me that they are nearly the same. The big
difference is the controller but this part is plugable and
a matter of taste whether you would like the control flow or an
action to control your forms application.

So I'm +1 to have one block (I would call it XMLForms) and
this is a combination of both (the 'old' XMLForms block and JXForms)
and contains one example controlling the form application with
a control flow and another with the XMLFormsAction. See also
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2
--> it contains information about off-list communication between Christohper
and Ivelin.

... and Woody is Woody and IMO completly different. As you
said evolution will show us which use cases are better solved with
XMLForms/JXForms and which with Woody. So I don't
worry that we have to decide something here.

What do you think?

Cheers,
Reinhard

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++

Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!


Mime
View raw message