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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Aspeli wrote:
> 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.

One case I know of that might obtain there is to allow for logging /
staging / versioning, etc. to happen as a result of workflow
transitions.  In fact, nearly *any* use case where you might use a
transition script today is a good example:  that there might be more
than one is pretty easy to arrange.

For BBB purposes (see below), my sense is that the "ObjectMoved"
exceptions should probably *not* change, although we should arrange to
publish appropriate events at the correct points, in order to allow
subscribers to respond.  One obvious candidate is a subscriber which
"fixes up" location-based indexes (the UID tool, the catalog, etc.).  We
would want those events to implement the same interfaces as the copy /
paste machinery.  Hmm, come to think of it, I don't know of any
reasonable implementation which would raise the 'ObjectMoved' or
'ObjectDeleted' exceptions which wouldn't *also* be using the
OFS.CopySupport, in which case publishing additional events would be
pointless.

>>> 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)?

Those actions were always intended to be "transitionish".  The
'notifyCreated', 'notifyBefore', 'notifySuccess', and 'notifyException'
methods were the original "event model" broadcasters, in fact:  the tool
"broadcast" those "events" to each of its workflow objects as subscribers.

There are at least a few apps out in production which are using
workflows defined in Python code, rather than as DCWorkflow instances.
We need to provide BBB for them, too (by preserving the semantics of
calling those 'notify' methods.)


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFk/8o+gerLs4ltQ4RAnn/AJ4sdt9Vc6ifpxPWjmJdjPOEYMqC8QCgo0Tq
XoV6dqFWVQJIzqxfjaNN/fw=
=jgCQ
-----END PGP SIGNATURE-----