[Zope3-dev] ObjectHub notes: removing objects

[Gary Poster]

On Sun, 2002-10-20 at 08:56, Steve Alexander wrote:

> > Is there a practical difference to the *consumers* of these events,
> > despite the fact that we see one from the outside?  Don't an object
> > removal and a workflow-related unregister call both require the same
> > exact processing from all ObjectHub clients?
> 
> They are different when you want to delete a Container, an have the 
> objecthub receive a single ObjectDeleted event, have the objecthub send 
> on a single HubIdObjectDeleted event, and then have a subscriber to that 
> event determine transitively the registered objects that are contents of 
> the deleted container, and inform the objecthub and its subscribers of 
> the deletion of the objects.

I don't think that's a good use case--I'll get into why below--but
actually I did think of another ok reason as to why we might need a
distinct ObjectRemovedHubEvent: if the object is removed, we need the
HubEvent's "getObject" method to function differently.

 * For normal hub events, we can perform getObject either with a
traverse of the location or an ObjectHub.getObject(hubid).

 * For unregistered events we can traverse the location.

 * For Removed hub events we need to get the removed object from the
Removed object event.

We could get around this, but the distinction seems reasonably logical
and practical, and I need to move check things in.  I say, at least as
far as my checkin is concerned, we keep the removed hub event.

As to why I don't like the use case: even with the
ObjectRemovedHubEvent, I don't think we would use it for this.  The
subscribing of an object in the object hub currently does not require
the subscribing of all parent folders, nor do I think it should. 
However, we do need a robust solution to parent deletion. 

While there are certainly other solutions (like *initially*
mass-producing boatloads of child object deletion events when a parent
is deleted...ugh), this is a case in which we will probably need some
sort of subscriber (or arguably even the ObjectHub--this could be
described as an implication of its contract) that keeps track of the
names of the parent folders of subscribed objects, and listens for
*normal* ObjectRemoved events (not ObjectRemoved hub events) to
determine if any grand cascade of object removal events in the hub needs
to occur (didn't we talk about event packages at one point?  I guess I
won't worry until we start banging on it, and then we can refactor
mercilessly...).  In any case, the crux is that I think we would be
using the ObjectRemovedEvent rather than the ObjectRemovedHubEvent for
this purpose.

Gary