cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Learning from XForms (was: Wrapping your head around Cocoon)
Date Thu, 11 Nov 2004 18:43:15 GMT
Micah Dubinko wrote:

> I'm happy to learn whatever I can here.

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 ( 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 (, and author of numerous 
magazine articles.

I thought about asking about your reaction to Sylvain's XForms-CForms 
comparison but 
found out that you already have started to write about that I also 
found 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 

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 
(, especially 
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.


Anyway, I think that we can learn a lot from you, welcome to our 
community :)


View raw message