-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://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-
___
Zope-CMF maillist -
