Sidnei da Silva wrote:
Something that strikes me, by looking at this code is that we also
want events that map to 'notifySuccess' and 'notifyException' too (ie,
ITransitionSuccessEvent and ITransitionFailureEvent), not only
'before'/'after'. (see _invokeWithNotifications).
Those could be fired from the 'notifySuccess', etc. And the code that
is currently in 'notifySuccess' would move to a subscriber.
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.
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.
It seems to me notifyBefore(), notifySuccess() and notifyException() are
used internally by DCWorkflow to let the workflows set variables and
mutate objects as needed. If that is correct, then I'd say it's a
lower-priority refactoring (if it's inwardly focused rather than
enabling other code to react to workflow events more easily, and thus
outwardly-focused) and could be handled separately from this patch, to
keep things simple.
I guess that 'notifyCreated' could be replaced by a subscriber to
'IObjectCreatedEvent' or equivalent.
+1 to not inventing more events than we need to.
Martin
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
