防止删除 Plone 中的文件夹（类型），除非删除父文件夹
我想防止删除 Plone 中文件夹类型的实例，除非删除父文件夹。我有预感，事件处理程序可以防止删除（在绑定到标记接口的 IObjectRemovedEvent 处理程序中引发异常），但实现此规则的异常似乎更难确定：我想允许删除项目的父文件夹时删除该项目。
我最初的预感是我可以遍历 __parent__ 指针并检查是否在要删除的父级（或某些远程间接容器）上设置了属性，但我不确定如何设置它在尝试删除所包含的子项之前删除父项的属性（否则不允许删除）。所以现在，我在质疑我是否以正确的方式处理这个问题？我是否误解了在 Plone 中删除对象的问题限制？我应该寻找 plone.app.linkintegrity 源来借用技巧吗？
我的用例：“项目”文件夹内的“设置文件夹”——本质上，除非项目文件夹本身被删除，否则绝对不允许删除设置文件夹。我想我是在要求一个非常具体的包含关系的引用完整性。
如何防止对象被删除，除非该对象是由于其父对象被删除而直接导致被删除的情况？
I want to prevent deletion of instance of a folderish type in Plone, excepting when a parent folder is being deleted. I have a hunch that an event handler can prevent deletion (raise an exception in an IObjectRemovedEvent handler bound to a marker interface), but implementing the exception to this rule seems harder to pin down: I want to allow deletion of the item when its parent folder is being deleted.
My initial hunch was that I could traverse __parent__ pointers and check if an attribute was set on the parent (or some distant indirect container) that it was being deleted, but I am not sure how I would set this attribute on deletion of the parent prior to an attempt to delete the contained child (otherwise not allowing deletion). So now, I'm questioning whether I am approaching this the right way? Am I misunderstanding the problem constraints for deleting objects in Plone? Should I look to plone.app.linkintegrity source to borrow tricks?
My use case: a "settings folder" inside a "project" folder -- intrinsically, the settings folder should never be allowed to be deleted unless the project folder itself is being deleted. I guess I'm asking for referential integrity for a very-specific containment relationship.
How would you prevent deletion of an object except in the case it was being deleted as a direct result of its parent being deleted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过相当长的一段时间，我终于找到了这个普遍问题的解决方案（但在不同的上下文中）：
因此，只有在尝试删除对象本身时才会引发异常，而在删除其父对象时则不会引发异常。
请参阅示例： http://bazaar.launchpad.net /~upiq-dev/upiq/dev-uu.formlibrary/revision/113
After a fair bit of time, I have finally found a solution to this general problem (but in a different context):
By consequence, an exception is only raised if an attempt is made to delete the object itself, but not when its parent is deleted.
See example: http://bazaar.launchpad.net/~upiq-dev/upiq/dev-uu.formlibrary/revision/113