[Zope3-dev] Re: IEndRequestEvent question

[Philipp von Weitershausen]

Florent Guillaume wrote:
> But the base one should really send an event there.
> How about adding a IAfterCall publication event?

How about making the publication more event-y and less subclass-y in the
first place? I think instead of calling various methods on the
publication when we want things to happen, I think we should just send
out events and let individual subscribers do things (start or end
transactions, interactions, etc.).

In particular, I would replace:

* beforeTraversal and callTraversal with (the already existing, but in
the wrong place) IBeforeTraverseEvent

* afterTraversal with an IAfterTraverseEvent

* afterCall with an IAfterCallEvent (this is the one Thierry wants)

* endRequest with (the already existing) IEndRequestEvent

Of course, most of these are object events. They should be defined in
zope.publisher.interfaces and be thrown by the publisher
(zope.publisher.publish) where it currently calls the various
publication methods. (It would continue to call these for BBB reasons,
of course, but we should deprecate them).

I think Steve had some ideas in the same direction during the PyCON
sprints, but I think he ended up doing somethign else...

Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

[Zope3-dev] Re: IEndRequestEvent question

[Florent Guillaume]

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
available...

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

--
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com