| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--------
- 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.
|
|
|
|
|
|
|
|
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.
|
|
deprecated. Its import and usage does not throw a warning, nor will
it probably ever disappear. However, using a
``repoze.bfg.configuration.Configurator`` class is now the preferred
way to generate a WSGI application.
- The ``run.py`` module in various ``repoze.bfg`` ``paster`` templates
now use a ``repoze.bfg.configuration.Configurator`` class instead of
the (now-legacy) ``repoze.bfg.router.make_app`` function to produce
a WSGI application.
|
|
|
|
|
|
|
|
|
|
|
|
---------
- 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.
|
|
import. Thanks to Daniel Holth for the initial patch.
|
|
|
|
|
|
documentation chapter.
|
|
|
|
|
|
|
|
|
|
``repoze.bfg`` application.
|
|
|
|
|
|
|
|
|
|
|
|
explains how to override resources within one package from another
package.
|
|
URL paths.
|
|
|
|
|
|
be used to get an interactive prompt with your BFG root object in
the global namespace. E.g.::
bin/paster bfgshell /path/to/myapp.ini myapp
See the ``Project`` chapter in the BFG documentation for more
information.
|
|
|
|
``configure.zcml.cache`` next to ``configure.zcml`` files in
projects). The code which managed writing and reading of the cache
file was a source of subtle bugs when users switched between
imperative (e.g. ``@bfg_view``) registrations and declarative
registrations (e.g. the ``view`` directive in ZCML) on the same
project. On a moderately-sized project (535 ZCML actions and 15 ZCML
files), executing actions read from the pickle was saving us only
about 200ms (2.5 sec vs 2.7 sec average). On very small projects (1
ZCML file and 4 actions), startup time was comparable, and sometimes
even slower when reading from the pickle, and both ways were so fast
that it really just didn't matter anyway.
|
|
|
|
"Available Add On Template System Bindings" in Templates chapter in
narrative docs.
- Noted existence of ``alchemy`` paster template.
|
|
sets up a BFG project that uses SQAlchemy (with SQLite) and uses
Routes exclusively to resolve URLs (no traversal root factory is
used). This template can be used via ``paster create -t
bfg_routesalchemy``.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
setuptools 0.6c9.
- Turn ``view_execution_permitted`` from the :mod:`repoze.bfg.view`
module into a documented API.
- Doc cleanups.
|
|
|
|
|
|
against a class rather than an interface.
|
|
Retain old test as an integration test. Update documentation.
|
