| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
``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.
|
|
end of request processing:
``repoze.bfg.interfaces.IFinishedRequest``. This event is meant to
be used when it is necessary to perform unconditional cleanup after
request processing. See the ``repoze.bfg.events.FinishedRequest``
class documentation for more information.
- The ``repoze.bfg.interfaces.IWSGIApplicationCreatedEvent`` event
interface was renamed to
``repoze.bfg.interfaces.IApplicationCreated``. Likewise, the
``repoze.bfg.events.WSGIApplicationCreatedEvent`` class was renamed
to ``repoze.bfg.events.ApplicationCreated``. The older aliases will
continue to work indefinitely.
- The ``repoze.bfg.interfaces.IAfterTraversal`` event interface was
renamed to ``repoze.bfg.interfaces.IContextFound``. Likewise, the
``repoze.bfg.events.AfterTraveral`` class was renamed to
``repoze.bfg.events.ContextFound``. The older aliases will continue
to work indefinitely.
|
|
--------
- In support of making it easier to configure applications which are
"secure by default", a default permission feature was added. If
supplied, the default permission is used as the permission string to
all view registrations which don't otherwise name a permission.
These APIs are in support of that:
- A new constructor argument was added to the Configurator:
``default_permission``.
- A new method was added to the Configurator:
``set_default_permission``.
- A new ZCML directive was added: ``default_permission``.
Documentation
-------------
- Added documentation for the ``default_permission`` ZCML directive.
- Added documentation for the ``default_permission`` constructor value
and the ``set_default_permission`` method in the Configurator API
documentation.
- Added a new section to the "security" chapter named "Setting a
Default Permission".
- Document ``renderer_globals_factory`` and ``request_factory``
arguments to Configurator constructor.
|
|
traversal path.
|
|
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``.
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
: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.
|
|
|
|
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.
|
|
|
|
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``.
|
|
|
|
|
|
``_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
|
|
--------
- A locale negotiator no longer needs to be registered explicitly. The
default locale negotiator at
``repoze.bfg.i18n.default_locale_negotiator`` is now used
unconditionally as... um, the default locale negotiator.
- The default locale negotiator has become more complex.
* First, the negotiator looks for the ``_LOCALE_`` attribute of
the request object (possibly set by an :term:`event listener`).
* Then it looks for the ``request.params['_LOCALE_']`` value.
* Then it looks for the ``request.cookies['_LOCALE_']`` value.
Backwards Incompatibilities
---------------------------
- The default locale negotiator now looks for the parameter named
``_LOCALE_`` rather than a parameter named ``locale`` in
``request.params``.
Behavior Changes
----------------
- A locale negotiator may now return ``None``, signifying that the
default locale should be used.
Documentation
-------------
- Documentation concerning locale negotiation in the
Internationalizationa and Localization chapter was updated.
|
|
be used to generate a BFG view callable from a user-supplied
function, instance, or class. This useful for external framework and
plugin authors wishing to wrap callables supplied by their users
which follow the same calling conventions and response conventions
as objects that can be supplied directly to BFG as a view callable.
See the ``derive_view`` method in the
``repoze.bfg.configuration.Configurator`` docs.
|
|
a context.
Cause append_slash_notfound_view to work in case it is registered via
set_notfound_view.
|
|
$REPOZE_SVN/repoze.bfg/branches/i18n
No foreigners were harmed in the coding of this feature.
|
|
merge -r9054:9030 svn+ssh://repoze@svn.repoze.org/svn/repoze.bfg/trunk
|
|
|
|
|
|
<http://docs.repoze.org/venusian>`) to perform ``bfg_view``
decorator scanning rather than relying on a BFG-internal decorator
scanner. (Truth be told, Venusian is really just a generalization
of the BFG-internal decorator scanner).
- A new install-time dependency on the ``venusian`` distribution was
added.
- Remove ``repoze.bfg.compat.pkgutil_26.py`` and import alias
``repoze.bfg.compat.walk_packages``. These were only required by
internal scanning machinery; Venusian replaced the internal scanning
machinery, so these are no longer required.
|
|
the "phash" branch.
|
|
that named a view callable and also a ``view_attr`` became broken.
Symptom: ``MyViewClass is not callable`` or the ``__call__`` of a
class was being called instead of the method named via
``view_attr``.
|
|
``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.
|
|
|
|
|
|
of predicates registered first (literally first, not "earlier") for
a triad would lose during view lookup to one registered with fewer.
|
|
|
