> My goal is to use request annotations to reference several objects that > should be treated after the main request process is done, and then to > subscribe to this event to fire these final modifications (so that, for > example, "IObjectModifiedEvent" is not fired too many times). Is it the > good approach ? Why are you concerned about IObjectModifiedEvent being fired too many times?
Thanks for your previous explanations : it's clear in my mind, now !
My first idea with this problem was to say : a content object can be modified several times during a request execution, sometimes by other content objects and not only by simple editing forms (which automatically fire IObjectModifiedEvent), and I want some kind of expensive application logic (for example, reindexing) to be applied only once, when all modifications are done.
So the IEndRequestEvent was, to me, a good place to handle this kind of methods ; but your previous explanation show that I was wrong.
I also thought about using some kind of request annotations or volatile attributes, but as event handlers are fired synchronously, I thing that I can't know if there are more modifications to come before the end of the request or not.
In fact, I thing that what I should need is a kind of "IBeforeEndRequestEvent", an event which would be fired before the end of the request, but when transactions and local utilities are still available...
Of course, any kind of complement would as always be very welcome...
Thanks,
Thierry
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
