Lifecycle Event Subscribers

A set of subscribers for the object zope.lifecycle events.

There are two key differences from the subscribers that come with the zope.intid package.

This does not register/unregister a zope.keyreference.IKeyReference with the intid utilities. Instead, it registers the actual object, and the events that are broadcast are broadcast holding the actual object.

IKeyReferenceces, especially KeyReferenceToPersistent, are used for a few reasons. First, they provide a stable, object-identity-based pointer to objects. To be identity based, this pointer is independent of the equality and hashing algorithms of the underlying object. Identity-based comparisons are necessary for the classic zope.intid utility implementation which uses a second OIBTree to maintain the backreferece from object to assigned intid (clearly you don’t want two non-identical objects which happen to compare equally now to get the same intid as that condition may change). Likewise, these references are all defined to be mutually comparable, no matter how they are implemented, a condition necessary for them to all work together in a OIBTree. Lastly, these references are meant to be comparable during ZODB conflict resolution (the original persistent objects probably won’t be), which, again, is a condition of the implementation using a OIBTree.

A consequence of avoiding these references is that generally persistent objects that are expected to have intids assigned should not be used as keys in an OxBTree or stored in an OOSet. Instead, all such data structures should use the integer variations (e.g., IISet), with the intid as the key.

As a corollary to the previous point, this module must be used with the intid utility from zc.intid.utility, (one implementing zc.intid.interfaces.IIntIds), which does not depend on being able to use objects as keys in a BTree.

Therefore, this module looks for utilities registered for that interface, not the zope.intid.interfaces.IIntIds.

We do, however, keep a few things in common:

1. We do ensure that the object can be adapted to zope.keyreference.interface.IKeyReference

   In the common case of persistent objects, this will ensure that the object is in the database and has a jar and oid, common needs.

2. We do broadcast the events from zope.intid.interfaces, even though

   the zc.intid package will broadcast its own events. There seems to be no reason not to and things like zope.catalog need them.

Configuring

To configure, you need to include subscribers.zcml:

<!-- configure.zcml -->
<!--
If we load zope.intid, we get subscribers for the Object events
that ensure all ILocation objects are registered/unregistered when
they are added/removed, plus another set of events when they
get/lose intids. This second set of events is meant to update
zope.catalog. A consequence of this is that ILocation objects must
be adaptable to KeyReferences when they are ObjectAdded (for
purposes of zope.intid, which we don't care about, but this also
ensures that they have ZODB Connections, which is good).

We cannot use these subscribers as-is due to the way the use IKeyReference
and try to register that. However, our subscribers *do* make sure that
the given objects can be adapted to IKeyReference because that's useful and
may be required by catalogs or other subscribers.
-->
<exclude package="zope.intid" file="subscribers.zcml" />
<include package="zope.intid" />

<include package="zope.keyreference" />

<!--
zc.intid fires a different set of events when objects gain/lose
intids.
-->
<include package="zc.intid" />

<!--
Make zc.intid utilities compatible with zope.intid utilities.
-->
<include package="zc.intid" file="zope-intid.zcml" />

<!-- To hook them up to the Object events, we need to include the file -->
<include package="zc.intid" file="subscribers.zcml" />

zc.intid.subscribers.addIntIdSubscriber(ob, event)

Registers the object in all unique id utilities and fires an event for the catalogs. Notice that each utility will fire zc.intid.interfaces.IIntIdAddedEvent; this subscriber will then fire one single zope.intid.interfaces.IIntIdAddedEvent, followed by one single zc.intid.interfaces.IAfterIdAddedEvent; this gives a guaranteed order such that zope.catalog and other Zope event listeners will have fired.

zc.intid.subscribers.removeIntIdSubscriber(ob, event)

Removes the unique ids registered for the object in all the unique id utilities.

Just before this happens (for the first time), an zc.intid.interfaces.IBeforeIdRemovedEvent is fired, followed by an zope.intid.interfaces.IIntIdRemovedEvent. Notice that this is fired before the id is actually removed from any utility, giving other subscribers time to do their cleanup.

Before each utility removes its registration, it will fire zc.intid.interfaces.IIntIdRemovedEvent. This gives a guaranteed order such that zope.catalog and other Zope event listeners will have fired.

zc.intid.subscribers.intIdEventNotify(event)

Event subscriber to dispatch IntIdEvent to interested adapters.

See subscribers.zcml for its registrations (it handles two types of events).