I am not in line with your principle "the error report is
part of [the output of] the first transaction".
The error report tells you what went wrong. You can only generate an accurate report if you see the objects in the error state. Zope is saying to your application: "your transaction is doomed. tell me why."
I'm interested in this for Zope 3.
Currently in Zope 3, you can register a view to give a custom presentation of an error that reaches the publisher. The view can also do persistent work if it needs to. An example of this is recording against a User record that a login failed for that User.
The view has access to the original request that ended in the error. The view is looked-up and rendered in a new transaction. The new transaction is committed if there were no errors raised, otherwise it is aborted.
Do you think this error handling system is insufficient for your needs?
Can you give an example of the kind of situation where you'd need access to objects in a doomed transaction in their doomed state, in order to make an error report?
I'm interested in improving the error handling system in Zope 3, so your use-case will be very useful.
-- Steve Alexander
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
