cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ivelin" <>
Subject Re: XMLForm & JSF
Date Mon, 07 Apr 2003 13:40:29 GMT


I am looking at mergin your code in XMLForm.
At this point I have these questions:
1) Is BeanUtils required? Your code seems to reference it, but your comments
suggest otherwise
2) How does one implement validation for a certain phase in a wizard?
Validator seems to offer some sort of linear page validation, but I don't
understand it quite yet.
Is there a good resource for commons validator examples and best practices?

Thank you,

----- Original Message -----
From: "Stephen Burns" <>
To: <>
Sent: Wednesday, April 02, 2003 10: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
<map:parameter name="xmlform-validator-rules"
<map:parameter name="xmlform-validator-resource"

instead of the schematron...
<map:parameter name="xmlform-validator-schema-ns"
<map:parameter name="xmlform-validator-schema"

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.

-----Original Message-----
From: ivelin []
Sent: Thursday, 3 April 2003 1:21 PM
Subject: Re: XMLForm & JSF

In response to the multiple messages in the recent days about using
I am currently studying hard JavaServer Faces EA3.
I will be looking to incorporate the JFC model into XMLForm without the
taglib part.
Any comments in this direction are welcome.

----- Original Message -----
From: "Sylvain Wallez" <>
To: <>
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
> > 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
> 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
> 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
> 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
> > 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,
> these are good arguments to ensure further innovation and development
> 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
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message