[Zope-CMF] Documenting DCWorkflow, an idea

Ulrich Eck lists@net-labs.de
Tue, 10 Jul 2001 10:15:37 +0200


For my understanding I made a state-machine-diagramm that shows the 
states and transitions of a default_workflow which is availiable 
(after a reviewer published it) under: 

http://cmf.zope.org/Members/jack-e/WorkflowDesign/CMFWorkflow


Every Object is in its "own" workflow form creation-time. the state
of an object defines what transitions can be made from there
(e.g. object is visible now you can hide or submit ...)
Every transition defines the state of the object after transit and
can limit its execution to special roles or dependent on a script that 
makes some checks (guard .. see Phillips answer to "a better workflow" 
in the mailinglist). within the workflow you can use your Variables
to store information that is not directly stored in the object but
needed for the work(flow). at last you can query the portal catalog
in a neat way by using the worklists to get objects of a certain
state to build the "joblists" for the responsible people ..

and a snippet i found in the archive:
---
[seb]
Whichever you use, the underlying concept is of a state machine, where
a transition between states results in changing the permissions on an 
object.  In the DefaultWorkflow the states are private, public, and
pending.  The transitions are retract, publish, and submit.  If you
look at updateMappingsFor in DefaultWorkflow, you'll see that
permissions get set dependent on state, following a transition.

The starting point in designing a workflow should be to write a state
machine diagram.  There's more pointers in the DCWorkflow docs.
---

thats how i understood it so far

hope this helps