| Age | Commit message (Collapse) | Author |
|---|
|
This interface is provided by all internal exception classes (such
as ``repoze.bfg.exceptions.NotFound`` and
``repoze.bfg.exceptions.Forbidden``), instances of which are both
exception objects and can behave as WSGI response objects. This
interface is made public so that exception classes which are also
valid WSGI response factories can be configured to implement them
or exception instances which are also or response instances can be
configured to provide them.
- New API class: ``repoze.bfg.view.AppendSlashNotFoundViewFactory`` (undoes
previous custom_notfound_view on request passsed to
append_slash_notfound_view).
- Previously, two default view functions were registered at
Configurator setup (one for ``repoze.bfg.exceptions.NotFound`` named
``default_notfound_view`` and one for
``repoze.bfg.exceptions.Forbidden`` named
``default_forbidden_view``) to render internal exception responses.
Those default view functions have been removed, replaced with a
generic default view function which is registered at Configurator
setup for the ``repoze.bfg.interfaces.IExceptionResponse`` interface
that simply returns the exception instance; the ``NotFound` and
``Forbidden`` classes are now still exception factories but they are
also response factories which generate instances that implement the
new ``repoze.bfg.interfaces.IExceptionResponse`` interface.
|
|
--------
- There can only be one Not Found view in any ``repoze.bfg``
application. If you use
``repoze.bfg.view.append_slash_notfound_view`` as the Not Found
view, it still must generate a NotFound response when it cannot
redirect to a slash-appended URL; this not found response will be
visible to site users.
As of this release, if you wish to use a custom notfound view
callable when ``append_slash_notfound_view`` does not redirect to a
slash-appended URL, use a wrapper function as the
``repoze.bfg.exceptions.NotFound`` view; have this wrapper attach a
view callable which returns a response to the request object named
``custom_notfound_view`` before calling
``append_slash_notfound_view``. For example::
from webob.exc import HTTPNotFound
from repoze.bfg.exceptions import NotFound
from repoze.bfg.view import append_slash_notfound_view
def notfound_view(exc, request):
def fallback_notfound_view(exc, request):
return HTTPNotFound('It aint there, stop trying!')
request.fallback_notfound_view = fallback_notfound_view
return append_slash_notfound_view(exc, request)
config.add_view(notfound_view, context=NotFound)
``custom_notfound_view`` must adhere to the two-argument view
callable calling convention of ``(context, request)`` (``context``
will be the exception object).
If ``custom_notfound_view`` is not found on the request object, a
default notfound response will be generated when the
``append_slash_notfound_view`` doesn't redirect to a slash-appended
URL.
Documentation
--------------
- Expanded the "Cleaning Up After a Request" section of the URL
Dispatch narrative chapter.
- Expanded the "Redirecting to Slash-Appended Routes" section of the
URL Dispatch narrative chapter.
|
|
|
|
|
|
and the ``route`` ZCML directive: ``traverse``. If you would like
to cause the ``context`` to be something other than the ``root``
object when this route matches, you can spell a traversal pattern as
the ``traverse`` argument. This traversal pattern will be used as
the traversal path: traversal will begin at the root object implied
by this route (either the global root, or the object returned by the
``factory`` associated with this route).
The syntax of the ``traverse`` argument is the same as it is for
``path``. For example, if the ``path`` provided is
``articles/:article/edit``, and the ``traverse`` argument provided
is ``/:article``, when a request comes in that causes the route to
match in such a way that the ``article`` match value is '1' (when
the request URI is ``/articles/1/edit``), the traversal path will be
generated as ``/1``. This means that the root object's
``__getitem__`` will be called with the name ``1`` during the
traversal phase. If the ``1`` object exists, it will become the
``context`` of the request. The Traversal narrative has more
information about traversal.
If the traversal path contains segment marker names which are not
present in the path argument, a runtime error will occur. The
``traverse`` pattern should not contain segment markers that do not
exist in the ``path``.
A similar combining of routing and traversal is available when a
route is matched which contains a ``*traverse`` remainder marker in
its path. The ``traverse`` argument allows you to associate route
patterns with an arbitrary traversal path without using a a
``*traverse`` remainder marker; instead you can use other match
information.
Note that the ``traverse`` argument is ignored when attached to a
route that has a ``*traverse`` remainder marker in its path.
|
|
information
|
|
|
|
|
|
narrative chapter.
|
|
|
|
============
Paster Templates
----------------
- The ``bfg_alchemy`` and ``bfg_routesalchemy`` templates no longer
register a ``handle_teardown`` event listener which calls
``DBSession.remove``. This was found by Chris Withers to be
unnecessary.
Documentation
-------------
- The "bfgwiki2" (URL dispatch wiki) tutorial code and documentation
was changed to remove the ``handle_teardown`` event listener which
calls ``DBSession.remove``.
- Any mention of the ``handle_teardown`` event listener as used by the
paster templates was removed from the URL Dispatch narrative chapter.
|
|
the "phash" branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
``view_path_info``, ``view_request_method``, ``view_request_param``,
and ``view_containment`` predicate arguments from the
``Configurator.add_route`` argument list. These arguments were
speculative. If you need the features exposed by these arguments,
add a view associated with a route using the ``route_name`` argument
to the ``add_view`` method instead.
- Remove ``view_header``, ``view_accept``, ``view_xhr``,
``view_path_info``, ``view_request_method``, ``view_request_param``,
and ``view_containment`` predicate arguments from the ``route`` ZCML
directive attribute set. These attributes were speculative. If you
need the features exposed by these attributes, add a view associated
with a route using the ``route_name`` attribute of the ``view`` ZCML
directive instead.
|
|
|
|
|
|
Merge a bunch of paper-based docs fixes
Configure logging during bfgshell.
|
|
|
|
|
|
|
|
|
|
code.
|
|
|
|
|
|
|
|
|
|
|
|
This section contains detailed ZCML directive information, some of
which was removed from various narrative chapters.
|
|
untestable code blocks from being tested.
|
|
|
|
|
|
|
|
|
|
|
|
documentation.
- Minor typo fixes.
|
|
|
|
``request_method``, ``path_info``, ``request_param``, ``header`` and
``accept`` are now *route* predicates rather than *view* predicates.
If one or more of these predicates is specified in the route
configuration, all of the predicates must return true for the route
to match a request. If one or more of the route predicates
associated with a route returns ``False`` when checked during a
request, the route match fails, and the next match in the routelist
is tried. This differs from the previous behavior, where no route
predicates existed and all predicates were considered view
predicates, because in that scenario, the next route was not tried.
|
|
as an adapter for ``ITraverser`` or ``ITraverserFactory``) will now
receive a *request* as the single argument to its ``__call__``
method. In previous versions it was passed a WSGI ``environ``
object. The request object passed to the factory implements
dictionary-like methods in such a way that existing traverser code
which expects to be passed an environ will continue to work.
- Fix docs.
|
|
predicates to ZCML view declaration, ZCML route declaration, and
``bfg_view`` decorator. See the ``Views`` narrative documentation
chapter for more information about these predicates.
|
|
urldispatch narrative chapter, where it's most helpful.
|
