| Age | Commit message (Collapse) | Author |
|---|
|
untestable code blocks from being tested.
|
|
``repoze.bfg.configuration.Configurator.setup_registry`` method as
an official API of a ``Configurator``.
|
|
API.
- Add roles to configurator API docs.
|
|
``repoze.bfg.authorization``, and ``repoze.bfg.interfaces`` modules
to API documentation.
|
|
|
|
and config.registry.registerUtility will work).
|
|
``repoze.bfg.configuration.Configurator`` class:
``testing_securitypolicy``, ``testing_models``,
``testing_add_subscriber``, and ``testing_add_template``. These
were added in order to provide more direct access to the
functionality of the ``repoze.bfg.testing`` APIs named
``registerDummySecurityPolicy``, ``registerModels``,
``registerEventListener``, and ``registerTemplateRenderer`` when a
configurator is used. The ``testing`` APIs named are nominally
deprecated (although they will likely remain around "forever", as
they are in heavy use in the wild).
- Doc-deprecated most helper functions in the ``repoze.bfg.testing``
module. These helper functions likely won't be removed any time
soon, nor will they generate a warning any time soon, due to their
heavy use in the wild, but equivalent behavior exists in methods of
a Configurator.
|
|
class: ``add_settings``. This API can be used to add "settings"
(information returned within via the
``repoze.bfg.settings.get_settings`` API) after the configurator has
been initially set up. This is most useful for testing purposes.
|
|
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.
|
|
--------
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
Remove set_security_policies configurator API method.
|
|
optional keyword arguments: ``registry``, ``request`` and
``hook_zca``.
If the ``registry`` argument is not ``None``, the argument will be
treated as the registry that is set as the "current registry" (it
will be returned by ``repoze.bfg.threadlocal.get_current_registry``)
for the duration of the test. If the ``registry`` argument is
``None`` (the default), a new registry is created and used for the
duration of the test.
The value of the ``request`` argument is used as the "current
request" (it will be returned by
``repoze.bfg.threadlocal.get_current_request``) for the duration of
the test; it defaults to ``None``.
If ``hook_zca`` is ``True`` (the default), the
``zope.component.getSiteManager`` function will be hooked with a
function that returns the value of ``registry`` (or the
default-created registry if ``registry`` is ``None``) instead of the
registry returned by ``zope.component.getGlobalSiteManager``,
causing the Zope Component Architecture API (``getSiteManager``,
``getAdapter``, ``getUtility``, and so on) to use the registry we're
using for testing instead of the global ZCA registry.
- The ``repoze.bfg.testing.tearDown`` function now accepts an
``unhook_zca`` argument. If this argument is ``True`` (the
default), ``zope.component.getSiteManager.reset()`` will be called,
causing the "base" registry to once again start returnining the
result of ``zope.component.getSiteManager``.
- Remove hook_zca and unhook_zca methods from Configurator.
|
|
the load_zcml API.
Get rid of hook_zca argument in configurator constructor in favor of a ``hook_zca`` method.
Provide an ``unhook_zca`` method.
|
|
|
|
|
|
removed; it has become unused.
- Change imperative API.
|
|
|
|
|
|
|
|
|
|
|
|
This testing function registers a routes "mapper" object in the
registry, for tests which require its presence. This function is
documented in the ``repoze.bfg.testing`` API documentation.
|
|
solved the reissue_time authentication policy issue a different way).
|
|
|
|
in the "repoze.bfg.testing" API chapter. This allows for
registration of "settings" values obtained via
``repoze.bfg.settings.get_settings()`` for use in unit tests.
|
|
|
|
function populates a component registry from a ZCML file for testing
purposes.
|
|
--------
- 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.
|
|
registering routes to satisfy calls to
e.g. ``repoze.bfg.url.route_url`` in unit tests.
|
|
``repoze.bfg.view.append_slash_notfound_view`` view as the Not Found
view in your application. When this view is the Not Found view
(indicating that no view was found), and any routes have been
defined in the configuration of your application, if the value of
``PATH_INFO`` does not already end in a slash, and if the value of
``PATH_INFO`` *plus* a slash matches any route's path, do an HTTP
redirect to the slash-appended PATH_INFO. Note that this will
*lose* ``POST`` data information (turning it into a GET), so you
shouldn't rely on this to redirect POST requests.
|
|
``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.
|
|
generating URLs to static resources defined by the ``<static>`` ZCML
directive. See the "Views" narrative chapter's section titled
"Generating Static Resource URLs" for more information.
|
|
deprecated in favor of
``repoze.bfg.testing.registerTemplateRenderer``. A deprecation
warning is *not* issued at import time for the former name; it will
exist "forever".
- The ``repoze.bfg.templating.renderer_from_cache`` function has been
moved to ``repoze.bfg.renderer.template_renderer_factory``. This
was never an API, but code in the wild was spotted that used it. A
deprecation warning is issued at import time for the former.
- Better error message when a wrapper view returns None.
|
|
|
|
|
|
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.
|
|
"front" for the Routes ``url_for`` API. See the URL Dispatch
narrative chapter and the "repoze.bfg.url" module API documentation
for more information.
|
|
|
|
|
|
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.
|
|
enough to be very helpful and had a misleading name.
|
|
|
|
should be used (**very sparingly**) to retrieve the "current"
request. See the ``repoze.bfg.request`` API documentation for more
information.
|
|
|
|
credentials from an auth_tkt cookie managed by the application
itself (instead of relying on an upstream data source for
authentication data). See the Security API chapter of the
documentation for more info.
- Allow RemoteUserAuthenticationPolicy and
RepozeWho1AuthenticationPolicy to accept various constructor
arguments. See the Security API chapter of the documentation for
more info.
|
