The code in the attached zip contains a wrapper around the Commons Validator for XMLForm using JXPath. (Schematron is still supported)
The Example org.apache.cocoon.acting.XMLFormAction class shows how it can be integrated and looks for 2 additional parameters in the form action, i.e. <map:parameter name="xmlform-validator-rules" value="validator/example-rules.xml"/> <map:parameter name="xmlform-validator-resource" value="validator/exampleResources.properties"/> instead of the schematron... <map:parameter name="xmlform-validator-schema-ns" value="http://www.ascc.net/xml/schematron"/> <map:parameter name="xmlform-validator-schema" value="schematron/SinglePageFormExample.xml"/> The class org.apache.cocoon.components.validation.commons.JXPathValidator provides all the usual validator methods, along with an extra dateRange method. Please email if you have any questions. Regards, Stephen -----Original Message----- From: ivelin [mailto:[EMAIL PROTECTED] Sent: Thursday, 3 April 2003 1:21 PM To: [EMAIL PROTECTED] Subject: Re: XMLForm & JSF In response to the multiple messages in the recent days about using commons validator, I am currently studying hard JavaServer Faces EA3. I will be looking to incorporate the JFC model into XMLForm without the JSP taglib part. Any comments in this direction are welcome. -=Ivelin=- ----- Original Message ----- From: "Sylvain Wallez" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 02, 2003 6:15 AM Subject: Re: [ANN] New version of XMLForm released > Stefano Mazzocchi wrote: > > <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 } >
xmlform.zip
Description: xmlform.zip
