| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--------
- 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.
|
|
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``.
|
|
|
|
``traverse`` route argument.
- Fix route ZCML directive to use traverse.
|
|
--------
- 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.
|
|
$REPOZE_SVN/repoze.bfg/branches/i18n
No foreigners were harmed in the coding of this feature.
|
|
<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.
|
|
decorator that provided a package-relative template filename might
not have been resolved properly. Symptom: inappropriate ``Missing
template resource`` errors.
|
|
---------
- Ensure that ``secure`` flag for AuthTktAuthenticationPolicy
constructor does what it's documented to do (merge Daniel Holth's
fancy-cookies-2 branch).
New Features
------------
- Add ``path`` and ``http_only`` options to
AuthTktAuthenticationPolicy constructor (merge Daniel Holth's
fancy-cookies-2 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.
|
|
|
|
--------
- The ``Configurator.add_view`` method now accepts an argument named
``context``. This is an alias for the older argument named
``for_``; it is preferred over ``for_``, but ``for_`` will continue
to be supported "forever".
- The ``view`` ZCML directive now accepts an attribute named
``context``. This is an alias for the older attribute named
``for``; it is preferred over ``for``, but ``for`` will continue to
be supported "forever".
- The ``Configurator.add_route`` method now accepts an argument named
``view_context``. This is an alias for the older argument named
``view_for``; it is preferred over ``view_for``, but ``view_for``
will continue to be supported "forever".
- The ``route`` ZCML directive now accepts an attribute named
``view_context``. This is an alias for the older attribute named
``view_for``; it is preferred over ``view_for``, but ``view_for``
will continue to be supported "forever".
Documentation and Paster Templates
----------------------------------
- All uses of the ``Configurator.add_view`` method that used its
``for_`` argument now use the ``context``argument instead.
- All uses of the ``Configurator.add_route`` method that used its
``view_for`` argument now use the ``view_context``argument instead.
- All uses of the ``view`` ZCML directive that used its ``for``
attribute now use the ``context`` attribute instead.
- All uses of the ``route`` ZCML directive that used its ``view_for``
attribute now use the ``view_context`` attribute instead.
|
|
and config.registry.registerUtility will work).
|
|
class: ``add_adapter`` and ``add_utility``. These, respectively,
perform the same functions as the ``registerAdapter`` and
``registerUtility`` functions of a ZCA registry. They were added to
allow for a more consistent testing API for applications that make
use of the ZCA directly.
- Cause the ``adapter``, ``utility``, and ``subscriber`` ZCML
directives to use a ``Configurator`` instance and associated
configurator APIs rather than a ZCA registry directly.
|
|
``add_view`` method, the ``bfg_view`` decorator and the attribute
list of the ZCML ``view`` directive. If ``custom_predicates`` is
specified, it must be a sequence of predicate callables (a predicate
callable accepts two arguments: ``context`` and ``request`` and
returns ``True`` or ``False``). The associated view callable will
only be invoked if all custom predicates return ``True``. Use one
or more custom predicates when no existing predefined predicate is
useful. Predefined and custom predicates can be mixed freely.
- Add a ``custom_predicates`` argument to the ``Configurator``
``add_route`` and the attribute list of the ZCML ``route``
directive. If ``custom_predicates`` is specified, it must be a
sequence of predicate callables (a predicate callable accepts two
arguments: ``context`` and ``request`` and returns ``True`` or
``False``). The associated route will match will only be invoked if
all custom predicates return ``True``, else route matching
continues. Use one or more custom predicates when no existing
predefined predicate is useful. Predefined and custom predicates
can be mixed freely.
|
|
of a ``Configurator`` is now importable as
``repoze.bfg.exceptions.ConfigurationError``.
|
|
|
|
|
|
Allow path specifications for renderers which are already resource specifications.
|
|
|
|
context.path.
|
|
|
|
|
|
functionality is replaced internally).
|
|
|
|
removed; it has become unused.
- Change imperative API.
|
|
an IDebugLogger unnamed utility. A named utility with the old name
is registered for b/w compat.
|
|
|
|
to Configurator in closures.
|
|
ZCML directives which accept paths now register absolute paths, while
imperative registrations now register resource specifications.
|
|
|
|
|
|
|
|
``repoze.bfg.view.render_view_to_iterable``,
``repoze.bfg.view.render_view_to_response``,
``repoze.bfg.view.append_slash_notfound_view``,
``repoze.bfg.view.default_notfound_view``,
``repoze.bfg.view.default_forbidden_view``, and the
``repoze.bfg.configuration.rendered_response`` functions now expects
to be called with a request object that has a ``registry`` attribute
which represents the current ZCA registry. This should only be a
problem when passing a custom request object to code which ends up
calling these functions in a unit test. To retrofit tests that end
up calling these functions which expect to be able to use a
non-registry-aware request object, use the
``repoze.bfg.threadlocal.get_current_request`` API in the test to
create the request; this will return a
``repoze.bfg.testing.DummyRequest`` that has the current registry as
its ``registry`` attribute. Alternatively, use the
``repoze.bfg.threadlocal.get_current_registry`` API: call this
function and add an attribute to your unit test request object named
``registry`` with the result.
- The ``repoze.bfg.view.derive_view`` callable has been removed. Use
``repoze.bfg.configuration.Configurator.derive_view`` instead (still
not an API, however).
|
|
|
|
|
|
|
|
- The ``repoze.bfg.view.map_view`` callable has been removed.
- The ``repoze.bfg.view.owrap_view`` callable has been removed.
- The ``repoze.bfg.view.predicate_wrap`` callable has been removed.
- The ``repoze.bfg.view.secure_view`` callable has been removed.
- The ``repoze.bfg.view.authdebug_view`` callable has been removed.
- The ``repoze.bfg.view.renderer_from_name`` callable has been removed.
- Coverage.
|
|
|
|
|
|
|
|
``remember`` and ``forget`` methods would be of type ``unicode`` if
the ``cookie_name`` attribute was used in the ZCML declaration.
This violated the WSGI spec, causing a ``TypeError`` to be raised
when these headers were used under ``mod_wsgi``.
- If a routes-only BFG app was mounted under a path in modwsgi, ala
``WSGIScriptAlias /myapp
/Users/chrism/projects/modwsgi/env/bfg.wsgi``, the home route (a
route with the path of ``'/'`` or ``''``) would not match when the
path ``/myapp`` was visited (only when the path ``/myapp/`` was
visited). This is now fixed: if the urldispatch root factory notes
that the PATH_INFO is empty, it converts it to a single slash before
trying to do matching.
|
|
``<route>`` ZCML directive (in-the-wild 1.1a bw compat).
- ``bfg_routesalchemy`` paster template: change ``<route>``
declarations: rename ``renderer`` attribute to ``view_renderer``.
- In ``<route>`` declarations in tutorial ZCML, rename ``renderer``
attribute to ``view_renderer`` (fwd compat).
|
|
|
|
``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.
|
|
--------
- In previous versions of BFG, the "root factory" (the ``get_root``
callable passed to ``make_app`` or a function pointed to by the
``factory`` attribute of a route) was called with a "bare" WSGI
environment. In this version, and going forward, it will be called
with a ``request`` object. The request object passed to the factory
implements dictionary-like methods in such a way that existing root
factory code which expects to be passed an environ will continue to
work.
Internal
--------
- The request implements dictionary-like methods that mutate and query
the WSGI environ. This is only for the purpose of backwards
compatibility with root factories which expect an ``environ`` rather
than a request.
- The ``repoze.bfg.request.create_route_request_factory`` function,
which returned a request factory was removed in favor of a
``repoze.bfg.request.route_request_interface`` function, which
returns an interface.
- The ``repoze.bfg.request.Request`` class, which is a subclass of
``webob.Request`` now defines its own ``__setattr__``,
``__getattr__`` and ``__delattr__`` methods, which override the
default WebOb behavior. The default WebOb behavior stores
attributes of the request in ``self.environ['webob.adhoc_attrs']``,
and retrieves them from that dictionary during a ``__getattr__``.
This behavior was undesirable for speed and "expectation" reasons.
Now attributes of the ``request`` are stored in ``request.__dict__``
(as you otherwise might expect from an object that did not override
these methods).
- Reverse the order in which the router calls the request factory and
the root factory. The request factory is now called first; the
resulting request is passed to the root factory.
- The ``repoze.bfg.request.request_factory`` function has been
removed. Its functionality is no longer required.
- The "routes root factory" that wraps the default root factory when
there are routes mentioned in the configuration now attaches an
interface to the request via ``zope.interface.directlyProvides``.
This replaces logic in the (now-gone)
``repoze.bfg.request.request_factory`` function.
- The ``route`` and ``view`` ZCML directives now register an interface
as a named utility (retrieved from
``repoze.bfg.request.route_request_interface``) rather than a
request factory (the previous return value of the now-missing
``repoze.bfg.request.create_route_request_factory``.
|
|
``request_param`` predicate attribute was used on the ZCML ``view``
directive if any two otherwise same-predicated views had the
combination of a predicate value with an ``=`` sign and one without
(e.g. ``a`` vs. ``a=123``).
|
