| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add debug_templates setting.
|
|
API.
- Add roles to configurator API docs.
|
|
|
|
|
|
Shuffle Configurator around so that not passing a registry makes a default one.
|
|
--------
- 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.
|
|
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).
|
|
``BFG_RELOAD_RESOURCES`` environment variable). When this is set to
true, the server never needs to be restarted when moving files
between directory resource overrides (esp. for templates currently).
- Add a ``reload_all`` configuration file setting (aka the
``BFG_RELOAD_ALL`` environment variable) that implies both
``reload_resources`` and ``reload_templates``.
- The ``static`` helper view class now uses a ``PackageURLParser`` in
order to allow for the overriding of static resources (CSS / logo
files, etc) using the ``resource`` ZCML directive. The
``PackageURLParser`` class was added to a (new) ``static`` module in
BFG; it is a subclass of the ``StaticURLParser`` class in
``paste.urlparser``.
- The ``repoze.bfg.templating.renderer_from_cache`` function now
checks for the ``reload_resources`` setting; if it's true, it does
not register a template renderer (it won't use the registry as a
template renderer cache).
- Add ``pkg_resources`` to the glossary.
- Update the "Environment" docs to note the existence of
``reload_resources`` and ``reload_all``.
- Use a colon instead of a tab as the separator between package name
and relpath to form the "spec" when register a ITemplateRenderer.
|
|
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.
|
|
``BFG_UNICODE_PATH_SEGMENTS`` configuration variable have been
removed. Path segments are now always passed to model
``__getitem__`` methods as unicode. "True" has been the default for
this setting since 0.5.4, but changing this configuration setting to
false allowed you to go back to passing raw path element strings to
model ``__getitem__`` methods. This services a speed goal (we get
about +80 req/s by removing the check), and it's clearer just to
always expect unicode path segments in model ``__getitem__``
methods.
|
|
|
|
Bug Fixes
---------
- Fix a bug where the Paste configuration's ``unicode_path_segments``
(and os.environ's ``BFG_UNICODE_PATH_SEGMENTS``) may have been
defaulting to false in some circumstances. It now always defaults
to true, matching the documentation and intent.
- The ``repoze.bfg.traversal.find_model`` API did not work properly
when passed a ``path`` argument which was unicode and contained
high-order bytes when the ``unicode_path_segments`` or
``BFG_UNICODE_PATH_SEGMENTS`` configuration variables were "true".
- A new module was added: ``repoze.bfg.settings``. This contains
deployment-settings-related code.
Behavior Changes
----------------
- The ``make_app`` callable within ``repoze.bfg.router`` now registers
the ``root_policy`` argument as a utility (unnamed, using the new
``repoze.bfg.interfaces.IRootFactory`` as a provides interface)
rather than passing it as the first argument to the
``repoze.bfg.router.Router`` class. As a result the
``repoze.bfg.router.Router`` router class only accepts a single
argument: ``registry``. The ``repoze.bfg.router.Router`` class
retrieves the root policy via a utility lookup now. The
``repoze.bfg.router.make_app`` API also now performs some important
application registrations that were previously handled inside
``repoze.bfg.registry.makeRegistry``.
- The ``repoze.bfg.settings.Settings`` class (an instance of which is
registered as a utility providing
``repoze.bfg.interfaces.ISettings`` when any application is started)
now automatically calls ``repoze.bfg.settings.get_options`` on the
options passed to its constructor. This means that usage of
``get_options`` within an application's ``make_app`` function is no
longer required (the "raw" ``options`` dict or None may be passed).
Deprecations
------------
- Moved the ``repoze.bfg.registry.Settings`` class. This has been
moved to ``repoze.bfg.settings.Settings``. A deprecation warning is
issued when it is imported from the older location.
- Moved the ``repoze.bfg.registry.get_options`` function This has been
moved to ``repoze.bfg.settings.get_options``. A deprecation warning
is issued when it is imported from the older location.
- The ``repoze.bfg.interfaces.IRootPolicy`` interface was renamed
within the interfaces package. It has been renamed to
``IRootFactory``. A deprecation warning is issued when it is
imported from the older location.
|
