[Zope-CMF] Re[2]: DCWorkflow + Acqusition

[Victor Safronovich]

Hello Tres Seaver,

Tuesday, October 11, 2005, 5:52:19 PM, you wrote:

Tres, thank you for your help!
I  use  3  way  in  the future, like using CMFUID, but i have my own uids for my
objects.

Meanwhile in the begining of the '__do_something_with_my_object__' i use
try:
   aq_parent(aq_inner(my_object))._getOb(my_object.getId())
except AttributeError:
   my_object  =  my_object.getObjectByUid(my_object.getUid()) # my methods, this
                                                              # rewrapps my_object


TS> The call chain looks like:

TS>   <your code> ->
TS>     wf_tool.doActdionFor(...) ->
TS>       wf_tool._invokeWithNotification
   Yes.

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

>>   Or may be i use WorkflowTool wrongly.

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

TS> Here are a couple of alternate strategies:

TS>  - You could modify the workflow action's result (which is coming from
TS>    the code which actually raises the ObjectMoved exception) to include
TS>    the newly-wrapped object in the result (e.g., as a tuple with the
TS>    current result).
   Question from other topic: What doActionFor usually returns?
   
   DCWorkflowDefinition.doActionFor returns usually None, but
   DCWorkflowDefinition.wrapWorkflowMethod  returns result of the custom method.


TS>  - You could move the code in '__do_something_with_my_object__' into an
TS>    "after" script of the workflow, where it would be passed the object
TS>    in its new wrappers.
   this is usefull too, because portal_workflow do reindexObject with new dict
   that  getCatalogVariablesFor  method  returned,  but  usually  i  have  many
   ZCatalogs   that  indexed  my_object  (  though  this  fixed  by  overriding
   reindexObject method )

TS>  - You could use the CMFUID tools, and find the object in its new
TS>    location after running the workflow transition using its UID.
   the best solution :)

   Or, may be added to ImplicitAcquisionWrapper new method 'aq_rewrap'
   for example
>>> l = [1,2,3]
>>> def list_modification1(l):
        l = [3,2,1]

>>> def list_modification2(l):
        l[:] = [3,2,1]

>>> list_modification1(l)
>>> l
[1, 2, 3]
>>> list_modification2(l)
>>> l
[3, 2, 1] <-- changed the list

wrapper = ImplicitAcquisitionWrapper( obj, container )
ImplicitAcqusitionWrapper sets 2 C attributes

  self->obj=obj;
  self->container=container;

and  ImplicitAcqusitionWrapper.aq_rewrap( self, container )  sets  new container to
self->container.
And use aq_rewrap instead of ObjectMoved.getNewObject.

Is this usefull, and do i need to send this to zope-dev at zope.org?

-- 
Best regards,
 Victor Safronovich
 NauMen.NauDoc.SoftwareDeveloper  http://www.naumen.ru