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
manageBeforeDelete.
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
--
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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
