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
'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.
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
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
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)?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests