<snip/>
My project aac-xforms (another approach to Coocon XForms) grew out of the desire to have the "standard" XForms in Cocoon. I'm still working on this project, but have currently very little time and so it is making little progress. Sometimes I look at chiba/chicoon and wonder if I should stop aac-xforms, but I still like my approach ;-).
Concerning the server/client question of XForms, I think there will always be demand for a pure server side solution (or at least approximation, as you can obviously not fully implement UI event behaviour) until XForms is integrated in browser (which will not shortly - if ever - happen). Believe it or not, especially the large costumers of the company I'm working for are still hesitant about allowing JavaScript (bad) or user driven download of plugins (very bad) and "please do not propose a solution that requires our IT department to do installation of software on the clients".
I perfectly understand this and had similar experiences: convincing a large customer to deploy a plugin on thousands of PCs is not a simple thing to do.
But this wasn't the real question: why XForms at all? Why use a client-side spec to constrain it in a server where it doesn't fit?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
