Thierry FLORAC wrote:
On Tue, 2006-06-06 at 13:32 +0200, Philipp von Weitershausen wrote:
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
Of course, any kind of complement would as always be very welcome...
You could use another publication object that subclasses the afterCall()
method (the original one is in zope.app.publication.zopepublication, and is
where the transaction is committed).
But the base one should really send an event there.
How about adding a IAfterCall publication event?
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
Zope3-users mailing list