[Zope3-dev] Re: Event fixes

[Florent Guillaume]

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   fg at nuxeo.com