Hi

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Florent Guillaume
> Sent: Wednesday, November 30, 2005 2:00 AM
> To: zope3-dev@zope.org
> Subject: [Zope3-dev] Re: Contained events interface inheritance order
> 
> I'm surprised no-one has commented on this. Jim, you did the 
> last work 
> on this, could you tell me what you think?
> 
> Florent
> 
> Florent Guillaume wrote:
> > Today the contained events interfaces are:
> >   class IObjectMovedEvent(IObjectEvent)
> >   class IObjectAddedEvent(IObjectMovedEvent)
> >   class IObjectRemovedEvent(IObjectMovedEvent)

I dont' know if this affect the events itself but there is also a 
problem in the ObjectMover.

If you use the ObjectMover from copypastemove on IDependable (registered) 
objects, it's not possible to move a object because of the order the move 
process is implemented.

---
target[new_name] = obj
del container[orig_name]

if the ObjectAdded Event will add a dependency to the object we can't 
delete them in the container.

If this should be fixed, I'm not sure if the ObjectMover should copy
dependable objects, then the order should be:

---
del container[orig_name]
target[new_name] = obj


This means the events order in this usecase looks like:

IObjectRemovedEvent
IObjectAddedEvent
IObjectMovedEvent

Where the IObjectMovedEvent notifies about the sucessful move.
Anyway, add a object to a container where is at the same time in
a second container is a bad idea in my point of view.

What do you think?

Regards
Roger Ineichen

> >  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)
> > 
> > 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
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > Myself I consider the current hierarchy to be a design bug.
> > 
> > Florent
> > 
> 
> 
> -- 
> Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
> +33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
> 

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to