| Age | Commit message (Collapse) | Author |
|---|
|
used to wrap the found view callable before it is called by Pyramid's
router. This is a feature usually only used by framework extensions, to
provide, for example, view timing support.
A view wrapper factory must be a callable which accepts three arguments:
``view_callable``, ``request``, and ``exc``. It must return a view
callable. The view callable returned by the factory must implement the
``context, request`` view callable calling convention. For example::
import time
def wrapper_factory(view_callable, request, exc):
def wrapper(context, request):
start = time.time()
result = view_callable(context, request)
end = time.time()
request.view_timing = end - start
return result
return wrapper
The ``view_callable`` argument to the factory will be the view callable
found by Pyramid via view lookup. The ``request`` argument to the factory
will be the current request. The ``exc`` argument to the factory will be
an Exception object if the found view is an exception view; it will be
``None`` otherwise.
View wrappers only last for the duration of a single request. You can add
such a factory for every request by using the
``pyramid.events.NewRequest`` subscriber::
from pyramid.events import subscriber, NewRequest
@subscriber(NewRequest)
def newrequest(event):
event.request.add_view_wrapper(wrapper_factory)
If more than one view wrapper is registered during a single request,
a 'later' view wrapper factory will be called with the result of its
directly former view wrapper factory as its ``view_callable``
argument; this chain will be returned to Pyramid as a single view
callable.
|
|
|
|
``application/json``, this attribute will contain the JSON-decoded
variant of the request body. If the request's ``content_type`` is not
``application/json``, this attribute will be ``None``.
|
|
abstraction.
- It is now possible to return an arbitrary object from a Pyramid view
callable even if a renderer is not used, as long as a suitable adapter to
``pyramid.interfaces.IResponse`` is registered for the type of the returned
object. See the section in the Hooks chapter of the documentation entitled
"Changing How Pyramid Treats View Responses".
- The Pyramid router now, by default, expects response objects returned from
view callables to implement the ``pyramid.interfaces.IResponse`` interface.
Unlike the Pyramid 1.0 version of this interface, objects which implement
IResponse now must define a ``__call__`` method that accepts ``environ``
and ``start_response``, and which returns an ``app_iter`` iterable, among
other things. Previously, it was possible to return any object which had
the three WebOb ``app_iter``, ``headerlist``, and ``status`` attributes as
a response, so this is a backwards incompatibility. It is possible to get
backwards compatibility back by registering an adapter to IResponse from
the type of object you're now returning from view callables. See the
section in the Hooks chapter of the documentation entitled "Changing How
Pyramid Treats View Responses".
- The ``pyramid.interfaces.IResponse`` interface is now much more extensive.
Previously it defined only ``app_iter``, ``status`` and ``headerlist``; now
it is basically intended to directly mirror the ``webob.Response`` API,
which has many methods and attributes.
- Documentation changes to support above.
|
|
interface API documentation.
|
|
|
|
|
|
|
|
``request.response_content_type = 'foo'``. Assignments and mutations of
the following request attributes that were considered by the framework for
response influence are now deprecated: ``response_content_type``,
``response_headerlist``, ``response_status``, ``response_charset``, and
``response_cache_for``. Instead of assigning these to the request object
for detection by the rendering machinery, users should use the appropriate
API of the Response object created by accessing ``request.response``
(e.g. ``request.response_content_type = 'abc'`` ->
``request.response.content_type = 'abc'``).
- Custom request objects are now required to have a ``response`` attribute
(or reified property) if they are meant to be used with renderers. This
``response`` attribute should be an instance of the class
``pyramid.response.Response``.
- The JSON and string renderer factories now use
``request.response.content_type`` rather than
``request.response_content_type``. They determine whether they should set
the content type of the response by comparing the response's content type
against the default (usually ``text/html``); if the content type is not the
default, the renderer changes the content type (to ``application/json`` or
``text/plain`` for JSON and string renderers respectively).
- Made it possible to assign to and delete
``pyramid.testing.DummyRequest.registry`` (bugfix).
|
|
|
|
``route_path``, ``route_url``, and ``static_url`` methods to
``pyramid.request.Request`` API docs.
|
|
|
|
``route_url``. These are simple passthroughs for their respective
functions in ``pyramid.url``.
- Documented the ``matchdict`` and ``matched_route`` attributes of the
request object in the Request API documentation.
|
|
to :app:`Pyramid`. A custom role setting was added to ``docs/conf.py`` to
allow for this. (internal)
|
|
|
|
|
|
|
|
--------
- Compatibility with WebOb 1.0.
Requirements
------------
- Now requires WebOb >= 1.0.
Backwards Incompatibilities
---------------------------
- Due to changes introduced WebOb 1.0, the
``repoze.bfg.request.make_request_ascii`` event subscriber no longer
works, so it has been removed. This subscriber was meant to be used
in a deployment so that code written before BFG 0.7.0 could run
unchanged. At this point, such code will need to be rewritten to
expect Unicode from ``request.GET``, ``request.POST`` and
``request.params`` or it will need to be changed to use
``request.str_POST``, ``request.str_GET`` and/or
``request.str_params`` instead of the non-``str`` versions of same,
as the non-``str`` versions of the same APIs always now perform
decoding to Unicode.
|
|
--------
- A ``request.matched_route`` attribute is now added to the request
when a route has matched. Its value is the "route" object that
matched (see the ``IRoute`` interface within
``repoze.bfg.interfaces`` API documentation for the API of a route
object).
- The ``exception`` attribute of the request is now set slightly
earlier and in a slightly different set of scenarios, for benefit of
"finished callbacks" and "response callbacks". In previous
versions, the ``exception`` attribute of the request was not set at
all if an exception view was not found. In this version, the
``request.exception`` attribute is set immediately when an exception
is caught by the router, even if an exception view could not be
found.
Backwards Incompatibilities
---------------------------
- The router no longer sets the value ``wsgiorg.routing_args`` into
the environ when a route matches. The value used to be something
like ``((), matchdict)``. This functionality was only ever
obliquely referred to in change logs; it was never documented as an
API.
- The ``exception`` attribute of the request now defaults to ``None``.
In prior versions, the ``request.exception`` attribute did not exist
if an exception was not raised by user code during request
processing; it only began existence once an exception view was
found.
Deprecations
------------
- References to the WSGI environment values ``bfg.routes.matchdict``
and ``bfg.routes.route`` were removed from documentation. These
will stick around internally for several more releases, but it is
``request.matchdict`` and ``request.matched_route`` are now the
"official" way to obtain the matchdict and the route object which
resulted in the match.
Documentation
-------------
- Added two sections to the "Hooks" chapter of the documentation:
"Using Response Callbacks" and "Using Finished Callbacks".
- Added documentation of the ``request.exception`` attribute to the
``repoze.bfg.request.Request`` API documentation.
- Added glossary entries for "response callback" and "finished
callback".
- The "Request Processing" narrative chapter has been updated to note
finished and response callback steps.
|
|
-------------
- Add an API chapter for the ``repoze.bfg.request`` module, which
includes documentation for the ``repoze.bfg.request.Request`` class
(the "request object").
- Modify the "Request and Response" narrative chapter to reference the
new ``repoze.bfg.request`` API chapter. Some content was moved from
this chapter into the API documentation itself.
Features
--------
- A new ``repoze.bfg.request.Request.add_response_callback`` API has
been added. This method is documented in the new
``repoze.bfg.request`` API chapter. It can be used to influence
response values before a concrete response object has been created.
Internal
--------
- The (internal) feature which made it possible to attach a
``global_response_headers`` attribute to the request (which was
assumed to contain a sequence of header key/value pairs which would
later be added to the response by the router), has been removed.
The functionality of
``repoze.bfg.request.Request.add_response_callback`` takes its
place.
|
|
|
|
should be used (**very sparingly**) to retrieve the "current"
request. See the ``repoze.bfg.request`` API documentation for more
information.
|
