Micah Dubinko wrote: <snip/>
I'm happy to learn whatever I can here.
<snip/> Micah Dubinko wrote in another mail:
I want to get involved in Cocoon more, and wonder if this would be a good project to cut my teeth on.
Hi Micah (and the rest of the list)!
There are certainly places in Cocoon where your help could be very valuable, how about geting involved in Cocoon form handling ;)
I hope I don't embarrass you by telling those on the list who don't know (me until an hour ago e.g.) that Micah (http://dubinko.info/) among other things is editor and author of the W3C XForms spec where he has been involved for the last six years, author of an excelent book about XForms (http://xformsinstitute.com/essentials/), and author of numerous magazine articles.
I thought about asking about your reaction to Sylvain's XForms-CForms comparison http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2 but found out that you already have started to write about that http://dubinko.info/blog/2004/10.html#perm2004-10-13_xmlforms. I also found http://wiki.apache.org/cocoon/XFormsInCocoon. Please do not be shy ;), publish your ideas about such things here at the list, so that we can discuss them.
XForms in Cocoon ----------------
There have been several different partial XForms implementations in or related to Cocoon since 2000. ExFormula (Berin Loritsch), Precept (Torsten Curdt), XMLForm (Ivan Ivanov), JXForm (Christopher Oliver). They where essentially one man shows. XMLForm become quite popular but it had a security problem and also a got a community issue when Ivan decided to continue development in an own fork outside Cocoon. IIRC Berin had some discussions at the XForms mail-list a number of years ago about server side implementation and draw the conclussion that the commity was mainly interested in client side implementation.
After this experience and especially after Sylvain's letter, there seem to have been a feeling in the community that XForms is not relevant for Cocoon.
IMHO, this might be a mistake. I sometimes got the impression that we spend a lot of time to independently evolve things that are quite close to what XForms allready does. And the last time I reviewed the spec it seemed to me that the XForms event model would work well at the server side also.
Now we can't switch form frame work every now and then in Cocoon. Our users need stabillity and we as a community needs focus, and CForms is an excelent form frame work in many ways. But I think that we can and should make it much less monolitic and thus open it up for pluging in new ideas into the frame work. Now it is rather all or nothing.
We currently have a long discussion about, (among other things), how to achieve a stricter model - view separation in CForms (http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2, especially http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2). The major point here is to put the conversion/rendering step (what you call I18N formatting in your blog entry, and also identify as a major issue), between the model and the view. Another thing is having a request processor that writes into the widget tree instead of letting the widgets read from the request. This makes it possible to plug in an XML based request processor instead of the request parameters based, e.g.
In my view it is possible to break up the rather heavy widget interface in more focused concern areas, and especially to give a more focused model-view interface, without breaking back compabillity.
If we can achive this, it will be possible to use an XForms like user interface, and still using the rest of the frame work. Or to plug in an own e.g. DOM based widget hierarchy whith the existing UI.
IIUC there is still work to do in formalizing the life cycle and the event handling in CForms, it would be very interesting to see a comparison with the event model in XForms.
---o0o---
Anyway, I think that we can learn a lot from you, welcome to our community :)
/Daniel
