| 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.
|
|
--------
- A ``request.matched_route`` attribute is now added to the request
when a route has matched. Its value is the "route" object that
matched (see the ``IRoute`` interface within
``repoze.bfg.interfaces`` API documentation for the API of a route
object).
- The ``exception`` attribute of the request is now set slightly
earlier and in a slightly different set of scenarios, for benefit of
"finished callbacks" and "response callbacks". In previous
versions, the ``exception`` attribute of the request was not set at
all if an exception view was not found. In this version, the
``request.exception`` attribute is set immediately when an exception
is caught by the router, even if an exception view could not be
found.
Backwards Incompatibilities
---------------------------
- The router no longer sets the value ``wsgiorg.routing_args`` into
the environ when a route matches. The value used to be something
like ``((), matchdict)``. This functionality was only ever
obliquely referred to in change logs; it was never documented as an
API.
- The ``exception`` attribute of the request now defaults to ``None``.
In prior versions, the ``request.exception`` attribute did not exist
if an exception was not raised by user code during request
processing; it only began existence once an exception view was
found.
Deprecations
------------
- References to the WSGI environment values ``bfg.routes.matchdict``
and ``bfg.routes.route`` were removed from documentation. These
will stick around internally for several more releases, but it is
``request.matchdict`` and ``request.matched_route`` are now the
"official" way to obtain the matchdict and the route object which
resulted in the match.
Documentation
-------------
- Added two sections to the "Hooks" chapter of the documentation:
"Using Response Callbacks" and "Using Finished Callbacks".
- Added documentation of the ``request.exception`` attribute to the
``repoze.bfg.request.Request`` API documentation.
- Added glossary entries for "response callback" and "finished
callback".
- The "Request Processing" narrative chapter has been updated to note
finished and response callback steps.
|
|
|
|
--------
- 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.
|
|
This returns an object implementing the ``IRoutesMapper`` interface.
|
|
|
|
working with gettext files.
|
|
|
|
$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.
|
|
|
|
|
|
|
|
Merge a bunch of paper-based docs fixes
Configure logging during bfgshell.
|
|
|
|
|
|
code.
|
|
|
|
|
|
--------
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
Documentation licensing.
|
|
This section contains detailed ZCML directive information, some of
which was removed from various narrative chapters.
|
|
--------
- The ``Configurator`` object now has two new methods: ``begin`` and
``end``. The ``begin`` method is meant to be called before any
"configuration" begins (e.g. before ``add_view``, et. al are
called). The ``end`` method is meant to be called after all
"configuration" is complete.
Previously, before there was imperative configuration at all (1.1
and prior), configuration begin and end was invariably implied by
the process of loading a ZCML file. When a ZCML load happened, the
threadlocal data structure containing the request and registry was
modified before the load, and torn down after the load, making sure
that all framework code that needed ``get_current_registry`` for the
duration of the ZCML load was satisfied.
Some API methods called during imperative configuration, (such as
``Configurator.add_view`` when a renderer is involved) end up for
historical reasons calling ``get_current_registry``. However, in
1.2a5 and below, the Configurator supplied no functionality that
allowed people to make sure that ``get_current_registry`` returned
the registry implied by the configurator being used. ``begin`` now
serves this purpose. Inversely, ``end`` pops the thread local
stack, undoing the actions of ``begin``.
We make this boundary explicit to reduce the potential for confusion
when the configurator is used in different circumstances (e.g. in
unit tests and app code vs. just in initial app setup).
Existing code written for 1.2a1-1.2a5 which does not call ``begin``
or ``end`` continues to work in the same manner it did before. It
is however suggested that this code be changed to call ``begin`` and
``end`` to reduce the potential for confusion in the future.
- All ``paster`` templates which generate an application skeleton now
make use of the new ``begin`` and ``end`` methods of the
Configurator they use in their respective copies of ``run.py`` and
``tests.py``.
Documentation
-------------
- All documentation that makes use of a ``Configurator`` object to do
application setup and test setup now makes use of the new ``begin``
and ``end`` methods of the configurator.
Bug Fixes
---------
- When a ``repoze.bfg.exceptions.NotFound`` or
``repoze.bfg.exceptions.Forbidden`` *class* (as opposed to instance)
was raised as an exception within a root factory (or route root
factory), the exception would not be caught properly by the
``repoze.bfg.`` Router and it would propagate to up the call stack,
as opposed to rendering the not found view or the forbidden view as
would have been expected.
|
|
documentation chapter explaining the effect of raising
``repoze.bfg.exceptions.NotFound`` and
``repoze.bfg.exceptions.Forbidden`` from within view code.
- When the ``repoze.bfg.exceptions.NotFound`` or
``repoze.bfg.exceptions.Forbidden`` error is raised from within a
custom root factory or the ``factory`` of a route, the appropriate
response is now sent to the requesting user agent (the result of the
notfound view or the forbidden view, respectively). When these
errors are raised from within a root factory, the ``context`` passed
to the notfound or forbidden view will be ``None``. Also, the
request will not be decorated with ``view_name``, ``subpath``,
``context``, etc. as would normally be the case if traversal had
been allowed to take place.
|
|
event subscriber, as other predicates are now usually an easier way
to get this done.
|
|
|
|
|
|
|
|
|
|
configuration into account in more places and uses glossary
references more liberally.
|
|
|
|
|
|
|
|
|
|
|
|
|
