On May 16, 2:27Â am, Chris McDonough <chr...@plope.com> wrote:
> I've created a branch named "httpexception-utils" on GitHub which
> contains an implementation of "redirect" and "abort" for Pyramid that
> act like their Pylons brethren.
Here's what I've decided to do with this issue:
- An exception view for the pyramid.interfaces.IExceptionResponse
interface will be registed by default. This exception view will
simply return the response object it receives as an exception.
It will be possible to disuse this default by passing a None value
to a constructor parameter. It will be possible to override the
default by passing a different view callable to the same constructor
parameter.
- All objects that inherit from pyramid.response.Response (inlcuding
instances of the Response class itself) will provide the
IExceptionResponse interface.
- We will disuse the classes from webob.exc because, although they
advertise themselves as Response objects, they really very badly
want to be used as WSGI applications rather than "plain response"
objects. We will create a mirror of the http exception hierarchy
in pyramid.response. It will be backwards compatible with the
current
crop of classes that are in "webob.exc" (aka
"pyramid.httpexceptions").
A backwards compatibility shim for "pyramid.httpexceptions" will be
left
in place.
- "pyramid.response.Response" will now be a *subclass* of
webob.response.Response (rather than an alias) which will
both inherit from Exception (so it can be raised) and will provide
the pyramid.interfaces.IExceptionResponse interface.
- the abort() and redirect() candy will be added. These will simply
raise exceptions.
After the above steps are taken, "raise
pyramid.response.HTTPUnauthorized(...)" from within view code (or
event handler code) will generate a 401 response code with a default
body out-of-the-box. It will mean (probably more controversially)
"raise Response('OK')" will generate a 200 response code with the body
"OK". This change should not cause much (if any) existing code to
break and if it does, the feature which provides this default behavior
can be turned off at Configurator constructor time.
After spending some time investigating alternative solutions, and
attempting to write documentation in a number of ways, allowing all
objects that inherit from Response to be raised seemed to be the most
sensible default as a principal of least surprise.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
