Daniel Fagerstrom wrote:
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.
Let me correct this: in the now famous "XMLForms vs Woody" post, the conclusion wasn't that XForms was not relevant for Cocoon, but that the XForm event model was IMO too rich to be implemented in a simple and efficient manner by a server-side implementation.
Woody on the contrary was less ambitious, but had good foundations for a server-side form framework. It later evolved into the CForms we have today, which does have an event model which, although simple, fits many complex needs as it runs server side.
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.
I shamely admit I haven't read the final version of the XForm spec :-/
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.
The danger here is to fall again in the XMLForm trap, where all request parameters where checked to see if they corresponded to some valid XPath expression.
Note also that most widgets only call getParameter() on the request, and that we could easily cut that dependency by passing e.g. a Map implementation wrapping the request. That's what JSF does to abstract the request between servlet and portlet, as they have no abstraction of the environment as Cocoon does.
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.
Could you elaborate on this?
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.
Sure, comparisons are always interesting.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
