| Age | Commit message (Collapse) | Author |
|---|
|
``current_route_url`` functions in the ``pyramid.url`` package now delegate
to a method on the request they've been passed, instead of the other way
around. The pyramid.request.Request object now inherits from a mixin named
pyramid.url.URLMethodsMixin to make this possible, and all url/path
generation logic is embedded in this mixin.
- Narrative and API documentation which used the ``route_url``,
``route_path``, ``resource_url``, ``static_url``, and ``current_route_url``
functions in the ``pyramid.url`` package have now been changed to use
eponymous methods of the request instead.
|
|
|
|
globally importable name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and the ``renderer_globals`` Configurator constructor parameter.
|
|
webob.exc.WSGIHTTPException (convenience).
- Use ``exc.message`` in docs rather than ``exc.args[0]`` now that
we control this.
|
|
|
|
|
|
- Fix Configurator docstring wrt exception responses.
- Speed up registry.queryAdapterOrSelf
|
|
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.
|
|
method which implements the WSGI application interface
instead of the three webob attrs status, headerlist
and app_iter. Backwards compatibility exists for
code which returns response objects that do not
have a __call__.
- pyramid.response.Response is no longer an exception
(and therefore cannot be raised in order to generate
a response).
- Changed my mind about moving stuff from pyramid.httpexceptions
to pyramid.response. The stuff I moved over has been moved
back to pyramid.httpexceptions.
|
|
|
|
``start_response`` callable and obtains the WSGI ``app_iter`` based on
adapting the response object to the new ``pyramid.interfaces.IResponder``
interface. The default ``IResponder`` uses Pyramid 1.0's logic to do this.
To override the responder::
from pyramid.interfaces import IResponder
from pyramid.response import Response
from myapp import MyResponder
config.registry.registerAdapter(MyResponder, (Response,),
IResponder, name='')
This makes it possible to reuse response object implementations which have,
for example, their own ``__call__`` expected to be used as a WSGI
application (like ``pyramid.response.Response``), e.g.:
class MyResponder(object):
def __init__(self, response):
""" Obtain a reference to the response """
self.response = response
def __call__(self, request, start_response):
""" Call start_response and return an app_iter """
app_iter = self.response(request.environ, start_response)
return app_iter
|
|
pyramid.response
|
|
``pyramid.config.Configurator.set_view_mapper`` and refer to it within
Hooks chapter section named "Using a View Mapper".
|
|
Conflicts:
docs/narr/hooks.rst
|
|
|
|
|
|
now ``403 Forbidden``. It was previously ``401 Unauthorized``, for
backwards compatibility purposes with ``repoze.bfg``. This change will
cause problems for users of Pyramid with ``repoze.who``, which intercepts
``401 Unauthorized`` by default, but allows ``403 Forbidden`` to pass
through. Those deployments will need to configure ``repoze.who`` to also
react to ``403 Forbidden``.
|
|
|
|
|
|
|
|
redirected to ``pyramid_zcml`` locations.
|
|
templates were removed. Use ``pyramid_sqla`` (available from PyPI) as a
generic replacement for Pylons-esque development.
- All references to ``add_handler`` and the ``handler`` ZCML directive have
been removed from the docs, and stubs which point to ``pylons_handlers``
package have replaced them.
|
|
|
|
- Document ``__view_mapper__`` attribute and ``mapper`` argument to view
configuration for view callable view mapper preference.
|
|
example
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
