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

2007-01-03 Thread Chris Withers

Martin Aspeli wrote:

To subscribe only to particular transitions, you would need for each
transition object to provide a specific interface. 


Unless you could leverage the same kind of thing that makes named 
adapters work...



zope.event?), it registers a general subscriber for IObjectEvent and then
redispatches for multi-subscribers based on (obj, event), i.e. you register
a handler for the object type and for the event type.


I actually don't like this pattern, it seems needlessly inefficient. Why 
not just set the right damned event going from the start? ;-)



We could do the same for a transition event, e.g. re-dispatching based on
object type, workflow type and/or transition type.


Sounds like it would fit the idiom, even if I don't like it...


However, in DCWorkflow, transitions are all of the same type, just with
different ids, and in WorkflowTool, actions (of which DCWorkflow transitions
are one common type) are also identified by a string only.


See my comment about named thingies above, although this is largely hand 
waving on my part...



It would be possible to define some kind of re-dispatch that used named
adapters, but even though subscribers are just adapter factories under the
hood (you'll see the slightly odd syntax of a loop that just retrieves all
possible adapters from the component registry, doing nothing with the return
values, because the event subscriber registry is using the same mechanism as
the adapter factory registry, but the factory that is called normally does
the event work), I don't think there's any natural syntax for registering
named subscribers. You *could* do this though:

@zope.component.adapter(Interface, IWorkflowTransitionEvent)
def dispatch_transitions(obj, event):
transition = event.transition.id
factory = getMultiAdapter((obj, event),
provides=INamedTransitionSubscriber, name=transition)

subscriber handler=.dispatch.dispatch_transitions /

- which would be generic and only be needed once.

and then for each transition:

@zope.component.implementer(INamedTransitionSubscriber)
@zope.component.adapter(IMyObject, IWorkflowTransitionEvent)
def react_to_published(obj, event):
...

and in ZCML:

adapter factory=.subscribers.react_to_published name=publish /

I'm not sure this is any easier or less hacky than doing the subscriber
like:

@zope.component.adapter(Interface, IWorkflowTransitionEvent)
def dispatch_transitions(obj, event):
transition = event.transition.id
if transition == 'publish':
   ...


Yeah, decorators suck when abused and zcml just sucks ;-)

*sigh*

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
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


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

2007-01-02 Thread Chris Withers

Hi All,

Martin Aspeli wrote:

class IWorkflowEvent(IObjectEvent):
A workflow related event


wf_name = TextLine(title=uThe name of the workflow this event is 
part of)


transition = TextLine(title=uThe name of the transition taking place)

state_before = TextLine(title=uThe object's state before the 
transition)


state_after = TextLine(title=uThe object's state after the 
transition)


I know I'm very late on this (sorry for taking a christmas vacation ;-) 
but how would I go about subcribing to a particular transition of a 
particular workflow?


This feels like the most common case for me, but it would seem that if 
you want to do that with the current patch, you'd have to have a generic 
subscriber that then if/then/else'd its way to only doing the right 
thing for the right workflow and the right transition.


I thought avoiding that kind of if/then/else'ing was what event 
subscribers were all about.


Hopefully I'm just missing something, could someone enlighten me?
(and by enlighten, I don't mean anything involving automotive fuel and 
matches :-P)


cheers,

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
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


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

2006-12-27 Thread Jens Vagelpohl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am I right in thinking that DCWorkflow does not send any Zope 3  
events? I'm not terribly familiar with that code, but some grepping  
suggests so.


Do you agree this would be useful? (I've got a pretty strong need  
for it  for Plone 3, i.e. CMF 2.1 - I'm sure we can work around it  
in Plone, but I'd rather do it properly)


It is definitely useful in the general migration towards more event- 
based processing.



I'm not quite sure where the best place to execute the event is.  
One option may be DCWorkflow/DCWorkflow.py, in notifyBefore() and  
notifySuccess(). Here, though, I get a bit confused about how to  
construct the wf_name and state_before/state_after parameters. I  
guess they're not always needed, but they seem like they'd be  
useful to most event handlers.


Eyeballing the code seems to suggest  
DCWorkflowDefinition._executeTransition as the place where both the  
old state and the new state are known.


If events are used I'm not sure what the notify*-Methods would be  
used for anymore.


jens



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFkixRRAx5nvEhZLIRAhABAJ0fM03/aTdY+1veRoIspYPi8HlYnwCcC5s+
xRrn5/5kVykwWZsJc8w75Ng=
=8MLg
-END PGP SIGNATURE-
___
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