At 10:25 AM 4/7/2002 -0500, Ivelin Ivanov wrote: >From: "Ovidiu Predescu" <[EMAIL PROTECTED]> >To: "Ivelin Ivanov" <[EMAIL PROTECTED]> >Sent: Friday, April 05, 2002 10:33 PM > > Workflow's approach appears to be based on a finite state machine > > model. Checkout the sample control file at: > > >http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow/src/wizard-de >mo/WEB-INF/wizard.xml?rev=1.1&content-type=text/vnd.viewcvs-markup > > > > The same approach can be modeled in Cocoon today using actions.
Does anyone have an example of this? The current action example (the standard sample webapp) is fairly sketchy, and it's not clear how to do a more complex workflow. > > However a much better approach is the one based on > > continuations. Check out the Schecoon calculator sample at: > >I have actually seen it and was hoping that you can elaborate a bit on the >advantages of continuations vs. state machine. I agree. Also, I'm fairly concerned by two things: 1) Continuations are notoriously difficult to understand; building them as the fundamental (and, if I understand Stefano's predilections, *only!*) mechanism of webapp flow control is going to do some damage to Cocoon's comprehensibility. 2) Continuations are difficult to evaluate for performance. A procedural model, with explicit webapp state management, at least makes it clear to the programmer how much state is being kept by their webapp, and gives them more or less full control over tuning that state. A continuation mechanism could radically change the amount of retained state (consider the possibility of inadvertent variable capture of large data structures by a continuation stack!). And it might or might not be *possible* for the end programmer to fix those capture issues. Perhaps Ovidiu's proposed uses of continuations are elegant enough, or the current scripting/continuation-capture mechanism is efficient and minimal enough, to address both these concerns. But personally I would very much hope that the flowmap mechanism allows (not requires, but allows) a more procedural style as well, with explicit state management. You do not need to listen to me very closely, however, as I am under enough time pressure with my current project (constructing a fairly complex multi-page form-based issue tracking system) to drive me to work with Struts instead. It's a shame, as Cocoon seems more like the right thing, but I don't have time to struggle with the documentation (or lack thereof), or to wait for Schecoon to mature into something straightforwards. I hope this changes in the very near future (i.e. I hope Cocoon/Schecoon get better documentation & examples, or I get more time, or both :-) Cheers, Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
