[Zope3-dev] Re: Event fixes

[Dominik Huber]

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)

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.


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dominik.huber.vcf
Type: text/x-vcard
Size: 154 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20051129/0d54d5dc/dominik.huber.vcf