Hi, In Zope 2.12 ZPublisher we have a good set of events now, which provide useful hooks for modifying the response before or after publication. However, I'd like to add one more. ;-) Basically, we have IPubFailure, but this is sent *after* transaction.abort() and endInteraction(). This means that it's impossible to read from the ZODB when trying to deal with a failure. I'd like to add an event before that, IPubBeforeAbort, which mirrors IPubBeforeCommit in being sent before the transaction is aborted. I can do this on Zope trunk + 2.12 branch if no-one objects. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Wouldn't it be better to just move IPubFailure before the abort? Is there a reason for subscribing to such an event which would required the transaction to be aborted already? I can see the usefulness of the transaction being already doom()ed before this event, but not aborted. On Wed, Nov 11, 2009 at 08:53, Martin Aspeli <optilude+lists@gmail.com> wrote:
Hi,
In Zope 2.12 ZPublisher we have a good set of events now, which provide useful hooks for modifying the response before or after publication. However, I'd like to add one more. ;-)
Basically, we have IPubFailure, but this is sent *after* transaction.abort() and endInteraction(). This means that it's impossible to read from the ZODB when trying to deal with a failure.
I'd like to add an event before that, IPubBeforeAbort, which mirrors IPubBeforeCommit in being sent before the transaction is aborted.
I can do this on Zope trunk + 2.12 branch if no-one objects.
Martin
-- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Leonardo Rochael Almeida wrote:
Wouldn't it be better to just move IPubFailure before the abort? Is there a reason for subscribing to such an event which would required the transaction to be aborted already? I can see the usefulness of the transaction being already doom()ed before this event, but not aborted.
There is an IPubSuccess which runs after the transaction is closed. Doing post-processing after closure may be useful to keep transactions shorter and thus reduce the risk of conflict errors. I don't think an extra event will cost us much, so being consistent and granular is probably best. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Thu, Nov 12, 2009 at 12:29, Martin Aspeli <optilude+lists@gmail.com> wrote:
Leonardo Rochael Almeida wrote:
Wouldn't it be better to just move IPubFailure before the abort? [...] I can see the usefulness of the transaction being already doom()ed before this event, but not aborted.
There is an IPubSuccess which runs after the transaction is closed. Doing post-processing after closure may be useful to keep transactions shorter and thus reduce the risk of conflict errors. I don't think an extra event will cost us much, so being consistent and granular is probably best.
Fair enough. I still suggest doom()ing the transaction before this event.
participants (2)
-
Leonardo Rochael Almeida -
Martin Aspeli