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
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
