On 3 January 2012 08:01, Chris McDonough <chr...@plope.com> wrote:
>> Am I right in thinking Pyramid no longer uses repoze.tm2 or a
>> middleware approach? What was the rationale for that design decision?
> You're right, Pyramid scaffolding no longer supplies repoze.tm2 or any
> other WSGI middleware component for handling transaction commits/aborts.
> Instead, it uses a Pyramid "tween", which is sort of like internal
> Pyramid middleware inasmuch as its a user-manageable functional
> composition terminating at the application. See
> Tweens can be reordeded arbitrarily, and the Pyramid exception handling
> logic (which locates and executes a Pyramid view when an application
> exception is raised) is itself a tween.
> The rationale is that application-specific error logic often needs to be
> executed after the transaction has been committed or aborted due to an
> exception. For example, if an exception is raised by an application,
> you'd like the system to abort the transaction, then potentially display
> a custom internal server error page (e.g. twitter fail-whale). People
> want to be able to write the error logic within their existing Pyramid
> development environment (where they have access to templating systems, a
> real request object, and possibly their database and other niceties)
> instead of as WSGI middleware higher in the stack than the transaction
I mostly agree with this, and for this reason I think the
ZPublisher.Pubevents (not quite as good as tweens, I admit) and
exception views are useful. With a middleware solution, you may find
yourself passing application state in the wsgi environ which seems
> FWIW, I believe Tres still disagrees strongly with this decision.
I can certainly see the use case for distributing transactions across
middleware and/or composite apps, which is why it may make sense for
this to be opt-in.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -