On Tue, 2012-01-03 at 07:32 +0000, Martin Aspeli wrote: > On 3 January 2012 06:39, Chris McDonough <chr...@plope.com> wrote: > > On Mon, 2012-01-02 at 10:39 +0000, Martin Aspeli wrote: > >> On 2 January 2012 08:50, Wichert Akkerman <wich...@wiggy.net> wrote: > >> > On 01/01/2012 08:39 PM, Martin Aspeli wrote: > >> >> > >> >> Hi, > >> >> > >> >> There are three known WSGI implementations of the Zope 2 publisher. > >> >> I've had a look at them and made some notes about what I think > >> >> provides the best story: > >> >> > >> >> ## Zope 2.13 WSGIPublisher > >> >> > >> >> Pros: > >> >> > >> >> * Allows distributed transaction management with repoze.tm2 > >> >> * Allows distributed retry with repoze.retry > >> >> * Ships with Zope > >> >> * Quite simple > >> >> > >> >> Cons: > >> >> > >> >> * Requires repoze.tm2 and repoze.rety > >> > > >> > > >> > Why is that a con? I use repoze.tm2 and repoze.retry with all my pyramid > >> > projects and they work beautifully. > >> > >> Only insofar as it means you have to have these in your WSGI pipeline > >> or it won't work, so there are more places things can go wrong. > >> > >> You'll note that I also consider not supporting such things a con for > >> infrae.wsgi. I wouldn't get too hung up on it, I was mainly just > >> trying to bring out the differences. It'd be nice if it wasn't a hard > >> requirement, though. > > > > FWIW, when I wrote repoze.tm2 I did not know that the transaction module > > already supported retry, so at least repoze.rety should die in favor of > > logic in something-like-repoze.tm2 that looks a little more like this: > > > > https://github.com/Pylons/pyramid_tm/blob/master/pyramid_tm/__init__.py#L49 > > > > (that's obviously not WSGI middleware, I'm just showing what the general > > logic should look like) > > 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. The pyramid debug toolbar (the thing that shows the pretty debug pages described at http://docs.pylonsproject.org/projects/pyramid_debugtoolbar/en/latest/) is also a tween, which means it has access to the Pyramid environment that WSGI middleware could not (such as access to the registry, allowing us to display view-configuration information, information about routes, etc). For us, this replaced our use of WebError, much as our use of pyramid_tm replaced our use of repoze.tm2, for mostly the same reasons. FWIW, I believe Tres still disagrees strongly with this decision. - C _______________________________________________ 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 )
