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.


But would the effect be different, if I used:


Or in other words, is attribute lookup entailed in traversal?


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  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to