Guido Casper <[EMAIL PROTECTED]> writes: > Continuations within a webapps are better than a FSMs because > the FSM approach is just a workaround for the lack of a > single-threaded view of my webapp and continuations brought > back that view to me. However for potentially everlasting > conditional (and rather detached) workflow state > transistions FSMs do not look like a workaround to me but > like the (or > one) solution. > > Page flow control mostly is rather small pieces of > potentially complex conditional logic with few branches (the > user "is passively guided" through the page flow) while > workflow logic looks like an everlasting loop of simple > conditional logic with potentially lots of branches (the > user "actively triggers" the workflow). I think I agree with you that continuations don't bring anything specifically to the work flow model. However, I believe that there is a continuum from flow to work flow; a sequence of screens is a sequence of screens. Where I draw the line is based on what the persistence requirements are: if a state must be persisted only across a browser request, Cocoon flow continuations are sufficient. However, if a state must be persisted across multiple browser sessions then continuations bring nothing to the table. Instead, you need an external state model that allows you to create (or recreate) the sequence of steps required to manipulate the "document" at any given point in time.
To put it another way, a work flow description tells us what sequence of screens must be presented dependant on the document instance and user at hand. Cocoon flow (and continuations) are a way to manage that work flow instance within a browser session. The issue that I think has to be solved is; how to take a generalized work flow model and turn it into a Cocoon flow. This raises many questions: - Can a database or document driven flow controller be created that is generalized enough to handle any work flow model? - Is there a nice way to map between some generalized flow model and Cocoon flow? In other words, what's the equivalent of Woody (ahem, cforms) templates for work flow? And, what's the equivalent of cforms transforms for work flow? - If we do this correctly does the requirement to write flowscript disappear and instead get turned into a requirement to just write a work flow template? (Even if it does, I bet writing flowscript would still be faster for writing small apps and prototypes).
