| Age | Commit message (Collapse) | Author |
|---|
|
urldispatch chapter of the documentation.
Clean up "BFG" vernacular (replace with repoze.bfg).
|
|
|
|
|
|
|
|
``webob.Request.get_response`` to do its work rather than relying on
howgrown WSGI code.
|
|
--------
- 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.
|
|
factory" (e.g. in the ``Router`` class) and ``webob.Response`` and
the "response factory" (e.g. in ``render_template_to_response``),
allow both to be overridden via a ZCML utility hook. See the "Using
ZCML Hooks" chapter of the documentation for more information.
|
|
|
|
attached to each request object on ingress. The HTTP-verb-related
interfaces are defined in ``repoze.bfg.interfaces`` and are
``IGETRequest``, ``IPOSTRequest``, ``IPUTRequest``,
``IDELETERequest`` and ``IHEADRequest``. These interfaces can be
specified as the ``request_type`` attribute of a bfg view
declaration. A view naming a specific HTTP-verb-matching interface
will be found only if the view is defined with a request_type that
matches the HTTP verb in the incoming request. The more general
``IRequest`` interface can be used as the request_type to catch all
requests (and this is indeed the default). All requests implement
``IRequest``. The HTTP-verb-matching idea was pioneered by
`repoze.bfg.restrequest
<http://pypi.python.org/pypi/repoze.bfg.restrequest/1.0.1>`_ . That
package is no longer required, but still functions fine.
|
|
of registries in order to make it possible to call one BFG
application from inside another.
|
|
|
|
- Remove old cold which attempts to recover from trying to unpickle a
``z3c.pt`` template; Chameleon has been the templating engine for a
good long time now. Running repoze.bfg against a sandbox that has
pickled ``z3c.pt`` templates it will now just fail with an
unpickling error, but can be fixed by deleting the template cache
files.
|
|
|
|
|
|
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.
|
|
|
|
method accepts keyword arguments. Each key/value pair in the
keyword arguments causes an assertion to be made that the renderer
received this key with a value equal to the asserted value.
- Projects generated by the paster templates now use the
``DummyTemplateRenderer.assert_`` method in their view tests.
|
|
|
|
|
|
|
|
framework-specific keys and values in the dictionary it returned.
It now returns all the keys and values in the dictionary it is
passed *plus* any framework-specific settings culled from the
environment. As a side effect, all PasteDeploy application-specific
config file settings are made available as attributes of the
``ISettings`` utility from within BFG.
|
|
of changelog in docs.
|
|
Added another template showing default ZODB setup using ``repoze.zodbconn``.
|
|
|
|
|
|
module. Instances of this class are willing to act as BFG views
which return static resources using files on disk. See the
:mod:`repoze.bfg.view` docs for more info.
|
|
- A new module ``repoze.bfg.url`` has been added. It contains the
``model_url`` API (moved from ``repoze.bfg.traversal``) and an
implementation of ``urlencode`` (like Python's
``urllib.urlencode``) which can handle Unicode keys and values in
parameters to the ``query`` argument.
Deprecations
- The ``model_url`` function has been moved from
``repoze.bfg.traversal`` into ``repoze.bfg.url``. It can still
be imported from ``repoze.bfg.traversal`` but an import from
``repoze.bfg.traversal`` will emit a DeprecationWarning.
Features
- The ``repoze.bfg.url.model_url`` API (nee'
``repoze.bfg.traversal.model_url``) now accepts and honors a
keyword argument named ``query``. The value of this argument
will be used to compose a query string, which will be attached to
the generated URL before it is returned. See the API docs (in
the docs directory or `on the web
<http://static.repoze.org/bfgdocs>`_) for more information.
|
|
|
|
``zope.component.interface.provideInterface`` for the ``for``
interface. We don't support ``provideInterface`` in BFG because
it mutates the global registry.
|
|
|
|
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.
|
|
|
|
|
|
|
|
``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``.
|
