[Zope-PTK] CMF Dogbowl: workflow Proposal

[Chui Tey]

Shane,

I just had a look at the IDL bindings proposed by the Workflow Management
Coalition (www.wfmc.org) for standard workflow interfaces. The wfmc API is
huge and I'm not suggesting that we go down this route, but if we could use
similar names and nomenclature, it may relieve some confusion for potential
developers.  Furthermore, there is ready documentation from wfmc :-)

interface WorkflowObject {
    attribute WMTName name;
    attribute WMTId id;

   // Zope: akin to listActions
    void listValidStates (
        in Filter filter,
        in boolean countFlag,
        out WMTStates states,
        out long count);

    // Zope: doActionFor
    void changeState (in WMTState newState)
        raises (TransitionNotAllowed, InvalidState);

   // Zope: getStatusOf
    void getState ( out WMTState currentState);

   // Zope: we already get this from introspection
    void openAttributeList (
        in Filter filter,
        in boolean countFlag,
        out AttributeList attributes,
        out long count)
        raises (InvalidFilter);

   // Zope: __getattr__ ?
    void getAttributeValue (
        in WMTName name
        out Attribute attribute)
        raises (InvalidAttribute);

   // Zope: __setattr__ ?
    void assignAttribute ( in Attribute attribute)
        raises (InvalidAttribute, AttributeAssignmentFailed);

    void assignAttributes ( in Attributes attributes)
        raises (InvalidAttribute, AttributeAssignmentFailed);

Sticking as close to your new proposal, we query workflow_tool for an object
which inplements  I_WorkflowObject (this object might reference a document,
news item, or might be implemented by the document or news item). and then
subsequently perform actions on the Workflow Object.

----- Original Message -----
From: Shane Hathaway <shane@digicool.com>
To: <zope-ptk@zope.org>
Sent: Saturday, March 17, 2001 2:47 PM
Subject: Re: [Zope-PTK] CMF Dogbowl: workflow Proposal


> 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
>
> _______________________________________________
> Zope-PTK maillist  -  Zope-PTK@zope.org
> http://lists.zope.org/mailman/listinfo/zope-ptk
>
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
requests
>