[Zope3-dev] Re: Event fixes

[Florent Guillaume]

On 28 Nov 2005, at 22:09, Dominik Huber wrote:
> 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)

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

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

-- 
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com