| Age | Commit message (Collapse) | Author |
|---|
|
--------
- Normalized all paster templates: each now uses the name ``main`` to
represent the function that returns a WSGI application, each now uses
WebError, each now has roughly the same shape of development.ini style.
Bug Fixes
---------
- The pylons_* paster templates erroneously used the ``{squiggly}`` routing
syntax as the pattern supplied to ``add_route``. This style of routing is
not supported. They were replaced with ``:colon`` style route patterns.
|
|
|
|
|
|
to :app:`Pyramid`. A custom role setting was added to ``docs/conf.py`` to
allow for this. (internal)
|
|
|
|
(e.g. ``pyramid.interfaces.INewRequest``) have been changed to reference
their concrete classes (e.g. ``pyramid.events.NewRequest``) in
documentation about making subscriptions.
|
|
|
|
|
|
|
|
``pyramid.configuration.Configurator.add_view`` method, or the
``pyramid.view.view_config`` decorator (nee ``bfg_view``) is no longer
permitted to be one of the strings ``GET``, ``HEAD``, ``PUT``, ``POST`` or
``DELETE``, and now must always be an interface. Accepting the
method-strings as ``request_type`` was a backwards compatibility strategy
servicing repoze.bfg 1.0 applications. Use the ``request_method``
parameter instead to specify that a view a string request-method predicate.
|
|
``pyramid_routesalchemy`` paster template.
|
|
``pyramid_zodb`` paster template.
|
|
|
|
|
|
now defaults to ``auth_tkt`` (it used to default to ``repoze.bfg.auth_tkt``).
- The default ``cookie_name`` value of the
``pyramid.authentication.AuthTktAuthenticationPolicy`` constructor now
defaults to ``auth_tkt`` (it used to default to ``repoze.bfg.auth_tkt``).
|
|
|
|
that it is imported from pyramid. API docs can mention its inheritance from
webob (aka "Provide a webob.Response class facade for forward compat").
|
|
during internationalization were never APIs. These however have changed to
``localizer`` and ``locale_name``, respectively.
|
|
an exception occurs is now deprecated. Instead, code which relies on this
environ value should use the ``exception`` attribute of the request
(e.g. ``request.exception[0]``) to retrieve the message.
|
|
is sent as an event before a renderer is invoked (but after the
application-level renderer globals factory added via
``pyramid.configurator.configuration.set_renderer_globals_factory``, if any,
has injected its own keys). Applications may now subscribe to the
``IBeforeRender`` event type in order to introspect the and modify the set of
renderer globals before they are passed to a renderer. The event object
iself has a dictionary-like interface that can be used for this purpose. For
example::
from repoze.events import subscriber
from pyramid.interfaces import IRendererGlobalsEvent
@subscriber(IRendererGlobalsEvent)
def add_global(event):
event['mykey'] = 'foo'
If a subscriber attempts to add a key that already exist in the renderer
globals dictionary, a ``KeyError`` is raised. This limitation is due to the
fact that subscribers cannot be ordered relative to each other. The set of
keys added to the renderer globals dictionary by all subscribers and
app-level globals factories must be unique.
|
|
|
|
object itself to a renderer rather than a dictionary derivation)
|
|
at at least one setting to determine how to do rendering
|
|
specification or an absolute path. The dictonary contains the following
keys: ``name`` (the ``renderer=`` value), ``package`` (the 'current package'
when the renderer configuration statement was found), ``type``: the renderer
type, and ``registry``: the current registry.
Third-party ``repoze.bfg`` renderer implementations that must be ported to
Pyramid will need to account for this.
This change was made to support more flexible Mako template rendering.
|
|
|
|
|
|
|
|
|
|
that uses cookies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
message was raised if the renderer name was not a string.
|
|
|
|
|
|
to encode a Unicode ``path`` into ASCII before attempting to split
it and decode its segments. This is for convenience, effectively to
allow a (stored-as-Unicode-in-a-database, or
retrieved-as-Unicode-from-a-request-parameter) Unicode path to be
passed to ``find_model``, which eventually internally uses the
``traversal_path`` function under the hood. In version 1.2 and
prior, if the ``path`` was Unicode, that Unicode was split on
slashes and each resulting segment value was Unicode. An
inappropriate call to the ``decode()`` method of a resulting Unicode
path segment could cause a ``UnicodeDecodeError`` to occur even if
the Unicode representation of the path contained no 'high order'
characters (it effectively did a "double decode"). By converting
the Unicode path argument to ASCII before we attempt to decode and
split, genuine errors will occur in a more obvious place while also
allowing us to handle (for convenience) the case that it's a Unicode
representation formed entirely from ASCII-compatible characters.
|
|
|
|
--------
- 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.
|
|
``set_notfound_view`` or ``set_forbidden_view`` APIs, the context
sent to the view was incorrect (could be ``None`` inappropriately).
|
|
|
|
|
|
``pregenerator`` argument. The pregenerator for the resulting route
is called by ``route_url`` in order to adjust the set of arguments
passed to it by the user for special purposes, such as Pylons
'subdomain' support. It will influence the URL returned by
``route_url``. See the ``repoze.bfg.interfaces.IRoutePregenerator``
interface for more information.
|
|
--------
- 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.
|
|
callbacks are called by the router unconditionally near the very end
of request processing.
|
|
|
