cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: Experience with workflow at Hippo Webworks
Date Mon, 08 Mar 2004 16:26:25 GMT
Guido Casper <> 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

- 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).

View raw message