Quite interesting. It's always great to offer better selection to users. Can you summarize what is the advantage of the commons validator vs Schematron? Their expressive power seems identical. The syntax is obviously different.
-=Ivelin=- ----- Original Message ----- From: "Stephen Burns" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 02, 2003 9:59 PM Subject: RE: XMLForm & JSF 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 } >
