| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
only used as a deprecation mechanism, so where possible we've kept around
the deprecation warnings and we've used zope.deprectation instead. However,
when cross-module deprecations were included, rather than introducing a
cyclic dependency, we just removed the deprecation itself.
As a result:
- Since version 0.6.1, a deprecation warning has been emitted when the
name ``model_url`` is imported from the ``repoze.bfg.traversal``
module. This import alias (and the deprecation warning) has been
removed. Any import of the ``model_url`` function will now need to
be done from ``repoze.bfg.url``; any import of the name
``model_url`` from ``repoze.bfg.traversal`` will now fail. This was
done to remove a dependency on zope.deferredimport.
- Since version 0.6.5, a deprecation warning has been emitted when the
name ``RoutesModelTraverser`` is imported from the
``repoze.bfg.traversal`` module. This import alias (and the
deprecation warning) has been removed. Any import of the
``RoutesModelTraverser`` class will now need to be done from
``repoze.bfg.urldispatch``; any import of the name
``RoutesModelTraverser`` from ``repoze.bfg.traversal`` will now
fail. This was done to remove a dependency on zope.deferredimport.
|
|
|
|
|
|
from zope.deferredimport.
|
|
|
|
|
|
|
|
``zope.deprecation`` for forward compatibility reasons
(``zope.component`` will stop relying on ``zope.deferredimport``
soon and although we use it directly, it's only a transitive
dependency, and ''zope.deprecation`` is used even though it's only a
transitive dependency as well).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--------
- The functionality of ``repoze.bfg.convention`` has been merged into
the core. Applications which make use of ``repoze.bfg.convention``
will continue to work indefinitely, but it is recommended that apps
stop depending upon it. To do so, substitute imports of
``repoze.bfg.convention.bfg_view`` with imports of
``repoze.bfg.view.bfg_view``, and change the stanza in ZCML from
``<convention package=".">`` to ``<grok package=".">``. As a result
of the merge, bfg has grown a new dependency: ``martian``.
- View functions which use the pushpage decorator are now pickleable
(meaning their use won't prevent a ``configure.zcml.cache`` file
from being written to disk).
Implementation Changes
----------------------
- The ``wsgiapp`` decorator now uses ``webob.Request.get_response`` to
do its work rather than relying on howgrown WSGI code.
|
|
|
|
installed in the interpreter which you use to run tests. Using an
interpreter with ``nose`` installed, do ``python setup.py
nosetests`` within a checkout of the ``repoze.bfg`` package to see
test coverage output.
|
|
Added another template showing default ZODB setup using ``repoze.zodbconn``.
|
|
|
|
|
|
chameleon automagically.
|
|
- 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.
|
|
|
|
|
|
|
|
buildout-generated environment.
See also http://lists.repoze.org/pipermail/repoze-dev/2008-December/001038.html
|
|
|
|
|
|
|
|
``__parent__`` of an object that claims it implements ILocation
during traversal even if the ``__name__`` or ``__parent__`` of the
object traversed does not match the name used in the traversal
step or the or the traversal parent . Rationale: it was insane to
do so. This bug was only found due to a misconfiguration in an
application that mistakenly had intermediate persistent
non-ILocation objects; traversal was causing a persistent write on
every request under this setup.
- ``repoze.bfg.location.locate`` now unconditionally sets
``__name__`` and ``__parent__`` on objects which provide ILocation
(it previously only set them conditionally if they didn't match
attributes already present on the object via equality).
Prep for 0.5.0.
|
|
|
|
``repoze.bfg.convention`` in context.
|
|
all generated URLs unless further elements are passed in as the
third and following arguments. Rationale: views often use
``model_url`` without the third-and-following arguments in order
to generate a URL for a model in order to point at the default
view of a model. The URL that points to the default view of the
*root* model is technically ``http://mysite/`` as opposed to
``http://mysite`` (browsers happen to ask for '/' implicitly in
the GET request). Because URLs are never automatically generated
for anything *except* models by ``model_url``, and because the
root model is not really special, we continue this pattern. The
impact of this change is minimal (at most you will have too many
slashes in your URL, which BFG deals with gracefully anyway).
Prep for 0.4.8.
|
|
style "object events" (subscribers accept more than a single event
argument). We extend the list with the arguments, rather than
append.
Prep for 0.4.7.
|
|
wrong value for the root object (e.g. ``model_path`` returned
``''`` for the root object, while it should have been returning
``'/'``).
Prep for 0.4.6.
|
|
|
|
|
