[Zope-CMF] Re: DCWorkflow + Acqusition

2005-10-25 Thread Florent Guillaume

Victor Safronovich wrote:

Hello Florent Guillaume,

Monday, October 24, 2005, 7:47:43 PM, you wrote:

FG They're not skipped, they're treated specially. These exceptions are the way
FG for transition code to notify the caller that something happened to the 
FG underlying object.

   But what preventtoraiseObjectMoved,   ObjectDeleted   in

That's not what these methods are for. ObjectMoved and ObjectDeleted are 
designed to be raised by workflow scripts, during the transition, to inform 
the workflow machinery that the transition left the object in an unexpected 

notifySuccess marks the end of the transition, and is designed similarly to 
an event mechanism, to inform interested parties that the transition is 
complete. If it raises exceptions, then they won't be caught.


  I.e.  DCWorkflowDefinition.notifyCreated

   swallow ObjectDeleted, ObjectMoved. Why?
   if ObjectMoved raised in DCWorkflowDefinition.notifyCreated,
   WorkflowTool.notifyCreated doen`t know about that, and
   def notifyCreated(self, ob):

Notify all applicable workflows that an object has been created
   and put in its new place.
   wfs = self.getWorkflowsFor(ob)
   for wf in wfs:
   self._reindexWorkflowVariables(ob)   --   ob  reindexed  in  a  wrong
   acquisition wrapper.

Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: DCWorkflow + Acqusition

2005-10-11 Thread Tres Seaver
Hash: SHA1

Victor Safronovich wrote:
 Hello zope-cmf-dev!
   I have a question about DCWorkflow, WorkflowTool and Acqusition.
   My  object,  during  change  state,  move  to  another folder and should 
   acqusition wrapper.
   workflow_tool = getToolByName( my_object, 'portal_workflow')
   workflow_tool.doActionFor( my_object, 'some_action' )
   # during doActionFor raised ObjectMoved but i don`t know about that in here
   # because WorkflowTool._invokeWithNotification shallow it.
   # so my_object has old acqusition wrapper.
   print aq_chain( my_object ) #wrong result
   my_object.reindexObject()   #   my_object  reindexed  on  the wrong path ( 
   #  path), but my_object has new physical path :(
   i think i should subclassing from WorkflowTool and override doActionFor
   Buthowcan   i   repaire   wrapper?  if  i  create  new  wrapper in 
   doActionFor,  method namespace has old wrapped object.

The call chain looks like:

  your code -
wf_tool.doActdionFor(...) -

Both of the tool methods return the result of calling the action.  In
cases where the ObjectMoved exception is raised, the exception has the
new object wrappers available, but the tool consumes that part of the
information (as you note).

   Or may be i use WorkflowTool wrongly.

Not really;  but the tool doesn't expect that you will need reindex the
object (it already does that in the new location).

Here are a couple of alternate strategies:

 - You could modify the workflow action's result (which is coming from
   the code which actually raises the ObjectMoved exception) to include
   the newly-wrapped object in the result (e.g., as a tuple with the
   current result).

 - You could move the code in '__do_something_with_my_object__' into an
   after script of the workflow, where it would be passed the object
   in its new wrappers.

 - You could use the CMFUID tools, and find the object in its new
   location after running the workflow transition using its UID.

Hope that helps,

- --
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests