[Checkins] SVN: Products.DCWorkflow/trunk/Products/DCWorkflow/doc/ Documentation reformatted as ReST and available at the top-level of the package.
Charlie Clark
cvs-admin at zope.org
Fri Sep 7 09:49:53 UTC 2012
Log message for revision 127764:
Documentation reformatted as ReST and available at the top-level of the package.
Changed:
D Products.DCWorkflow/trunk/Products/DCWorkflow/doc/actbox.stx
D Products.DCWorkflow/trunk/Products/DCWorkflow/doc/basics.stx
D Products.DCWorkflow/trunk/Products/DCWorkflow/doc/expressions.stx
D Products.DCWorkflow/trunk/Products/DCWorkflow/doc/howto.stx
D Products.DCWorkflow/trunk/Products/DCWorkflow/doc/worklists.stx
-=-
Deleted: Products.DCWorkflow/trunk/Products/DCWorkflow/doc/actbox.stx
===================================================================
--- Products.DCWorkflow/trunk/Products/DCWorkflow/doc/actbox.stx 2012-09-07 09:39:22 UTC (rev 127763)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/doc/actbox.stx 2012-09-07 09:49:48 UTC (rev 127764)
@@ -1,30 +0,0 @@
-
-Names and URLs for the actions box can be formatted using standard Python
-string formatting. An example::
-
- %(object_url)s/content_submit_form
-
-The string '%(object_url)s' will be replaced by the value of object_url.
-The following names are available:
-
-- portal_url
-
-- folder_url
-
-- object_url
-
-- user_id
-
-- count (Available in work lists only. Represents the number of items in
- the work list.)
-
-The following names are also available, in case there is any use for them.
-They are not strings.
-
-- portal
-
-- folder
-
-- object
-
-- isAnonymous
Deleted: Products.DCWorkflow/trunk/Products/DCWorkflow/doc/basics.stx
===================================================================
--- Products.DCWorkflow/trunk/Products/DCWorkflow/doc/basics.stx 2012-09-07 09:39:22 UTC (rev 127763)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/doc/basics.stx 2012-09-07 09:49:48 UTC (rev 127764)
@@ -1,59 +0,0 @@
-
-This product can be added to the portal_workflow tool of CMF site.
-It provides fully customizable workflow.
-
-To see an example, after installing DCWorkflow, using the "Contents"
-tab of your portal_workflow instance add a "CMF default workflow (rev 2)"
-instance. The other way to create it is to add a "Workflow" object,
-selecting "dc_workflow" as the type. The second way will create a
-blank workflow.
-
-This tool is easiest to use if you draw a state diagram first. Your
-diagram should have:
-
-- States (bubbles)
-
-- Transitions (arrows)
-
-- Variables (both in states and transitions)
-
-Remember to consider all the states your content can be in. Consider
-the actions users will perform to make the transitions between states.
-And consider not only who will be allowed to perform what functions,
-but also who will be *required* to perform certain functions.
-
-On the "States" tab, add a state with a simple ID for each state on
-your diagram. On the "Transitions" tab, add a transition with a simple
-ID for each group of arrows that point to the same state and have
-similar characteristics. Then for each state choose which transitions
-are allowed to leave that state.
-
-Variables are useful for keeping track of things that aren't very well
-represented as separate states, such as counters or information about
-the action that was last performed. You can create variables that get
-stored alongside the workflow state and you can make those variables
-available in catalog searches. Some variables, such as the review
-history, should not be stored at all. Those variables are accessible
-through the getInfoFor() interface.
-
-Worklists are a way to make people aware of tasks they are required
-to perform. Worklists are implemented as a catalog query that puts
-actions in the actions box when there is some task the user needs to
-perform. Most of the time you just need to enter a state ID,
-a role name, and the information to put in the actions box.
-
-You can manage all of the actions a user can perform on an object by
-setting up permissions to be managed by the workflow. Using the
-"Permissions" tab, select which permissions should be state-dependent.
-Then in each state, using the "permissions" tab, set up the
-role to permission mappings appropriate for that state.
-
-Finally, you can extend the workflow with scripts. Scripts can be
-External Methods, Python Scripts, DTML methods, or any other callable
-Zope object. They are accessible by name in expressions. Scripts
-are invoked with a state_change object as the first argument; see
-expressions.stx.
-
-Once you've crafted your workflow, you hook it up with a content type
-by using the portal_workflow top-level "Workflows" tab. Specify the
-workflow name in the target content type's box.
Deleted: Products.DCWorkflow/trunk/Products/DCWorkflow/doc/expressions.stx
===================================================================
--- Products.DCWorkflow/trunk/Products/DCWorkflow/doc/expressions.stx 2012-09-07 09:39:22 UTC (rev 127763)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/doc/expressions.stx 2012-09-07 09:49:48 UTC (rev 127764)
@@ -1,52 +0,0 @@
-
-DCWorkflow Expressions
-
- Expressions in DCWorkflow are TALES expressions.
-(See the <a href="http://zope.org/Documentation/Books/ZopeBook">Zope Book</a>
-for background on page templates and TALES.)
-Some of the contexts have slightly different meanings from what is provided
-for expressions in page templates.
-
-- 'here' -- The content object
-
-- 'container' -- The content object's container
-
-Several other contexts are also provided.
-
-- 'state_change' -- A special object containing info about the state change
-
-- 'transition' -- The transition object being executed
-
-- 'status' -- The former status
-
-- 'workflow' -- The workflow definition object
-
-- 'scripts' -- The scripts in the workflow definition object
-
-'state_change' objects provide the following attributes:
-
-- 'state_change.status' -- a mapping containing the workflow status.
-
-- 'state_change.object' -- the object being modified by workflow.
-
-- 'state_change.workflow' -- the workflow definition object.
-
-- 'state_change.transition' -- the transition object being executed.
-
-- 'state_change.old_state' -- the former state object.
-
-- 'state_change.new_state' -- the destination state object.
-
-- 'state_change.kwargs' -- the keyword arguments passed to the
- doActionFor() method.
-
-- 'state_change.getHistory()' -- returns a copy of the object's workflow
- history.
-
-- 'state_change.getPortal()' -- returns the root of the portal.
-
-- 'state_change.ObjectDeleted' and 'ObjectMoved' -- exceptions that
- can be raised by scripts to indicate to the workflow that an object
- has been moved or deleted.
-
-- 'state_change.getDateTime()' -- returns the DateTime of the transition.
Deleted: Products.DCWorkflow/trunk/Products/DCWorkflow/doc/howto.stx
===================================================================
--- Products.DCWorkflow/trunk/Products/DCWorkflow/doc/howto.stx 2012-09-07 09:39:22 UTC (rev 127763)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/doc/howto.stx 2012-09-07 09:49:48 UTC (rev 127764)
@@ -1,46 +0,0 @@
-From: John Morton <jwm at plain.co.nz>
-
-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
- details.
-
-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
- semicolon.
-
-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.
Deleted: Products.DCWorkflow/trunk/Products/DCWorkflow/doc/worklists.stx
===================================================================
--- Products.DCWorkflow/trunk/Products/DCWorkflow/doc/worklists.stx 2012-09-07 09:39:22 UTC (rev 127763)
+++ Products.DCWorkflow/trunk/Products/DCWorkflow/doc/worklists.stx 2012-09-07 09:49:48 UTC (rev 127764)
@@ -1,7 +0,0 @@
-
-Worklists are predefined catalog queries.
-
-When defining a variable match, you can enter a list of possible matches
-separated by semicolons. In addition, the matches will be formatted
-according to the rules described in "actbox.stx":actbox.stx.
-This way you can enter "%(user_id)s" to match only the current user.
More information about the checkins
mailing list