[Zope-CMF] WorkflowMethod

[Tres Seaver]

On Sun, 2003-01-26 at 13:57, Florent Guillaume wrote:
> In article <15903.11263.344652.310285@gargle.gargle.HOWL> you write:
> > The idea (old use cases found on "cmf.zope.org") has been that
> > you can control the method execution by your workflow:
> > 
> >   When the worflow state does not allow the corresponding transition.
> >   you cannot call the method.
> > 
> > Unfortunately, this is broken in CMF 1.3:
> > 
> >   When the workflow state does not allow the transition, the
> >   method is called anyway.
> 
> 
> Yeah, that pretty much defeats the point of having workflow methods...

Actually, there was another use case for workflow methods:  they could
be wrappers around "non-transition" methods, which existed only to
"trigger" the workflow machinery.

For instance, if you have automatic transitions in your workflow, then
you would like any method which modifies the workflowed object to notify
the workflow, in case the modifications would allow one of them to
fire.  That rationalization is why 'edit' was originally wrapped.  You
can think of such a method as a "virtual transition" back to the same
state.

> 
> I'm inclined to patch it, as I too need such functionnality.
> 
> It would probably mean either:
> 
>  - removing all workflowAction wrappings from CMFDefault, because the
>    standard workflows don't have the correct transitions,
> 
>  - adding the necessary transitions (edit, setFormat, editMetadata)
>    to the default workflows,
> 
>  - adding a global boolean flag to the workflow tool that says "enforce
>    workflow methods".
> 
> Opinions?

A downside to using wrapped workflow methods is that the underlying
Python class has to do the wrapping, which makes it a "hard-wired"
policy choice, at least for the use case I outlined above.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com