| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.httpexceptions.redirect``.
- Added "HTTP Exceptions" section to Views narrative chapter including a
description of ``pyramid.httpexceptions.abort``; adjusted redirect section
to note ``pyramid.httpexceptions.redirect``.
- A default exception view for the context ``webob.exc.HTTPException`` (aka
``pyramid.httpexceptions.HTTPException``) is now registered by default.
This means that an instance of any exception class imported from
``pyramid.httpexceptions`` (such as ``HTTPFound``) can now be raised from
within view code; when raised, this exception view will render the
exception to a response.
- New functions named ``pyramid.httpexceptions.abort`` and
``pyramid.httpexceptions.redirect`` perform the equivalent of their Pylons
brethren when an HTTP exception handler is registered. These functions
take advantage of the newly registered exception view for
``webob.exc.HTTPException``.
- The Configurator now accepts an additional keyword argument named
``httpexception_view``. By default, this argument is populated with a
default exception view function that will be used when an HTTP exception is
raised. When ``None`` is passed for this value, an exception view for HTTP
exceptions will not be registered. Passing ``None`` returns the behavior
of raising an HTTP exception to that of Pyramid 1.0 (the exception will
propagate to middleware and to the WSGI server).
|
|
|
|
|
|
interface API documentation.
|
|
|
|
'Paster templates' will now be refered to as 'scaffolds,' while
'rendered templates' will remain as 'templates.' I have changed
the docs to reflect this change in terminology.
|
|
|
|
tutorials out of core documentation and into the Pyramid Tutorials site
(http://docs.pylonsproject.org/projects/pyramid_tutorials/dev/).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
redirected to ``pyramid_zcml`` locations.
|
|
|
|
|
|
on the "current" route (if any) and its matchdict values.
|
|
view config
|
|
|
|
|
|
a named implementation of a ``pyramid.interfaces.IViewMapperFactory``
interface. Its name can be passed as a ``view_mapper`` argument to
``config.add_view``. A view mapper allows objects that are meant to be
used as view callables to have an arbitrary argument list and an arbitrary
result. This feature will be used by Pyramid extension developers, not by
"civilians".
- New constructor argument to Configurator: ``default_view_mapper``. Useful
to create systems that have view callables with alternate default calling
conventions.
- ``view_mapper`` argument to ``add_view`` should now be a view mapper *name*
rather than an implementation.
- Add ``view_mapper`` argument to ``view_config`` decorator constructor.
- Remove (non-API) function of config.py named _map_view.
- Fix docstring for ``decorator`` argument to add_view.
- Factor invocation of view mapper into a viewderiver method.
- Promote view rendering and decorating into viewderiver, out of view mapper.
- Make requestonly into a function rather than a method of the default view
mapper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to :app:`Pyramid`. A custom role setting was added to ``docs/conf.py`` to
allow for this. (internal)
|
|
|
|
|