| Age | Commit message (Collapse) | Author |
|---|
|
setuptools 0.6c9.
- Turn ``view_execution_permitted`` from the :mod:`repoze.bfg.view`
module into a documented API.
- Doc cleanups.
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
quoting function instead of Python's ``urllib.quote``, by caching
URL path segment quoting and encoding results, and by disusing
Python's ``urlparse.urljoin`` in favor of a simple string
concatenation.
|
|
|
|
|
|
|
|
default traverser) always passed each URL path segment to any
``__getitem__`` method of a model object as a byte string (a
``str`` object). Now, by default the ModelGraphTraverser attempts
to decode the path segment to Unicode (a ``unicode`` object) using
the UTF-8 encoding before passing it to the ``__getitem__`` method
of a model object. This makes it possible for model objects to be
dumber in ``__getitem__`` when trying to resolve a subobject, as
model objects themselves no longer need to try to divine whether
or not to try to decode the path segment passed by the
traverser.
Note that since 0.5.4, URLs generated by repoze.bfg's
``model_url`` API will contain UTF-8 encoded path segments as
necessary, so any URL generated by BFG itself will be decodeable
by the traverser. If another application generates URLs to a BFG
application, to be resolved successully, it should generate the
URL with UTF-8 encoded path segments to be successfully resolved.
The decoder is not at all magical: if a non-UTF-8-decodeable path
segment (e.g. one encoded using UTF-16 or some other insanity) is
passed in the URL, BFG will raise a ``TypeError`` with a message
indicating it could not decode the path segment.
To turn on the older behavior, where path segments were not
decoded to Unicode before being passed to model object
``__getitem__`` by the traverser, and were passed as a raw byte
string, set the ``unicode_path_segments`` configuration setting to
a false value in your BFG application's section of the paste .ini
file, for example::
unicode_path_segments = False
Or start the application using the ``BFG_UNICODE_PATH_SEGMENT``
envvar set to a false value::
BFG_UNICODE_PATH_SEGMENTS=0
|
|
|
|
|
|
- URL-quote "extra" element names passed in as ``**elements`` to the
``traversal.model_url`` API. If any of these names is a Unicode
string, encode it to UTF-8 before URL-quoting. This is a slight
backwards incompatibility that will impact you if you were already
UTF-8 encoding or URL-quoting the values you passed in as
``elements`` to this API.
Bugfixes
- UTF-8 encode each segment in the model path used to generate a URL
before url-quoting it within the ``traversal.model_url`` API.
This is a bugfix, as Unicode cannot always be successfully
URL-quoted.
|
|
|
|
buildout-generated environment.
See also http://lists.repoze.org/pipermail/repoze-dev/2008-December/001038.html
|
|
|
|
|
|
|
|
|
|
``testing.registerDummyRenderer`` is used, it now registers a
dummy implementation using ``ITemplateRenderer`` interface, which
is checked for when the built-in templating facilities do
rendering. This change also allows developers to make explcit
named utility registrations in the ZCML registry against
``ITemplateRenderer``; these will be found before any on-disk
template.
|
|
|
|
|
|
|
|
|
|
scheme (see zope.component.adaptedBy); the change-log entry has detailed information.
|
|
within traversal machinery.
|
|
|
|
|
|
|
|
``testing.DummyModel``.
|
|
``__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.
|
|
|
|
where the template does not need to be wrapped in any containing
XML).
Prep for 0.4.9.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
