Florent Guillaume wrote:

On 28 Nov 2005, at 19:30, Dominik Huber wrote:

Florent,
But at least the event notifications within the setitem function is kind of redundant. An add-, move- and remove- event is a part of the container framework. Therefore we can assume that the underlying container referenced by the event.object.__parent__ has changed too.

file: zope.app.container.contained.py:

def setitem(container, setitemf, name, object):
   ...
   if event:
       notify(event)
       notifyContainerModified(container)


If you don't have this container notification, then when you want to know when a given container object is modified you have to listen to all add, remove and move events, and then introspect their oldParent and newParent. Doh.

The object event framework promises you that if there is something happening to an object, you get notified of it directly. That's what I'm doing here, I'm notifying that the container object was modified, because it was.

If you have a problem with that event, then you should have a problem with the whole concept of event dispatching to sublocations, which are also "redundant" but which we want to make explicit nevertheless, for the benefit of subscribers.

Dispatching does not mean redundant event information!

IMO, there are three use cases mixed up:
1. Notification if the *order* of container was changed.
2. Notification if the content of a container was *moved* (add- and move events). 3. Notification if the *content* of a container was changed (Mechansim to inform super (parent) objects)

1. A subtype of IObjectModifiedEvent could make sense, because only the state of the container changed. (Here is our dispute wether we implement such an event as subtype or be the general object modified event and modification descriptors.)

2. A subtype of IObjectModifiedEvent is cluttering because of redundant modification events. The modification is caused by the containment. Regularly the dispatching related to the containment hierarchy tries to emulate an information flow from *parent -> child*, because children should be informed if the location information has been changed. But the other way around you need *never* a notification, because the container is aware of changes related to the container framework! Here an more adequat solution would be an internal container framework event that derives from IObjectEvent but not from IObjectModifiedEvent, because otherwise we would notify the same modification using two redundant modification events.

3. IMO you are introducing something like a dispatchToParentLocations information flow from *child -> parent* similar to the dispatchToSublocations (*parent -> child* ). I like this idea, but I would generalize it: It might be interesting for parents to be informed if the state of a containment has changed.

def dispatchToParentLocations(object, event):
   parents = IParents(object, None)
   if parents is not None:
       for parent in parents :
           for ignored in zapi.subscribers((parent, event), None):
               pass # They do work in the adapter fetch

 <subscriber
     for="zope.app.location.interfaces.ILocation
          zope.app.container.interfaces.IObjectMovedEvent"
     handler=".contained.dispatchToParentLocations"
     >
 </subscriber>

But then we would have the problem, that we could not differ child->parent and parent->child handlers...

Florent, excuse my insistence, but I'm afraid that we mess up the notification mechanism. I think I understand your intention. The only thing I realy defend is the fact that we should not implement different approaches (models of a containment hierarchy) using the same events, because we have no change to differ those point of views within our event handlers. Therefore it is very important that we notify only one event (IObjectModifiedEvent.isOrExtends(event)), because we don't have a chance to check for redundant event informations that affects different logical systems.

I'm realy tired of this hick-hack-thread. IMO the correct way would be a proposal for such a fundamental change.
Amen,

Dominik





begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30
x-mozilla-html:FALSE
version:2.1
end:vcard

_______________________________________________
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