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:

But Dominik, before my modification, the code was:

    if event:

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


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.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to