On 27 Mar 2007, at 20:57 , Dieter Maurer wrote:
As so often, we have completely different views on how things
should be:
When I have an "IObjectBeforeDeleteEvent" subscriber which
should update the unique ID tool, then it can assume that
there is indeed a unique ID tool. And if the assumption is
wrong, an exception should result.
What makes you think you can make that assumption? This is Zope 2 all
over again, where things just have to be there. That won't help
making things more flexible.
We have this situation here: there should be (and is) a unique
id tool but the local registrations have not been performed.
Nope, we're just not operating in a place where we can get to the
tool. It's standard acquisition semantics.
An exception is better than silently omit the update of the existing
unique id tool.
You could argue that the local id tool does not need to be updated
as the complete site (including the tool) gets deleted.
Indeed.
But would the effect be different, if I used:
plone_site.some_folder.manage_deleteObjects(....).
Or in other words, is attribute lookup entailed in traversal?
No.
If it is not (which I assume), then your "defensive programming"
would hide inconsistencies in the unique id tool -- similar
to a "defensive try: .... except: pass".
What kind of inconsistencies? We're deleting the thing anyway, what's
the point to update it?
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
