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):
This method is called every time when an item is set to a container.
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
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.
tel;work:++41 56 534 77 30
Zope3-dev mailing list