cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject RE: Cocoon Form binding and validation [was: RE: SchemoX forms]
Date Tue, 26 Mar 2002 14:05:36 GMT
> Done. Hm... It seems that you and Ivelin are doing the same thing but in
> quite different ways ;)
> Isn't it time to come a consensus in interfaces, sitemap structure etc.?

Yes... that's true - I had almost finished my proof-of-concept prototype
when Ivelin spoke up...

> Btw, I've found my own wizard demo that I created for my collegues a while
> ago and it's based on something like a flow engine (it's called
> ProcessHelper). So, I have 3 different implementations of almost the same
> thing ;)

Hey, we have also another one at hand we called it "dflow" (that's
what we are currently using - it didn't stand the test of developers
needs in the end;) we have 4 ;)

> > So might also want to try the examples...
> Yes, sure, but I'd prefer to have them running from Cocoon samples page (see
> http://localhost:8080/cocoon/mount/ - there is a link to 'precept', but I
> couldn't find the magic url after that to start your sample. What about a
> 'default' url in sitemap or a static HTML page with needed links?).

Ok.. I'll add another page. But you might already want to try:


> > <snip/>
> >
> > > 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?
> No, XSD does not support this kind of data dependency, but XForms' binding
> do. See 'relevant' attribute in my sample XForms.xml. You can define any
> dependency that is possible to express with XPath (more complicated cases in
> XForms are defined using 'functions', IIRC).

hm... it's been a while since I last read the spec - I should have a look
into the latest spec...

> > 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.
> And that is cool. From the first glance your interfaces are quite enough for
> any kind of validation (single field or dependency checks).

Yepp.... that's the idea. Let's keep them as simple as possible.
I'd like to see at least a XSchema and Relax-NG implementation.

> > 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'd like to use some kind of an XForms-based validation (that takes into
> account the form field-set, instance schema and the bindings), but haven't
> seen any implementation for it.

Hmm... I prefer the idea having some kind of schema as valdiation model...
So it would be great if we could merge these ideas...

> > > > If we're to solve it and bump Cocoon to the level of Struts
> > > > and the next
> > > > generation Java Server Faces based app servers, we need
> > their help.
> > >
> > > We need to create a small but real-life sample application
> > and we will
> > > achieve the level of Struts. Haven't look at JSF, but it's
> > based on Struts,
> > > isn't it?
> >
> > Can you give a link for the JSF?
> Here it is:

Thanks! ...doesn't seem to go very much into detail though

> > > So, let's start work on a web app now! Your work fills me
> > with enthusiasm ;)

Yeah, seems we are going at least somewhere :) The lack of form handling
has been around for sooo long now...

> > 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 :)
> Great idea!
> If it would not require already installed Cocoon then we could create an
> installation wizard for Cocoon ;)

Well, let's start with the feedback wizard first ;))

> > 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
> It seems that you've found the correct person for this one ;)
> And I'll have a chance to try usefulness of my i18n transformer in a real
> life application.

There are plenty of them, dude :)

> > * all types of HTML controls should be used
> > * you should be able to navigate through the wizard with
> > "next" and "prev"
> >   buttons
> and be able to cancel the process with a 'return' or 'cancel' button


> > * as little java programming as possible should be necessary
> > to create simple
> >   forms.
> > * use the MVC pattern
> Agree with all of this. But first we should decide whose framework we will
> be using. Until that I can take on me the presentation and i18n parts.

I don't think my "example1" isn't that far from Ivelin work. Only
difference of our approaches I see is the use of "phases" over "xpaths".
I actually think phases can easily added if we stick with "xpaths" in the

If you look into the action there are already "sets" = "phases". It should
be really easy to read them from a descriptor! Then we have both...

To unsubscribe, e-mail:
For additional commands, email:

View raw message