| Age | Commit message (Collapse) | Author |
|---|
|
in the pattern, instead of immediately following a ``/``.
- Added ``marker_pattern`` option to ``add_route`` to supply a dict of
regular expressions to be used for markers in the pattern instead of the
default regular expression that matched everything except a ``/``.
|
|
``route_url``. These are simple passthroughs for their respective
functions in ``pyramid.url``.
- Documented the ``matchdict`` and ``matched_route`` attributes of the
request object in the Request API documentation.
|
|
|
|
to :app:`Pyramid`. A custom role setting was added to ``docs/conf.py`` to
allow for this. (internal)
|
|
|
|
|
|
|
|
|
|
|
|
that it is imported from pyramid. API docs can mention its inheritance from
webob (aka "Provide a webob.Response class facade for forward compat").
|
|
|
|
|
|
|
|
|
|
via ``repoze.sphinx.autointerface``.
- The URL Dispatch narrative chapter now refers to the ``interfaces``
chapter to explain the API of an ``IRoute`` object.
- ``tests_require`` now includes ``repoze.sphinx.autointerface`` as a
dependency.
|
|
accepts a different ordering of arguments. Previously it was
``(pattern, name, factory=None, predicates=())``. It is now
``(name, pattern, factory=None, predicates=())``. This is in
support of consistency with ``configurator.add_route``.
- The ``repoze.bfg.urldispatch.RoutesMapper.connect`` method (not an
API) now accepts a different ordering of arguments. Previously it
was ``(pattern, name, factory=None, predicates=())``. It is now
``(name, pattern, factory=None, predicates=())``. This is in
support of consistency with ``configurator.add_route``.
- The ``repoze.bfg.urldispatch.RoutesMapper`` object now has a
``get_route`` method which returns a single Route object or
``None``.
- A new interface ``repoze.bfg.interfaces.IRoute`` was added. The
``repoze.bfg.urldispatch.Route`` object implements this interface.
- The canonical attribute for accessing the routing pattern from a
route object is now ``pattern`` rather than ``path``.
- The argument to ``repoze.bfg.configuration.Configurator.add_route``
which was previously called ``path`` is now called ``pattern`` for
better explicability. For backwards compatibility purposes, passing
a keyword argument named ``path`` to ``add_route`` will still work
indefinitely.
- The ``path`` attribute to the ZCML ``route`` directive is now named
``pattern`` for better explicability. The older ``path`` attribute
will continue to work indefinitely.
- All narrative, API, and tutorial docs which referred to a route
pattern as a ``path`` have now been updated to refer to them as a
``pattern``.
- The routesalchemy template has been updated to use ``pattern`` in
its route declarations rather than ``path``.
|
|
|
|
below-named arguments to be passed as "dotted name strings"
(e.g. "foo.bar.baz") rather than as actual implementation objects
that must be imported:
setup_registry
root_factory, authentication_policy, authorization_policy,
debug_logger, locale_negotiator, request_factory,
renderer_globals_factory
add_subscriber
subscriber, iface
derive_view
view
add_view
view, for_, context, request_type, containment
add_route()
view, view_for, factory, for_, view_context
scan
package
add_renderer
factory
set_forbidden_view
view
set_notfound_view
view
set_request_factory
factory
set_renderer_globals_factory()
factory
set_locale_negotiator
negotiator
testing_add_subscriber
event_iface
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
