[Zope-PTK] CMF Dogbowl: workflow Proposal

Shane Hathaway shane@digicool.com
Fri, 16 Mar 2001 23:47:31 -0500


Kent Polk wrote:
> I was considering how to hack 'recipients' into the cataloging but
> that looks like a really bad way to do it. 'recipients' really needs
> your:
> 
>  getCatalogVariablesFor(self, ob)
>     Invoked by portal_catalog. Allows workflows to add variables
>     to the catalog based on workflow status, making it possible to
>     implement queues. Returns a mapping containing the catalog
>     variables that apply to ob.
> (snip)
> Correct?

That's right.  If you isolate the workflow from the object type, the
workflow needs to implement getCatalogVariablesFor() and listActions().

> Now. This brings up the issue  of whether or not a RequestItem is
> a document-sort-of-object, and whether its actions are review-*
> actions.
> 
> (snip)
> 
> However, it appears to me that review-* actions are pretty hard-coded
> into the CMF at this point.

Think about it this way: if the new DefaultWorkflow.py weren't there,
how many references to "review*" would there be?  Unless we've missed
some, there would be none at all.  That means DefaultWorkflow.py fully
encapsulates the CMF default workflow.

Now imagine WorkflowTool.py being folderish and containing any number of
workflows similar to DefaultWorkflow, then using a UI to assign
workflows to types.  You could assign multiple workflows to a type,
making sub-workflows possible.  Then imagine those workflows being
created through the Web.  Imagine OpenFlow being adapted as simply an
object that gets added to the workflow tool.  There are more
possibilities...

So, if the default workflow doesn't quite fit, the intention is that you
replace or subclass DefaultWorkflow.  That doesn't mean you need to
change CMFCore, but until the WorkflowTool is folderish, it does mean
you need to make your own WorkflowTool.

Shane