On 3 January 2012 08:01, Chris McDonough <chrism@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