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