<snip/>
During the last year of consultancies, I found out that several people identified XMLForm as the possible way to turn cocoon into better webapp-capable system.
And having a good form-handling package in Cocoon is absolutely necessary to have it adopted to build web applications. I can't remember how many people asked me about Struts vs Cocoon. I know they are not comparable, but these people were actually asking for a good forms handling package.
And web applications are key for Cocoon's future, since even publication-oriented sites now want CMS functions that are basically web applications.
<snip/>
and include all that 'somewhat-business-logic' that is sooooo common between webapps that should be factored out and provided directly by cocoon (as struts, somewhat, does).
And we should as far as possible build on some common mechanisms such as commons-validator that will both factorize development effort, promote cross-project pollinization and help people migrate from JSP/Struts environments to Cocoon.
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.
FormValidationAction did not prevent XMLForm nor Precept to appear, but these are good arguments to ensure further innovation and development in this area. And, BTW, Precept is already a block.
So +1 for a block, but I'm still wanting the current XMLForm code base to stay in Cocoon's CVS.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
