[Zope3-Users] 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-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Re: [Zope3-Users] Re: IEndRequestEvent question

[Thierry FLORAC]

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

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