Sidnei da Silva wrote:
On 12/27/06, Martin Aspeli <[EMAIL PROTECTED]> 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
_______________________________________________
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
