cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivelin Ivanov <>
Subject Re: XMLForms and Flowmap
Date Sun, 16 Jun 2002 16:20:12 GMT

Thanks for your thouts.

I would like to see an example at least as complex as the XMLForm demo 
before I can comment.
The example needs to

1) Be able to handle most UI widgets, including checkboxes
2) Allow 2 way navigation
3) Make decisions about the next page based on:
   a) validity of the input
   b) user selection in the current page
4) Show how data in a page can be pulled from a db source, only if it is 
5) Show how input data can be wrapped in a transaction which will write 
the data to a db and will also trigger other steps that need to be part 
of the same transaction, so that either everything succeeds or nothing.

These 5 steps are what people writing Web Apps have to deal with all the 
time. Having data processing in the action, allows use of standard J2EE 
APIs, like JTA, JDBC, etc. which have proven solid. It also allows clean 
interaction with the business layer through strongly typed objects, 
allows easy debugging and performance profiling.
These three benefits are vital for a web app which has the potential to 
scale in size and usage.



Stefano Mazzocchi wrote:
> Ivelin Ivanov wrote:
>>We are looking for someone to step up and show us how these two can work
>>together in a nice way.
> I am.
> IMNSHO, the flowmap should totally replace actions and deprecate them.
> I've looked at XMLForms and I must say it looks extremely unfriendly to
> my eyes. The reason? massive use of actions, which hide the flow logic
> from the sitemap.
> In the example I've seen, you use the same URI, passing the
> cocoon-action parameter to trigger a different state.
> I'm not against the concept, not at all, but I think that actions are
> evil, bad, harder to use than it first seems and not RAD at all.
> What I love about Ovidiu's work is the ability to use it even without
> continuations: you are not forced to use continuations to store your
> state and you can simply write your flow logic in javascript and run it,
> instead of using actions, compile them, include them and so on.
> So, I don't think they should work together at all: form validation
> should be a cocoon component that you simply call from your flow logic.
> Does it make sense?


-= Ivelin =-

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

View raw message