| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--------
- 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.
|
|
callbacks are called by the router unconditionally near the very end
of request processing.
|
|
|
|
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.
|
|
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``.
|
|
-------------
- 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.
|
|
``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.
|
|
the "phash" branch.
|
|
|
|
--------
- 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.
|
|
|
|
an IDebugLogger unnamed utility. A named utility with the old name
is registered for b/w compat.
|
|
|
|
ZCML directives which accept paths now register absolute paths, while
imperative registrations now register resource specifications.
|
|
``repoze.bfg.configuration.rendered_response``.
- The ``repoze.bfg.view.decorate_view`` function has been moved to
``repoze.bfg.configuration.decorate_view``.
- The ``repoze.bfg.view.MultiView`` class has been moved to
``repoze.bfg.configuration.MultiView``.
- Fix argument ordering bug in r.b.configuration.Configurator.resource.
|
|
|
|
|
|
---------
- Remove ``ez_setup.py`` and its import from all paster templates,
samples, and tutorials for ``distribute`` compatibility. The
documentation already explains how to install virtualenv (which will
include some ``setuptools`` package), so these files, imports and
usages were superfluous.
Deprecations
------------
- The ``options`` kw arg to the ``repoze.bfg.router.make_app``
function is deprecated. In its place is the keyword argument
``settings``. The ``options`` keyword continues to work, and a
deprecation warning is not emitted when it is detected. However,
the paster templates, code samples, and documentation now make
reference to ``settings`` rather than ``options``. This
change/deprecation was mainly made for purposes of clarity and
symmetry with the ``get_settings()`` API and dicussions of
"settings" in various places in the docs: we want to use the same
name to refer to the same thing everywhere.
|
|
of this type will be sent after traversal is completed, but before
any view code is invoked. Like ``repoze.bfg.events.NewRequest``,
This event will have a single attribute: ``request`` representing
the current request. Unlike the request attribute of
``repoze.bfg.events.NewRequest`` however, during an AfterTraversal
event, the request object will possess attributes set by the
traverser, most notably ``context``, which will be the context used
when a view is found and invoked. The interface
``repoze.bfg.events.IAfterTraversal`` can be used to subscribe to
the event. For example::
<subscriber for="repoze.bfg.interfaces.IAfterTraversal"
handler="my.app.handle_after_traverse"/>
Like any framework event, a subscriber function should expect one
parameter: ``event``.
|
|
arg.
|
|
as an adapter for ``ITraverser`` or ``ITraverserFactory``) will now
receive a *request* as the single argument to its ``__call__``
method. In previous versions it was passed a WSGI ``environ``
object. The request object passed to the factory implements
dictionary-like methods in such a way that existing traverser code
which expects to be passed an environ will continue to work.
- Fix docs.
|
|
``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).
- The router no longer calls ``repoze.bfg.traversal._traverse`` and
does its work "inline" (speed).
|
|
the 99% case, and its behavior can be emulated by returning a root object that implements some interface and registering a traverser for that interface.
|
|
directly. In this case, no adaptation is done before traversal. This feature is added such that a routes factory can implement its own traversal logic without establishing an artificial context only to get a hook into the traversal machinery.
|
|
breaks backwards compatibility, migration is trivial.
|
|
solved the reissue_time authentication policy issue a different way).
|
|
directive. If this value is set, it must be an integer representing
the number of seconds which the auth tkt cookie will survive.
Mainly, its existence allows the auth_tkt cookie to survive across
browser sessions.
- The ``reissue_time`` argument to the ``authtktauthenticationpolicy``
ZCML directive now actually works. When it is set to an integer
value, an authticket set-cookie header is appended to the response
whenever a request requires authentication and 'now' minus the
authticket's timestamp is greater than ``reissue_time`` seconds.
- The router now checks for a ``global_response_headers`` attribute of
the request object before returning a response. If this value
exists, it is presumed to be a sequence of two-tuples, representing
a set of headers to append to the 'normal' response headers. This
feature is internal, rather than exposed internally, because it's
unclear whether it will stay around in the long term. It was added
to support the ``reissue_time`` feature of the authtkt
authentication policy.
- The ``authtkt`` authentication policy ``remember`` method now no
longer honors ``token`` or ``userdata`` keyword arguments.
|
|
|
|
--------
- Add ``setUp`` and ``tearDown`` functions to the
``repoze.bfg.testing`` module. Using ``setUp`` in a test setup and
``tearDown`` in a test teardown is now the recommended way to do
component registry setup and teardown. Previously, it was
recommended that a single function named
``repoze.bfg.testing.cleanUp`` be called in both the test setup and
tear down. ``repoze.bfg.testing.cleanUp`` still exists (and will
exist "forever" due to its widespread use); it is now just an alias
for ``repoze.bfg.testing.setUp`` and is nominally deprecated.
- The BFG component registry is now available in view and event
subscriber code as an attribute of the request
ie. ``request.registry``. This fact is currently undocumented
except for this note, because BFG developers never need to interact
with the registry directly anywhere else.
- The BFG component registry now inherits from ``dict``, meaning that
it can optionally be used as a simple dictionary. *Component*
registrations performed against it via e.g. ``registerUtility``,
``registerAdapter``, and similar API methods are kept in a
completely separate namespace than its dict members, so using the
its component API methods won't effect the keys and values in the
dictionary namespace. Likewise, though the component registry
"happens to be" a dictionary, use of mutating dictionary methods
such as ``__setitem__`` will have no influence on any component
registrations made against it. In other words, the registry object
you obtain via e.g. ``repoze.bfg.threadlocal.get_current_registry``
or ``request.registry`` happens to be both a component registry and
a dictionary, but using its component-registry API won't impact data
added to it via its dictionary API and vice versa. This is a
forward compatibility move based on the goals of "marco".
Documentation
-------------
- Various tutorial test modules updated to use
``repoze.bfg.testing.setUp`` and ``repoze.bfg.testing.tearDown``
methods in order to encourage this as best practice going forward.
Backwards Incompatibilities
---------------------------
- Importing ``getSiteManager`` and ``get_registry`` from
``repoze.bfg.registry`` is no longer supported. These imports were
deprecated in repoze.bfg 1.0. Import of ``getSiteManager`` should
be done as ``from zope.component import getSiteManager``. Import of
``get_registry`` should be done as ``from repoze.bfg.threadlocal
import get_current_registry``. This was done to prevent a circular
import dependency.
- Code bases which alternately invoke both
``zope.testing.cleanup.cleanUp`` and ``repoze.bfg.testing.cleanUp``
(treating them equivalently, using them interchangeably) in the
setUp/tearDown of unit tests will begin to experience test failures
due to lack of test isolation. The "right" mechanism is
``repoze.bfg.testing.cleanUp`` (or the combination of
``repoze.bfg.testing.setUp`` and
``repoze.bfg.testing.tearDown``). but a good number of legacy
codebases will use ``zope.testing.cleanup.cleanUp`` instead. We
support ``zope.testing.cleanup.cleanUp`` but not in combination with
``repoze.bfg.testing.cleanUp`` in the same codebase. You should use
one or the other test cleanup function in a single codebase, but not
both.
Internal
--------
- Created new ``repoze.bfg.configuration`` module which assumes
responsibilities previously held by the ``repoze.bfg.registry`` and
``repoze.bfg.router`` modules (avoid a circular import dependency).
- The result of the ``zope.component.getSiteManager`` function in unit
tests set up with ``repoze.bfg.testing.cleanUp`` or
``repoze.bfg.testing.setUp`` will be an instance of
``repoze.bfg.registry.Registry`` instead of the global
``zope.component.globalregistry.base`` registry. This also means
that the threadlocal ZCA API functions such as ``getAdapter`` and
``getUtility`` as well as internal BFG machinery (such as
``model_url`` and ``route_url``) will consult this registry within
unit tests. This is a forward compatibility move based on the goals
of "marco".
- Removed ``repoze.bfg.testing.addCleanUp`` function and associated
module-scope globals. This was never an API.
|
|
``repoze.bfg.exceptions.NotFound``. The old location still
functions, but emits a deprecation warning.
- The import of ``repoze.bfg.security.Unauthorized`` is deprecated in
favor of ``repoze.bfg.exceptions.Forbidden``. The old location
still functions but emits a deprecation warning. The rename from
``Unauthorized`` to ``Forbidden`` brings parity to the the name of
the exception and the system view it invokes when raised.
- New ``repoze.bfg.exceptions`` module was created to house exceptions
that were previously sprinkled through various modules.
- An ``exceptions`` API chapter was added, documenting the new
``repoze.bfg.exceptions`` module.
|
|
- Speed up ``repoze.bfg.traversal.model_path_tuple`` slightly.
- Speed up ``repoze.bfg.traversal.traverse`` slightly.
- In 0.8a7, the return value expected from an object implementing
``ITraverserFactory`` was changed from a sequence of values to a
dictionary containing the keys ``context``, ``view_name``,
``subpath``, ``traversed``, ``virtual_root``, ``virtual_root_path``,
and ``root``. Until now, old-style traversers which returned a
sequence have continued to work but have generated a deprecation
warning. In this release, traversers which return a sequence
instead of a dictionary will no longer work.
|
|
|
|
instead rely on queryAdapter and a manual default to
ModelGraphTraverser.
- Speed: do not register an IContextURL in configure.zcml; instead
rely on queryAdapter and a manual default to TraversalContextURL.
- General speed microimprovements for helloworld benchmark: replace
try/excepts with statements which use 'in' keyword.
|
|
|
|
|
|
default_notfound_view functions into the ``repoze.bfg.view`` module
(moved from ``repoze.bfg.router``).
|
|
absolute filesystem path including a drive letter was passed as
``filename`` (or as ``configure_zcml`` in the options dict) to
``repoze.bfg.router.make_app``, it would be treated as a
package:resource_name specification.
|
|
|
|
environment variable (``BFG_CONFIGURE_ZCML``) to name a ZCML file
that will be used to bootstrap the application. Previously, the
integrator could not influence which ZCML file was used to do the
boostrapping (only the original application developer could do so).
|
|
arguments to ``repoze.bfg.router.make_app``. Instead, developers
should use the various authentication policy ZCML directives
(``repozewho1authenticationpolicy``,
``remoteuserauthenticationpolicy`` and
``authtktauthenticationpolicy``) and the `aclauthorizationpolicy``
authorization policy directive as described in the changes to the
"Security" narrative documentation chapter and the wiki tutorials.
|
|
IAuthenticationPolicy/IForbiddenView/INotFoundView based on older
concepts from the router module's ``make_app`` function into the
``repoze.bfg.zcml.zcml_configure`` callable, to service
compatibility with scripts that use "zope.configuration.xmlconfig"
(replace with ``repoze.bfg.zml.zcml_configure`` as necessary to get
BBB logic)
|
|
directive can be used to name a view that should be invoked when the
request can't otherwise be resolved to a view callable. For example::
<notfound
view="helloworld.views.notfound_view"/>
- A new ZCML directive was added named ``forbidden``. This ZCML
directive can be used to name a view that should be invoked when a
view callable for a request is found, but cannot be invoked due to
an authorization failure. For example::
<forbidden
view="helloworld.views.forbidden_view"/>
|
|
``environ["PATH_INFO"]`` on the notfound result page rather than the
fullly computed URL.
|
|
# used routes (at least apps without any custom "context
# factory") in BFG 0.9.X and before
|
|
|
|
derivation of values passed as the ``options`` value of
``repoze.bfg.router.make_app``. This API should be preferred
instead of using getUtility(ISettings). I added a new
``repoze.bfg.settings`` API document as well.
|
|
for use as a default context factory as documented in the "Hooks"
chapter.
|
|
non-response object now includes the view's name for troubleshooting
purposes.
- A "new response" event is emitted for forbiden and notfound views.
|
