Dr. Michael N. Lipp wrote:
<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
|