cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniela Gehle <>
Subject Re: [RT] Flowmaps revisited
Date Wed, 10 Oct 2001 15:50:08 GMT
Hi Tom/Berin,

Berin Loritsch wrote:
> "Tom Klaasen (TeleRelay)" wrote:
> >
> > Hi,
> >
> > I'm impressed... This would even solve problems I've got now with Struts
> > (which is concentrating solely on webapp development)

thanks :)

> > One point though: you should work out point "(6): form submits" some
> > more . Form validation is *the* PITA in webapp development, not in the
> > least because the user wants to see some feedback about what he did
> > wrong. I don't see that in your solution (but then again, I still have
> > to see the first webapp framework that solves this properly. My hopes go
> > to XForms, because I've done some pretty nice things with that).

Yep, you're right. I didn't mention form handling because it would have led
too far away from my original point, the Flowmap itself. Of course form
validation is a vital issue in Web development and of course we've been
thinking about this, too, and we're currently working on a form handling
component relying on XForms.

But, anyway, you can perfectly use the validation actions and logicsheets
Berin mentioned as well. In my opinion the syntax of the Flowmap itself should
be general enough to let you plug in the form validation component of your
personal taste.
> [...]

> > On a second level, have you thought about multi-page forms (one form is
> > filled out in multiple stages. There _are_ situations where you want to
> > do that) and multi-form pages (several forms on one page, and depending
> > on which form you press "submit" on, you go to a different location)?
> The Flowmap approach would take the sitemap entry above, and manage
> the flow/state transition between each page in the form.


Multi-form pages can be handled equally easily with the Flowmap approach. You
just have to take care that each of the forms carries a different event
parameter. According to the submitted event parameter a different transition
will be chosen, leading to a different target state with possibly a different
handler that processes the form data. Voila! 


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

View raw message