I have been working with hurry.workflow in a project and had some 
questions about making hurry.workflow work with different work flows.

For this project each class can have a different work flow with it's own 
set of states and transitions. All of the instances of a given class 
share the same work flow.

To create these different work flows I have registered a utility for 
each class. The utility has a factory that creates instances of 
hurry.workflow.workflow.Workflow initialized with the correct set of 
transitions for that type. The utilities are named, to allow more than 
one utility to register for the hurry.interfaces.IWorkflow interface.

With many IWorkflow utilities the WorkflowInfo implementation can not 
find the utility it needs. So I changed the WorkflowInfo behavior by 
having it look for a named utility based on the class name of the 
instance. For example the work flow utility for the class 'Cat' is 
registered with the name "project.workflow.Cat" which I selected the 
pattern "project.workflow.{className}" to try and avoid naming conflicts.

This solution seems to work well for the project I am working on, 
however I am quite new to Zope and this is the first time I've made 
these kinds of modifications.

Does anyone have any thoughts about how this implementation could be 
improved, it doesn't feel like I'm taking the best advantage of the 
component model? If I could come up with a set of patches, would the 
change to a class based work flow be useful to include in hurry.workflow?



Michael Shaw
Nunatak Systems Pty Ltd
15 Princes Street
Sandy Bay Tasmania 7005
P: 61 3 6223 7875
F: 61 3 6226 1887
e: michael.s...@nunatak.com.au
w: www.nunatak.com.au

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to