need lesson in zope's OO architecture
hi list, i built a special object in zope, which holds most of its data outside of ZODB (in mySQL) obviously i had to override the _delObject() method, that at deletion of the zope object my external data is deleted too for better control of these special objects i built a special folder, which holds those objects my problem - when my special folder is subfolder of a normal folder, and this normal folder is renamed, the rename method of the above normal folder is triggered but a rename does deletion of the children object and creates a new one that means _my_ delObject() from special folder and special objects is executed and kills my external data )-: v v v v v v v v v v v v v v v v v v v v v v v v v v def manage_renameObject(self, id, new_id, REQUEST=None): ... ... ob=self._getOb(id) ... ... self._delObject(id) ## this destroys my external data ob = aq_base(ob) ob._setId(new_id) ... ... v v v v v v v v v v v v v v v v v v v v v v v v v v the problem seems for me that methods from parent container take actions on their children and children can never distinguish between delete by renaming and real delete a similar problem is cut / copy / paste where i cannot decide if copying my special object (for copy/paste) or doing nothing (for cut/paste) i have no idea how to solve this (without rewriting core zope elements like CopySource, ObjectManager), because i cannot get control over the parent objects from my folder do i heavily misunderstand something ??? can i solve this problem somehow ??? thank you for every input fritz (-:fs)
Hi Fritz, my best guess is that you should redefine the manage_copy/manage_rename for your special folder object, so that they could not be removed if they are not empty. This is the first hack I could think of. Best regards. Paolo -- Paolo Bizzarri - President - Icube S.r.l. Address: Via Ridolfi 15 - 56124 Pisa (PI), Italy E-mail: p.bizzarri@icube.it Web: http://www.icube.it Phone: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588
Am Dienstag, 27. Juli 2004 09:12 tippte Paolo Bizzarri:
Hi Fritz,
my best guess is that you should redefine the manage_copy/manage_rename for your special folder object, so that they could not be removed if they are not empty.
This is the first hack I could think of.
<thx> - you led me to the right way i have to combine this redefinings with forbidding to create my special folder in other than root directory thank you paolo best regards fritz (-:fs)
friedrich steindl wrote at 2004-7-26 22:24 +0200:
... for better control of these special objects i built a special folder, which holds those objects
my problem -
when my special folder is subfolder of a normal folder, and this normal folder is renamed, the rename method of the above normal folder is triggered
but a rename does deletion of the children object and creates a new one
A "rename" does not delete the object (nor the children thereof).
that means _my_ delObject() from special folder and special objects is executed and kills my external data )-:
Your "_delObject" is not called -- unless you do it in "manage_beforeDelete"...
... def manage_renameObject(self, id, new_id, REQUEST=None): ... ... ob=self._getOb(id) ... ... self._delObject(id) ## this destroys my external data
This does not delete the object but just removes it from "self" -- and it calls the object's "manage_beforeDelete".
From your description, the "_delObject" above is not your "_delObject" but the (normal) "_delObject" of a (normal) folder ... the problem seems for me that methods from parent container take actions on their children
They do not do this. However, they call the childrens "manage_beforeDelete" method such that they can take appropriate actions (such as uncataloguing, for example). Unfortunately, the "manage_afterAdd/manage_beforeDelete" protocol is too weakly implemented. These hook are not informed whether the delete comes from a true deletion or instead a rename or move (and analoguously for add). Therefore, I was forced to implement an extension, described as follows: '''Enhanced Copy Support. Zopes standard copy support is quite weak. Its calling of 'manage_afterAdd', 'manage_beforeDelete' and 'manage_afterClone' is not distinguished enough for copying versus moving on one hand and moving versus deleting on the other hand. Standard Zope calls (maybe indirectly): creation - 'manage_afterAdd' (via '_setObject') copying - '_getCopy', 'manage_afterAdd' (via '_setObject'), 'manage_afterClone' moving(renaming) - 'manage_beforeDelete' (via '_delObject'), 'manage_afterAdd' (via '_setObject'), deleting - 'manage_beforeDelete' (via '_delObject') The enhanced copy support adds the attribute '_v_EnhancedCopySupport__Operation' to the copied/moved object. Its value is 'COPY' for a copy operation and 'MOVE' for a move operation. For creation and deletion the attribute is not defined. This allows 'manage_afterAdd' and 'manage_beforeDelete' to check in which context they are used. We still do not distinguish between creation and import. The enhancements are instantiated via 'monkey patching'. **ATT**: it may come too late, to be effective everywhere. ''' The implementation looks like this: def manage_pasteObjects(...): ... ob._p_sticky = 1 # prevent "_v_" loss ob._v_EnhancedCopySupport__Operation= COPY try: self._setObject(id, ob) finally: del ob._v_EnhancedCopySupport__Operation ... def manage_renameObject(...): ... ob._p_sticky = 1 # prevent "_v_" loss ob._v_EnhancedCopySupport__Operation= MOVE try: self._delObject(id) ob = aq_base(ob) ob._setId(new_id) # Note - because a rename always keeps the same context, we # can just leave the ownership info unchanged. self._setObject(new_id, ob, set_owner=0) finally: del ob._v_EnhancedCopySupport__Operation ... ... Note that in order to make this extension safe against subtransactions (which may discard "_v_" attributes), you need my ZODB "_p_sticky" extension. I posted it as a patch to "zodb-dev@zope.org" (--> mailing list archive). While the "CopySupport" enhancement can be installed as a "monkey patch", the "_p_sticky" extension is partly C level and requires your own ZODB version... -- Dieter
dieter, thanks for your detailed explanation i could not clearly distiguish between methods operating on containers and those (hooks) operating on contained objects now the concept is much clearer for me --------------------------------------------------------------------------------------------- Am Dienstag, 27. Juli 2004 21:33 tippte Dieter Maurer: ...
Your "_delObject" is not called -- unless you do it in "manage_beforeDelete"...
this was one of my big misunderstandings actually 'manage_beforeDelete' deletes my external data and not '_delObject' -----------------------------------------------
'''Enhanced Copy Support. ... ... Note that in order to make this extension safe against subtransactions (which may discard "_v_" attributes), you need my ZODB "_p_sticky" extension. I posted it as a patch to "zodb-dev@zope.org" (--> mailing list archive). While the "CopySupport" enhancement can be installed as a "monkey patch", the "_p_sticky" extension is partly C level and requires your own ZODB version...
can i hope this will be integrated into one of the future versions of zope (zodb) ? ---------------- thanks again fritz (-:fs)
participants (3)
-
Dieter Maurer -
friedrich steindl -
Paolo Bizzarri