BlueBream

ObjectRemovedEvent is sent *before* the object is removed

Bug #202102 reported by Jan Wijbrand Kolman
2
Affects Status Importance Assigned to Milestone
BlueBream
New
Undecided
Unassigned
Zope 3
Won't Fix
Undecided
Unassigned

Bug Description

The ObjectRemovedEvent is fired when an contained item is removed from its container.

The current container implementations in zope.app.container fire this event *before* actually removing the item. Subscribers to this event will thus find the item still in its container (for example through the oldParent attribute on the event object).

So either the event's name is misleading and should be something like "ObjectAboutToBeRemovedEvent", or the event should be actually fired after the delete.

The latter solution would need a bit of work, since the helper functions (in zope.app.container.contained) that create and fire the event need access to the __parent__ of the item-to-be-deleted. One possibility could be, to have the uncontained function do the actual delete just after having constructed the event.

Revision history for this message
Fred Drake (fdrake) wrote :

I'm sure there's a way to say "Not a bug" or "Won't fix" in Launchpad, but I can't find it in this UI.

This has always been this way; the behavior can't be changed; that would be a backward compatibility failure. I vaguely recall this being discussed when this was first designed, and it was decided this was reasonable *because* subscribers would want to be able to use __parent__.

If you really need both the existing event *and* ObjectHasAlreadyBeenRemoved, present a feature request with a use case. Seems unlikely to be valuable IMO.

Tres Seaver (tseaver)
Changed in zope3:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.