[Zope-CMF] Re: Zope 3 events from workflow

[Martin Aspeli]

Sidnei da Silva wrote:
> On 12/27/06, Martin Aspeli <optilude at gmx.net> wrote:
>> I don't think I fully understand the use case or usage of
>> notifySuccess() and notifyException(). They are called by
>> portal_workflow, on the workflow definition. They don't seem to be used
>> in the current code at least.
> 
> There is at least two cases which you may or may not be aware of.
> Workflows other than DCWorkflow and multiple workflows.
> 
> If you have multiple workflows (or even a single workflow with
> multiple automatic transitions) you will have multiple events being
> fired.
> 
> 'notifySuccess' is called at the workflow-tool level, notifying each
> workflow associated with the object that an action has succeeded, no
> matter which workflow suceeded in fulfilling the action.
> 
> The confusing part here is that there's a 'notifySuccess' on the tool
> itself, and another in the workflow object.

Yes.

>> From looking at the tests and the code in the workflow tool, it
> appears that the tool's 'notifySuccess' and friends are never called
> directly by any internal code, but instead expected to be called by
> external code performing 'fancy stuff', to deliver notifications to
> any workflows associated with a certain object, without having to know
> which workflows are those. That certainly smells like events to me.
> 
> I agree that maybe this refactoring is lower priority, I'm just making
> sure it's not forgotten just because the main workflow used is
> DCWorkflow, and maybe clarifying some not-so-clear use cases beyond
> DCWorkflow's owns.

Right. It strikes me though, that if there will be a 
(zero-or-)one-to-one correspondence between subscribers and workflow 
definitions, then it may be easier to use the template method pattern 
(kinda) as we do now rather than decouple it with subscribers. 
Otherwise, you just end up with a few subscribers in separate functions 
that logically are tightly coupled with the workflow definition.

If on the other hand, there is a need for an open ended number of 
components outside workflow definitions to react to these events, then 
using zope.event subscribers makes sense. From the use cases I've seen, 
that's not really the case, though.

>> I think for code *outside* DCWorkflow/portal_workflow the most sensible
>> things to subscribe to would be the IBeforeTransitionEvent and
>> IAfterTransitionEvent events in my patch - you care that a transition is
>> about to happen or has just happened, much like we have script_before
>> and script_after.
> 
> But you just cover transitions from DCWorkflow. WorkflowTool is not
> just about DCWorkflow. Where do those stand in the light of events?

That's a good point. I'm not really clear on where the line goes between 
WorkflowTool and DCWorkflow. Are state and transition defs a property of 
WorkflowTool or DCWorkflow? Is WorkflowTool just concerned with abstract 
actions (named by strings)?

Martin