| Age | Commit message (Collapse) | Author |
|---|
|
``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``.
|
|
parameter.
When you supply an ``http_cache`` value to a view configuration, the
``Expires`` and ``Cache-Control`` headers of a response generated by the
associated view callable are modified. The value for ``http_cache`` may be
one of the following:
- A nonzero integer. If it's a nonzero integer, it's treated as a number
of seconds. This number of seconds will be used to compute the
``Expires`` header and the ``Cache-Control: max-age`` parameter of
responses to requests which call this view. For example:
``http_cache=3600`` instructs the requesting browser to 'cache this
response for an hour, please'.
- A ``datetime.timedelta`` instance. If it's a ``datetime.timedelta``
instance, it will be converted into a number of seconds, and that number
of seconds will be used to compute the ``Expires`` header and the
``Cache-Control: max-age`` parameter of responses to requests which call
this view. For example: ``http_cache=datetime.timedelta(days=1)``
instructs the requesting browser to 'cache this response for a day,
please'.
- Zero (``0``). If the value is zero, the ``Cache-Control`` and
``Expires`` headers present in all responses from this view will be
composed such that client browser cache (and any intermediate caches) are
instructed to never cache the response.
- A two-tuple. If it's a two tuple (e.g. ``http_cache=(1,
{'public':True})``), the first value in the tuple may be a nonzero
integer or a ``datetime.timedelta`` instance; in either case this value
will be used as the number of seconds to cache the response. The second
value in the tuple must be a dictionary. The values present in the
dictionary will be used as input to the ``Cache-Control`` response
header. For example: ``http_cache=(3600, {'public':True})`` means 'cache
for an hour, and add ``public`` to the Cache-Control header of the
response'. All keys and values supported by the
``webob.cachecontrol.CacheControl`` interface may be added to the
dictionary. Supplying ``{'public':True}`` is equivalent to calling
``response.cache_control.public = True``.
Providing a non-tuple value as ``http_cache`` is equivalent to calling
``response.cache_expires(value)`` within your view's body.
Providing a two-tuple value as ``http_cache`` is equivalent to calling
``response.cache_expires(value[0], **value[1])`` within your view's body.
If you wish to avoid influencing, the ``Expires`` header, and instead wish
to only influence ``Cache-Control`` headers, pass a tuple as ``http_cache``
with the first element of ``None``, e.g.: ``(None, {'public':True})``.
|
|
|
|
|
|
|
|
documentation when passed more than one interface object to its
constructor. For example, when the following listener was registered::
@subscriber(IFoo, IBar)
def expects_ifoo_events_and_ibar_events(event):
print event
The Events chapter docs claimed that the listener would be registered and
listening for both ``IFoo`` and ``IBar`` events. Instead, it registered an
"object event" subscriber which would only be called if an IObjectEvent was
emitted where the object interface was ``IFoo`` and the event interface was
``IBar``.
The behavior now matches the documentation. If you were relying on the
buggy behavior of the 1.0 ``subscriber`` directive in order to register an
object event subscriber, you must now pass a sequence to indicate you'd
like to register a subscriber for an object event. e.g.:
@subscriber([IFoo, IBar])
def expects_object_event(object, event):
print object, event
|
|
|
|
to depend on WebTest, and 2 tests failed as the result of changes to
Pyramid itself. These issues have been fixed.
|
|
and the ``renderer_globals`` Configurator constructor parameter.
|
|
|
|
attributes deprecated for ``pyramid.request.Request`` are accessed (like
``response_content_type``). This is for the benefit of folks running unit
tests which use DummyRequest instead of a "real" request, so they know
things are deprecated without necessarily needing a functional test suite.
|
|
|
|
preprocessor to be specified as a Python callable or Python dotted name.
See https://github.com/Pylons/pyramid/pull/183 for rationale.
Closes #183.
|
|
(e.g. ``response_content_type``) now issues a deprecation warning at access
time rather than at rendering time.
|
|
|
|
|
|
|
|
|
|
``config.add_translation_dirs``, the directories were inserted into the
beginning of the directory list in the wrong order: they were inserted in
the reverse of the order they were provided in the ``*specs`` list (items
later in the list trumped ones earlier in the list). This is now fixed.
Note however, that later calls to ``config.add_translation_dirs`` continue
to insert directories into the beginning of the list of translation
directories created by earlier calls. This means that the same translation
found in a directory added via ``add_translation_dirs`` later in the
configuration process will be found before one added earlier via a separate
call to ``add_translation_dirs`` in the configuration process.
|
|
|
|
|
|
``environ['repoze.bfg.message']`` when it caught a view-related exception
for backwards compatibility with :mod:`repoze.bfg` during error handling.
It did this by using code that looked like so::
# "why" is an exception object
try:
msg = why[0]
except:
msg = ''
environ['repoze.bfg.message'] = msg
Use of the value ``environ['repoze.bfg.message']`` was docs-deprecated in
Pyramid 1.0. Our standing policy is to not remove features after a
deprecation for two full major releases, so this code was originally slated
to be removed in Pyramid 1.2. However, computing the
``repoze.bfg.message`` value was the source of at least one bug found in
the wild (https://github.com/Pylons/pyramid/issues/199), and there isn't a
foolproof way to both preserve backwards compatibility and to fix the bug.
Therefore, the code which sets the value has been removed in this release.
Code in exception views which relies on this value's presence in the
environment should now use the ``exception`` attribute of the request
(e.g. ``request.exception[0]``) to retrieve the message instead of relying
on ``request.environ['repoze.bfg.message']``.
Closes #199.
|
|
|
|
|
|
|
|
|
|
- The ``pyramid.httpexceptions`` classes named ``HTTPFound``,
``HTTPMultipleChoices``, ``HTTPMovedPermanently``, ``HTTPSeeOther``,
``HTTPUseProxy``, and ``HTTPTemporaryRedirect`` now accept ``location`` as
their first positional argument rather than ``detail``. This means that
you can do, e.g. ``return pyramid.httpexceptions.HTTPFound('http://foo')``
rather than ``return
pyramid.httpexceptions.HTTPFound(location='http//foo')`` (the latter will
of course continue to work).
|
|
|
|
|
|
|
|
exception responses.
- Add note about why we've created a shadow exception hierarchy
parallel to that of webob.exc.
|
|
should be used instead of the ``pyramid.view.is_response`` function, which
has been deprecated.
- Deprecated ``pyramid.view.is_response`` function in favor of (newly-added)
``pyramid.request.Request.is_response`` method. Determining if an object
is truly a valid response object now requires access to the registry, which
is only easily available as a request attribute. The
``pyramid.view.is_response`` function will still work until it is removed,
but now may return an incorrect answer under some (very uncommon)
circumstances.
|
|
- 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
|
|
- The ``pyramid.request.Request`` class now has a ``ResponseClass`` interface
which points at ``pyramid.response.Response``.
- The ``pyramid.request.Response`` class now has a ``RequestClass`` interface
which points at ``pyramid.response.Request``.
- ``pyramid.response.Response`` is now a *subclass* of
``webob.response.Response``. It also inherits from the built-in Python
``Exception`` class and implements the
``pyramid.interfaces.IExceptionResponse`` class so it can be raised as an
exception from view code.
|
|
|
|
|
|
``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).
|
|
|
|
argument. If this argument is ``True``, the added route will never be
considered for matching when a request is handled. Instead, it will only
be useful for URL generation via ``route_url`` and ``route_path``. See the
section entitled "Static Routes" in the URL Dispatch narrative chapter for
more information.
|
|
interface API documentation.
|
|
|
|
"traverser" (e.g. an object that implements
``pyramid.interfaces.ITraverser`` such as an instance of
``pyramid.traversal.ResourceTreeTraverser``) as its ``request`` argument
now causes a deprecation warning to be emitted. Consumer code should pass a
``request`` object instead. The fact that passing an environ dict is
permitted has been documentation-deprecated since ``repoze.bfg`` 1.1, and
this capability will be removed entirely in a future version.
- The following (undocumented, dictionary-like) methods of the
``pyramid.request.Request`` object have been deprecated: ``__contains__``,
``__delitem__``, ``__getitem__``, ``__iter__``, ``__setitem__``, ``get``,
``has_key``, ``items``, ``iteritems``, ``itervalues``, ``keys``, ``pop``,
``popitem``, ``setdefault``, ``update``, and ``values``. Usage of any of
these methods will cause a deprecation warning to be emitted. These
methods were added for internal compatibility in ``repoze.bfg`` 1.1 (code
that currently expects a request object expected an environ object in BFG
1.0 and before). In a future version, these methods will be removed
entirely.
|
|
``webob.request.Request`` and implemented ``__getattr__``, ``__setattr__``
and ``__delattr__`` itself in order to overidde "adhoc attr" WebOb behavior
where attributes of the request are stored in the environ. Now,
``pyramid.request.Request`` object inherits from (the more recent)
``webob.request.BaseRequest`` instead of ``webob.request.Request``, which
provides the same behavior. ``pyramid.request.Request`` no longer
implements its own ``__getattr__``, ``__setattr__`` or ``__delattr__`` as a
result.
|
|
|
|
- Modify documentation for cross-referencing.
- Use add_view(viewname) syntax rather than add_view(view=viewname)
syntax for normalization.
- Use warnings.warn rather than zope.deprecated in order to make
testing easier.
- Move tests which test deprecated methods of configurator to a
separate test case.
|
|
|
