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 needed. 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. Cheers, Ivelin Stefano Mazzocchi wrote: > Ivelin Ivanov wrote: > >>Reinhard, >> >>We are looking for someone to step up and show us how these two can work >>together in a nice way. >> >>Interested? > > > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
