[CMF-checkins] CVS: CMF/DCWorkflow/doc - howto.stx:1.1
Fri, 28 Jun 2002 14:15:50 -0400
Update of /cvs-repository/CMF/DCWorkflow/doc
In directory cvs.zope.org:/tmp/cvs-serv549
Added small tutorial by John Morton describing how to create a new
=== Added File CMF/DCWorkflow/doc/howto.stx ===
From: John Morton <firstname.lastname@example.org>
Here's how I generally go about putting together a new workflow:
1. Draw up a state diagram with the nodes as states and the arcs as
transitions. I usually do this on paper, then do a good copy in dia
or some other diagram tool, so I have an image to go with the
documentation. I usually spot several corner cases in the process.
2. Start by creating an example DCworkflow, rather than a new one, as
it's faster to delete all the states and transitions than it is to
create all the standard review_state variables.
3. In the permissions tab, select all the permissions that you want the
workflow to govern.
4. Define any extra variables that you need.
5. Set up the states for your workflow, one for each node in your state
diagram. Try to stick to the standard names for a publication
workflow, as some badly behaved products have states like 'published'
hardcoded into their searches (ie CalendarTool, last I looked). Set
up the permissions on the states now, as well. I find that using
acquisition for the site visible states, and using explicit
permissions for the private and interim states works well. Reviewer
roles should either have view permissions on every state or you
should change the appropriate skins to take them somewhere sensible
after a transition or they'll end up with an ugly access denied page
after sending some content back to private state.
6. Set up any scripts that you'll need for transitions - pre and post
transition scripts and ones to handle complex guard conditions. Just
set up skeletons for now, if you haven't though through all the
7. Create your transitions from all the arcs on your state diagram. You
should be able to pick the right destination state as all your states
are already defined, and set up the right scripts to run, as you've
defined those as well. It's worth noting that the guards are or'ed -
if any guard matches, the transition can occur. You can specify more
than one permission, role or expression by separating them with a
That about covers it. By working in this order, you tend to step through
the creation process one tab at a time, rather than switching back and
forth. I find it tends to be faster and less confusing that way.