| Age | Commit message (Collapse) | Author |
|---|
|
This returns an object implementing the ``IRoutesMapper`` interface.
|
|
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``.
|
|
when rendering a Chameleon template that has not already been
rendered once. This would usually occur directly after a restart,
when more than one person or thread is trying to execute the same
view at the same time: https://bugs.launchpad.net/karl3/+bug/621364
|
|
custom route/view predicate in order to allow the custom predicate
some control over which predicates are "equal".
- Use ``response.headerlist.append`` instead of
``response.headers.add`` in
``repoze.bfg.request.add_global_response_headers`` in case the
response is not a WebOb response.
|
|
resource specifications were used to create two separate static
views, but they shared a common prefix, it was possible that
``static_url`` would generate an incorrect URL.
- Fix another bug in ``repoze.bfg.static_url`` URL generation: too
many slashes in generated URL.
|
|
enable mutations to the response to take effect.
|
|
|
|
``request`` attribute; as a result, a handler for INewResponse now
has access to the request which caused the response.
- The INewResponse event is now not sent to listeners if the response
returned by view code (or a renderer) is not a "real" response
(e.g. if it does not have ``.status``, ``.headerlist`` and
``.app_iter`` attribtues).
|
|
(either via the ``static`` ZCML directive or via the
``add_static_view`` method of the configurator) was incorrect. It
was regsistered for e.g. ``static*traverse``, while it should have
been registered for ``static/*traverse``. Symptom: two static views
could not reliably be added to a system when they both shared the
same path prefix (e.g. ``/static`` and ``/static2``).
|
|
|
|
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
|
|
-------------
- Add an API chapter for the ``repoze.bfg.request`` module, which
includes documentation for the ``repoze.bfg.request.Request`` class
(the "request object").
- Modify the "Request and Response" narrative chapter to reference the
new ``repoze.bfg.request`` API chapter. Some content was moved from
this chapter into the API documentation itself.
Features
--------
- A new ``repoze.bfg.request.Request.add_response_callback`` API has
been added. This method is documented in the new
``repoze.bfg.request`` API chapter. It can be used to influence
response values before a concrete response object has been created.
Internal
--------
- The (internal) feature which made it possible to attach a
``global_response_headers`` attribute to the request (which was
assumed to contain a sequence of header key/value pairs which would
later be added to the response by the router), has been removed.
The functionality of
``repoze.bfg.request.Request.add_response_callback`` takes its
place.
|
|
wraps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
:meth"`repoze.bfg.configuration.Configurator.absolute_resource_spec`
method resolves a potentially relative :term:`resource
specification` string into an absolute version.
|
|
|
|
a ``package`` constructor argument. The ``package`` argument was
previously required to be a package *object* (not a dotted name
string).
- The ``repoze.bfg.configuration.Configurator.with_package`` method
was added. This method returns a new Configurator using the same
application registry as the configurator object it is called
upon. The new configurator is created afresh with its ``package``
constructor argument set to the value passed to ``with_package``.
This feature will make it easier for future BFG versions to allow
dotted names as arguments in places where currently only object
references are allowed (the work to allow dotted names isntead of
object references everywhere has not yet been done, however).
- The ``repoze.bfg.configuration.Configurator.maybe_dotted`` method
resolves a Python dotted name string supplied as its ``dotted``
argument to a global Python object. If the value cannot be
resolved, a ``repoze.bfg.configuration.ConfigurationError`` is
raised. If the value supplied as ``dotted`` is not a string, the
value is returned unconditionally without any resolution attempted.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
decorator decorates module-scope functions, which are then treated
as event listeners after a scan() is performed. See the Events
narrative documentation chapter and the ``repoze.bfg.events`` module
documentation for more information.
|
|
exist" meaning, temporally, a view was added with a route name for a
route which had not yet been added via add_route), the value of the
``custom_predicate`` argument to ``add_view`` was lost. Symptom:
wrong view matches when using URL dispatch and custom view
predicates together.
|
|
|
|
|
|
|
|
``set_request_factory``. If used, this method will set the factory
used by the :mod:`repoze.bfg` router to create all request objects.
- The ``Configurator`` constructor takes an additional argument:
``request_factory``. If used, this argument will set the factory
used by the :mod:`repoze.bfg` router to create all request objects.
- The ``Hooks`` narrative chapter now contains a section about
changing the request factory.
|
|
``traverse`` route argument.
- Fix route ZCML directive to use traverse.
|
|
|
|
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.
|
|
``repoze.bfg.exceptions.PredicateMismatch`` now exists. This
exception is currently raised when no constituent view of a
multiview can be called (due to no predicate match). Previously, in
this situation, a ``repoze.bfg.exceptions.NotFound`` was raised. We
provide backwards compatibility for code that expected a
``NotFound`` to be raised when no predicates match by causing
``repoze.bfg.exceptions.PredicateMismatch`` to inherit from
``NotFound``. This will cause any exception view registered for
``NotFound`` to be called when a predicate mismatch occurs, as was
the previous behavior.
There is however, one perverse case that will expose a backwards
incompatibility. If 1) you had a view that was registered as a
member of a multiview 2) this view explicitly raised a ``NotFound``
exception *in order to* proceed to the next predicate check in the
multiview, that code will now behave differently: rather than
skipping to the next view match, a NotFound will be raised to the
top-level exception handling machinery instead. For code to be
depending upon the behavior of a view raising ``NotFound`` to
proceed to the next predicate match, would be tragic, but not
impossible, given that ``NotFound`` is a public interface.
``repoze.bfg.exceptions.PredicateMismatch`` is not a public API and
cannot be depended upon by application code, so you should not
change your view code to raise ``PredicateMismatch``. Instead, move
the logic which raised the ``NotFound`` exception in the view out
into a custom view predicate.
|
|
--------
- New view predicate: match_val. The ``match_val`` value represents
the presence of a value in the structure added to the request named
``matchdict`` during URL dispatch representing the match values from
the route pattern (e.g. if the route pattern has ``:foo`` in it, and
the route matches, a key will exist in the matchdict named ``foo``).
Like all other view predicates, this feature is exposed via the
``bfg_view`` API, the Configurator ``add_view`` API, and the ZCML
``view`` directive.
Documentation
-------------
- API documentation for the ``add_view`` method of the configurator
changed to include ``match_val``.
- ZCML documentation for ``view`` ZCML directive changed to include
``match_val``.
- The ``Views`` narrative chapter now contains a description of the
``match_val`` predicate.
Bug Fixes
---------
- The ``header`` predicate (when used as either a view predicate or a
route predicate) had a problem when specified with a name/regex
pair. When the header did not exist in the headers dictionary, the
regex match could be fed ``None``, causing it to throw a
``TypeError: expected string or buffer`` exception. Now, the
predicate returns False as intended.
Internal
--------
- Remove ``repoze.bfg.configuration.isclass`` function in favor of
using ``inspect.isclass``.
|
|
|
|
This URL is a subclass of the built-in Python exception named
``UnicodeDecodeError``.
- When decoding a URL segment to Unicode fails, the exception raised
is now ``repoze.bfg.exceptions.URLDecodeError`` instead of
``UnicodeDecodeError``. This makes it possible to register an
exception view invoked specifically when ``repoze.bfg`` cannot
decode a URL.
|
|
``repoze.bfg.configuration.Configurator.add_static_view``. Before
1.3a4, view names that contained a slash were supported as route
prefixes. 1.3a4 broke this by trying to treat them as full URLs.
|
|
|
|
|
|
``_app_url`` is present in the arguments passed to ``route_url``,
this value will be used as the protocol/hostname/port/leading path
prefix of the generated URL. For example, using an ``_app_url`` of
``http://example.com:8080/foo`` would cause the URL
``http://example.com:8080/foo/fleeb/flub`` to be returned from this
function if the expansion of the route pattern associated with the
``route_name`` expanded to ``/fleeb/flub``.
- It is now possible to use a URL as the ``name`` argument fed to
``repoze.bfg.configuration.Configurator.add_static_view``. When the
name argument is a URL, the ``repoze.bfg.url.static_url`` API will
generate join this URL (as a prefix) to a path including the static
file name. This makes it more possible to put static media on a
separate webserver for production, while keeping static media
package-internal and served by the development webserver during
development.
|
|
|
|
information
|
