[Zope3-dev] Re: Event fixes

[Dominik Huber]

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: dominik.huber.vcf
Type: text/x-vcard
Size: 154 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20051128/d0db92e0/dominik.huber.vcf