Florent Guillaume wrote:
Today the contained events interfaces are:
  class IObjectMovedEvent(IObjectEvent)
  class IObjectAddedEvent(IObjectMovedEvent)
  class IObjectRemovedEvent(IObjectMovedEvent)

 From the archives I can find this was decided after:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ SimplifyObjectLifecycleAndLocationEvents but without motivation for this part. I'm still looking for the motivation...

Before that proposal, the hierarchy was:
  class IObjectAddedEvent(IObjectEvent)
  class IObjectRemovedEvent(IObjectEvent)
  class IObjectMovedEvent(IObjectAddedEvent, IObjectRemovedEvent)

Note that before the refactoring, separate add and remove events were
published on a move.  This is the most important aspect of the change.

You often want to handle just add events or just removed events.
For example, you only want to generate an integer id on an add event
and you only want to remove it on a remove event.  "Added" means that
something that didn't have a location now has one. Similarly,
"removed" means that something no-longer has a location.  This meaning
isn't captured by the old hierarchy.  It's a shame this wasn't captured
in the proposal.

I contend that this second hierarchy is much more useful to deal with. The arguments I have are in the use cases explained in: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/ 2005_11_08_events-in-zope-2-9

(Is there some reason for the urls you give to have spaces in them?
It makes them harder to follow. It appears that this is a mac thing.
It's rather annoying.)

where you can see the hoops one has to go through to react to objects being created, deleted or moved with the current event hierarchy.

You mean "added", "removed", or "moved".

In your third use case, I'll note that you can compute the old path
using information in the event.   This is why Zope 3 doesn't
need the before event.  My understanding was that the before
event was added to more closely match the semantics of

I'd like to know what non-framework use cases people have today with the current event interfaces hierarchy, and if they really find it more useful than the old one.

The concepts of "added" and "removed", as described above, are valuable IMO.

If not, or if the use cases are borderline, I'd like to propose that the hierarchy be moved back to the second form. This would have to go through a deprecation phase, I'm not sure exactly how, but if there's consensus we can find a way.

I suggest:

- Rename IObjectMovedEvent to IObjectLocationEvent.  The old name
  would be retained as an alias and deprecated.

- Create a new event, IObjectRelocatedEvent that extends
  IObjectLocationEvent and is generated whan an object is moved,
  but not added or removed.  Possibly, down the road, "relocated" could be
  renamed to "moved".

  In your first use case, you'd register the subscriber for both added
  and relocated.  In your second, for just relocated.  You could so something
  similar for your before events.

- If necessary, intermediate event types could be defined to avoid
  the duplicate registrations.

Of course, this would be for the June release.   It will also cause spurious
test failures.  We really need to have better ways to make assertions about
event histories.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to