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

[Martin Aspeli]

Sidnei da Silva wrote:
> On 12/27/06, Martin Aspeli <optilude at gmx.net> wrote:
>> > 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.
> 
> That is always the case I believe on any default implementation using
> events. The power of firing the events is on empowering the
> extensibility of the framework. The decision on firing an event should
> be based on 'is this event useful outside the framework' not on 'is
> this event useful inside the framework'.

Right - that was the question I was asking. *Is* this an event that's 
useful outside the framework?

> I agree that the internal implementation can just stay as it is, but
> from an outside perspective, for people extending the framework,
> having the events being fired there is certainly helpful. New workflow
> implementations could choose between implementing 'notifySuccess' or
> using a event subscriber for example.

Okay. I still think (and I think we agree) that such an event 
fundamentally has a different type of "audience" than the before/after 
transition events in DCWorkflow (which use DCWorkflow-specific 
information that's generally useful in CMFCore, Plone and elsewhere). I 
won't try to do this refactoring in the patch I'm proposing, but of 
course it could be done later.

> state and transition are properties of DCWorkflow, as you don't see
> any mention of those in the WorkflowTool. Workflow Tool only deals
> with actions named by strings.

Thanks for clearing it up.

Martin