Stefano Mazzocchi wrote, On 02/04/2003 12.47: ...
But I'm more than happy to see XMLForm being factored out because:
1) this removes the wrong marketing perception that XMLForm is *the* solution for data-logic control.
2) allows people to experiment different approaches (XForm-based or not) with the same level of confidence.
Comments?
I held back my comments till now because there was some negative energy going round, especially because of the way it was "proposed", but IMO factoring XMLForm out of Cocoon as a library to process XForms makes perfect techniological sense, both for Cocoon (as you nicely put it) and for XMLForm, as it would be usable like the Struts Validator is for example.
Does it so much make sense ? The main difference of XForms with other "traditonal" forms is the client-side markup and this is where Cocoon shines by allowing XForms markup to be translated to regular HTML until browsers natively support it. A server-side implementation will mostly concentrate on form validation, which is common to every webapp framework, be it XForms-based or not.
So IMO an Cocoon-independent solution will be mainly a form validation package, or it will have to reinvent some of the Cocoon mechanisms.
I think though that this can grow into an Apache (sub)project. What would you suggest in this case?
Mmmh... Don't be too fast : let's wait and see how it evolves and what community will be around it...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
