cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Burns" <>
Subject RE: XMLForm & JSF
Date Mon, 07 Apr 2003 23:28:06 GMT

1) Unfortunately the BeanUtils is still required because the main
commons Validator class still uses PropertyUtils.  I'm sure it is
possible to remove this need if JXPath was used, but I went for a
minimal approach.  The JXPathValidator class supplied is an extension to
the Commons Validator and does NOT need it.

2) The Field element in the validation rules supports a page attribute
for this purpose, but I haven't looked into this yet.

3) I based the work on the Struts framework, there doesn't seem to be
any other real examples available at the moment.


-----Original Message-----
From: ivelin [] 
Sent: Monday, 7 April 2003 11:40 PM
Subject: Re: XMLForm & JSF


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
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
understand it quite yet.
Is there a good resource for commons validator examples and best

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