| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- Rearrange router logic so that start_response is not called until there
is no chance of an exception occurring.
|
|
--------
- 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.
|
|
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).
|
|
-------------
- 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.
|
|
configuration into account in more places and uses glossary
references more liberally.
|
|
|
|
|
|
|
|
an IDebugLogger unnamed utility. A named utility with the old name
is registered for b/w compat.
|
|
Update text files.
|
|
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.
|
|
|
|
- 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.
|
|
Muck around with Configurator constructor.
|
|
|
|
|
|
---------
- 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``.
|
|
|
|
``root`` is available as an attribute of the request before a
NewRequest event is emitted. This makes some potential future
features impossible, or at least awkward (such as grouping traversal
and view lookup into a single adapter lookup).
|
|
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.
|
|
--------
- 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``.
|
|
``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).
|
|
|
|
argument is never used. Note that this refactoring does away with a surplus traverser factory lookup.
|
|
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.
|
|
|
|
slightly earlier now (before a NewRequest event is emitted).
``root`` is the result of the application "root factory".
|
|
|
|
--------
- 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.
|
