| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
``setup.py`` ``tests_require`` argument (Twill will only be
downloaded when :mod:`repoze.bfg` ``setup.py test`` or ``setup.py
nosetests`` is invoked).
|
|
|
|
|
|
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).
|
|
|
|
- Rather than prepare the "stock" implementations of the ZCML
directives from the ``zope.configuration`` package for use under
:mod:`repoze.bfg`, :mod:`repoze.bfg` now makes available the
implementations of directives from the ``repoze.zcml`` package
(see http://static.repoze.org/zcmldocs). As a result, the
:mod:`repoze.bfg` package now depends on the ``repoze.zcml``
package, and no longer depends directly on the ``zope.component``,
``zope.configuration``, ``zope.interface``, or ``zope.proxy``
packages.
The primary reason for this change is to enable us to eventually
reduce the number of inappropriate :mod:`repoze.bfg` Zope package
dependencies, as well as to shed features of dependent package
directives that don't make sense for :mod:`repoze.bfg`.
Note that currently the set of requirements necessary to use bfg
has not changed. This is due to inappropriate Zope package
requirements in ``chameleon.zpt``, which will hopefully be
remedied soon.
- BFG applications written prior to this release which expect the
"stock" ``zope.component`` ZCML directive implementations
(e.g. ``adapter``, ``subscriber``, or ``utility``) to function now
must either 1) include the ``meta.zcml`` file from
``zope.component`` manually (e.g. ``<include
package="zope.component" file="meta.zcml">``) and include the
``zope.security`` package as an ``install_requires`` dependency or
2) change the ZCML in their applications to use the declarations
from `repoze.zcml <http://static.repoze.org/zcmldocs/>`_ instead
of the stock declarations. ``repoze.zcml`` only makes available
the ``adapter``, ``subscriber`` and ``utility`` directives.
- The ``http://namespaces.repoze.org/bfg`` XML namespace is now the
default XML namespace in ZCML for paster-generated applications.
- The copies of BFG's ``meta.zcml`` and ``configure.zcml`` were
removed from the root of the ``repoze.bfg`` package. In 0.3.6, a
new package named ``repoze.bfg.includes`` was added, which
contains the "correct" copies of these ZCML files; the ones that
were removed were for backwards compatibility purposes.
Other
- The minimum requirement for ``chameleon.core`` is now 1.0b13. The
minimum requirement for ``chameleon.zpt`` is now 1.0b7. The
minimum requirement for ``chameleon.genshi`` is now 1.0b2.
|
|
``configure.zcml.pck`` next to the applications's "normal"
configuration file. A given bfg app will usually start faster
if it's able to read the pickle data. It fails gracefully
to reading the real ZCML file if it cannot read the pickle.
|
|
``bfg:view`` configure.zcml element. This attribute will have a
value which is a dotted Python path, pointing at an interface. If
the request object implements this interface when the view lookup
is performed, the appropriate view will be called.
- Remove "template only" views. These were just confusing and were
never documented.
|
|
calling a view, which is a callable that returns a response
directly (as opposed to returning a view). As a result, the
``factory`` attribute in the bfg:view ZCML statement has been
renamed to ``view``. Various interface names were changed also.
- ``render_template`` and ``render_transform`` no longer return a
Response object. Instead, these return strings. The old behavior
can be obtained by using ``render_template_to_response`` and
``render_transform_to_response``.
|
|
|
|
that the template be spelled on the class, while still allowing us to pickle the registry actions.
|
|
knowing their template's name.
|
|
context), so we can later enable an app-local component registry.
|
