Hi, I am writing a product through the ZMI (which extends Folder) that contains products of the same type (basically a hierarchical system). I want to be able to delete an arbitrary item and all of it's sub-items. The method that does this is a recursive deleteMe() python script. Here is the code that I am using: def deleteMe(root=1): children = context.objectIds('NavigationMenu') if (len(children)): for child in children: context[child].deleteMe(root=0) context.manage_delObjects(children) if (root==1): context.aq_parent.manage_delObjects(context.id) So, to me this looks like your standard recursive function (well, sort of). However, when I get to the bottom of the tree, context.objectIds contains siblings, not children. I would expect that if there were no children, objectIds would return []. I have tried using container instead of context, but that does not work, either. As an example, say we have the following hierarchy: menu1 - menu2 - menu3 - menu4 If I were to delete menu1, I would get an error inside menu2 like: BadRequest: m3 does not exist Sometimes I get attribute errors (e.g. __getitem__ doesn't exist), or keyerrors. The problem either happens in ObjectManager._getOb, or manage_delObjects. I get the feeling that *somehow* the context becomes menu1, even though the callback says it is really menu2. Otherwise, I don't understand how menu2.objectValues() would EVER know about it's siblings! Any ideas why this is happening? Do just not understand acquisition? Thank you so much for the help, Andy
Andrew Altepeter wrote at 2003-2-3 13:10 -0600:
I am writing a product through the ZMI (which extends Folder) that contains products of the same type (basically a hierarchical system). I want to be able to delete an arbitrary item and all of it's sub-items. The method that does this is a recursive deleteMe() python script.
Here is the code that I am using:
def deleteMe(root=1): children = context.objectIds('NavigationMenu') if (len(children)): for child in children: context[child].deleteMe(root=0) context.manage_delObjects(children) if (root==1): context.aq_parent.manage_delObjects(context.id) The standard way to delete a subhierarchie is:
* you have a single call to "manage_delObjects(ids)". It deletes the subtrees rooted in "ids". * you customize "manage_beforeDelete" when you need special operations before the object is deleted.
So, to me this looks like your standard recursive function (well, sort of). However, when I get to the bottom of the tree, context.objectIds contains siblings, not children. I would expect that if there were no children, objectIds would return []. It depends on the base classes inherited by your product class.
In my view, it is a bug that "SimpleItem.Item" implements Object Manager methods (it is not such a thing!). You, on the other hand, would like that and apparently got a base class that does not define these methods. Dieter
The standard way to delete a subhierarchie is:
* you have a single call to "manage_delObjects(ids)". It deletes the subtrees rooted in "ids".
* you customize "manage_beforeDelete" when you need special operations before the object is deleted.
Ahhh, thank you for that. I had originally thought of doing that, but then I wasn't sure if just that object was deleted (with the subobjects remaining, but not attached). But now that I think about it, since the subobjects are just 'variables' inside the top object, they would, and should be deleted.
So, to me this looks like your standard recursive function (well, sort of). However, when I get to the bottom of the tree, context.objectIds contains siblings, not children. I would expect that if there were no children, objectIds would return []. It depends on the base classes inherited by your product class.
In my view, it is a bug that "SimpleItem.Item" implements Object Manager methods (it is not such a thing!).
You, on the other hand, would like that and apparently got a base class that does not define these methods.
Which is strange to me, because when I setup the ZClass, I had it inherit from ZObject, and ZObjectManager. Ummm, now that I look again, it is ZFolder. But it should define those methods? Gosh, I'm still hazy why an object that inherits from ZObjectManager should return siblings (which it should not know about) when objectValues() was called? Andy
Dieter
participants (2)
-
Andrew Altepeter -
Dieter Maurer