[Zope-dev] Zope 2 WSGI investigation

[Martin Aspeli]

On 3 January 2012 08:01, Chris McDonough <chrism at 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
> http://www.slideshare.net/aconrad/alex-conrad-pyramid-tweens-ploneconf-2011
>
> 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
> manager.

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


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

Martin