cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@iname.com>
Subject Re: Cocoon Form binding and validation [was: RE: SchemoX forms]
Date Tue, 26 Mar 2002 14:56:05 GMT

Torsten,

I looked at your README and code.
Man we're so much on the same page.
Let's turn it over !!!

Did you have a chance to look at my latest stuff?

Is there a way we can get my source in scratch pad so that more people can
play with it.
Right now only a few of us that follow the thread know that it exists
somewhere on sourceforge.


> > If it supports dependecy checks then 'yes'. An example: is it possible
to
> > implement such a validation rule "validate 'car-model' required field
only
> > if the user indicated that he owns one (has set 'has-car' field to
true)"?
>
> That's what I like to see, too. Although I doubt you can express this
> within a XSD, can you?

Not with XSD. Schematron rules ! See my response to Konstantin.
Relax NG can't do it either, correct ?

> I know most people don't like "homegrown" standards that's why I made the
> validation pluggable in my approach. So anyone can easily come up with
> what he needs but still support the current "standard" validations.
>
> As a demo validation I came up with the "easyrelax" validation... Although
> it's just an example I have to admit I like it more and more :)

I saw it, it's all right. Options are good for people to choose from.

However we need to pick one validation language for the wizard.
You know my vote:) What do you guys think, which one should we use?


I have a few comments for  your samples:

If you look at my code , you'll notice that I already have implementation
for all your key interfaces:
Instance (JavaBean or DOM node impl), Preceptor (schematron.Validator),
Constraint (Schematron schema).

I would suggest that we try to hide as much of the complexity from the user
as possible.
The only thing which I believe is neccessary to expose to the user is a
Validator/Preceptor interface and a ValidationResult interface (with its
elements).
It is not necessary for the user to see an Instance. All they need to pass
in to the Binder/Populator is a JavaBean or DOM node, or a mixed version of
the two. Then know the Validator interface, so they can call a factory:
ValidatorFactory.newInstance(SCHEMA_TYPE);
and then call
Validator.validate(instance, properties)

Again, the instance doesn't have to be anything special but a JavaBean or
DOM node.

Forcing people to implement an Instance interface or a Constraint interface
is just to much hardship.
I don't mind if we use them internally for the framework though.

On the model.xml:

Don't you think we can use Konstantin's work on XForms to implement a
standards based solution instead of home grown:

<i:insert/>

can be replaced with any of the available <xsl:include document> or
castorTransformer insert or DomReaderTransformer
within the instance tag of an XForms markup.

<r:render/>
<f:textbox/>

have alternative XForms tags as well.


Ok that's for now.

I think I managed to provoke a constructive discussion !


Cheers,

Ivelin



>
> Ivelin and me thought it would be a good idea to have a feedback wizard as
> sample application. So people install cocoon and they are asked a few
> questions (what system, how the installation went etc.) and the feedback
> can be registered somewhere. We then could create some statistics with
> SVG on the cocoon website maybe :)
>
> We compiled some requirements for such an sample application:
> * should at least 3 pages with a summary as last page
> * should be full i18n. the browser locale should be taken as default
>   locale for the application. not only the labels but also the constraints
>   and error messages should be localized
> * all types of HTML controls should be used
> * you should be able to navigate through the wizard with "next" and "prev"
>   buttons
> * as little java programming as possible should be necessary to create
simple
>   forms.
> * use the MVC pattern

Good coverage !





>
> Hope I haven't forgotten anything...
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message