Hi,
On 29 Nov 2005, at 08:27, Dominik Huber wrote:
Florent Guillaume wrote:
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.
Excuse the confusion of my mail. I was to tired yesterday. I try it
another time :)
zope.app.container.contained.py, line 594
def setitem(container, setitemf, name, object):
...
if event:
notify(event)
notifyContainerModified(container)
But Dominik, before my modification, the code was:
if event:
notify(event)
modified(container)
Where `modified` is defined in zope.app.event.objectevent and does:
def modified(object, *descriptions):
notify(ObjectModifiedEvent(object, *descriptions))
So I didn't introduce a redundant event, it's always been there.
This method is called every time when an item is set to a
container. Isn't it?
Therefore additionally to the object moved resp. object added event
newly an container modified event is notified.
The second notification is kind of redundant information to the
framework, because we can get all the information from the first
event. The only problem - and there I'm with you - is that the
subscription for handlers that applies to the container itself is
cumbersome (-> Use case A, for example modification handlers for
containers).
The solution you have choosen to solve use case A brings two
disadvantages to my applications:
1. I'm not able to make batchwise additions to a container and
notify afterward a single modification event of the container
anymore (Anology: Modification event within the form framework are
notified by views (adapters) -> The model itself notifies never an
modification, because those events would be to granular (an event
for each edited attribute)
2. For complex event proceeding of components I sometimes use a
single handler that is registered to different events. This brings
the advantage that you can bundle event-specific code within one
handler (omit redundant and distributed logic -> more
understandable). Now the disadvantage is that those handlers get
invoked twice during the same logical transaction (once by moved
event and right afterward by the modified event). This additional
event is cluttering, because once the container modified event is
notified to handle an additional container state (-> Use case B,
for example ordered containers) and once a only state that is
already covered by the moved event. The container modified event
covers two use cases (A and B), but is not able to model them
semantically.
These are two very valid use cases, and I believe they are answered
by pre-setting __parent__ and __name__ on the object before adding/
moving/removing it -- again, code I didn't introduce. Please read the
docstring for containedEvent() and uncontained().
Florent
Other solution would be...
Use Case A:... to dispatch the moved event using a similar
mechanism like dispatchToSublocations-handler (-
>dispatchToParentHandler) without notifying a second modified event.
Use Cas B: as you proposed or modification descriptors
Mixture Use Case A and B: We could use modification descriptors to
stuff the semantical lack of the container modified event, but
then... ;)
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.
I hope I could lighten the msiunderstanding a little bit.
Regards,
Dominik
<dominik.huber.vcf>
--
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
