On 28 Nov 2005, at 22:09, Dominik Huber wrote:
Florent Guillaume wrote:

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

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:

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)

Yes there are certainly several problems intertwinned.

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.)

Yes that's where I thought our dispute was all along. I appreciate your point of view here, even though I don't agree with it. We'd want external opinions. Jim appeared to say that the subtype-based approach had merit, and that the description-based approach had merit too but wasn't "adequately worked out".

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.

Here you lost me. I changed the type of event sent to a subclass of what it was before. Before, it was IObjectModifiedEvent. So all you're saying applies to code that's been there *forever*. Yes, there are multiple events dispatched for a single "operation". It's always been like that.

Please reread my checkin:
http://svn.zope.org/Zope3/trunk/src/zope/app/container/contained.py? rev=40368&r1=39759&r2=40368

There was already code before that sent an event about the container. That I didn't add.

3. IMO you are introducing something like a dispatchToParentLocations information flow from *child -> parent*

I didn't introduce any fundamental concept, I only specialized an event.

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


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.

Excuse my insistence, but the only thing I *added* was a modification event when you reorder the children of an ordered container. Before attacking it, please undestand what I checked in.

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.

I'm always for a good dicussion thread when things have to be explained.

But here I think there's a big misunderstanding.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

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

Reply via email to