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.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to