| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
removed, as well as its documentation. It had been deprecated since
0.6.3. Code in ``repoze.bfg.urldispatch.RoutesModelTraverser``
which catered to it has also been removed.
- The semantics of the ``route`` ZCML directive have been simplified.
Previously, it was assumed that to use a route, you wanted to map a
route to an externally registered view. The new ``route`` directive
instead has a ``view`` attribute which is required, specifying the
dotted path to a view callable. When a route directive is
processed, a view is *registered* using the name attribute of the
route directive as its name and the callable as its value. The
``view_name`` and ``provides`` attributes of the ``route`` directive
are therefore no longer used. Effectively, if you were previously
using the ``route`` directive, it means you must change a pair of
ZCML directives that look like this::
<route
name="home"
path=""
view_name="login"
factory=".models.root.Root"
/>
<view
for=".models.root.Root"
name="login"
view=".views.login_view"
/>
To a ZCML directive that looks like this::
<route
name="home"
path=""
view=".views.login_view"
factory=".models.root.Root"
/>
In other words, to make old code work, remove the ``view``
directives that were only there to serve the purpose of backing
``route`` directives, and move their ``view=`` attribute into the
``route`` directive itself.
This change also necessitated that the ``name`` attribute of the
``route`` directive is now required. If you were previously using
``route`` directives without a ``name`` attribute, you'll need to
add one (the name is arbitrary, but must be unique among all
``route`` and ``view`` statements).
The ``provides`` attribute of the ``route`` directive has also been
removed. This directive specified a sequence of interface types
that the generated context would be decorated with. Since route
views are always generated now for a single interface
(``repoze.bfg.IRoutesContext``) as opposed to being looked up
arbitrarily, there is no need to decorate any context to ensure a
view is found.
- The Routes ``Route`` object used to resolve the match is now put
into the environment as ``bfg.route`` when URL dispatch is used.
|
|
|
|
``registerAdapter``, ``registerUtiity``, ``registerSubscriber``, and
``cleanUp``.
- Added glossary entry for "root factory".
|
|
|
|
|
|
|
|
|
|
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``.
|
|
|
|
|
|
to ``repoze.bfg.router.make_app`` became optional if any ``route``
declaration was made in ZCML. The intent was to make it possible to
disuse traversal entirely, instead relying entirely on URL dispatch
(Routes) to resolve all contexts. However a compound set of bugs
prevented usage of a Routes-based root view (a view which responds
to "/"). One bug existed in `repoze.bfg.urldispatch``, another
existed in Routes itself.
To resolve this issue, the urldispatch module was fixed, and a fork
of the Routes trunk was put into the "dev" index named
``Routes-1.11dev-chrism-home``. The source for the fork exists at
`http://bitbucket.org/chrism/routes-home/
<http://bitbucket.org/chrism/routes-home/>`_; its contents have been
reported to the upstream Routes developers and will hopefully be a
part of the final Routes 1.11 release.
|
|
|
|
|
|
|
|
--------
- Two new security policies were added:
RemoteUserInheritingACLSecurityPolicy and
WhoInheritingACLSecurityPolicy. These are security policies which
take into account *all* ACLs defined in the lineage of a context
rather than stopping at the first ACL found in a lineage. See the
"Security" chapter of the API documentation for more information.
- The API and narrative documentation dealing with security was
changed to introduce the new "inheriting" security policy variants.
- Added glossary entry for "lineage".
Deprecations
------------
- The security policy previously named
``RepozeWhoIdentityACLSecurityPolicy`` now has the slightly saner
name of ``WhoACLSecurityPolicy``. A deprecation warning is emitted
when this policy is imported under the "old" name; usually this is
due to its use in ZCML within your application. If you're getting
this deprecation warning, change your ZCML to use the new name,
e.g. change::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.RepozeWhoIdentityACLSecurityPolicy"
/>
To::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.WhoACLSecurityPolicy"
/>
|
|
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
application runtime. This allows us to get rid of ``zope.testing``
on platforms like GAE which have file limits.
|
|
|
|
|
|
package within the ``configure.zcml`` of the "repoze.bfg.includes"
package. This has been a no-op for some time now.
-The ``repoze.bfg.chameleon_zpt`` package no longer imports from
``chameleon.zpt`` at module scope, deferring the import until later
within a method call. The ``chameleon.zpt`` package can't be
imported on platforms like GAE.
|
|
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.
|
|
|
|
``repoze.bfg.traversal.model_path`` and
``repoze.bfg.traversal.model_path_tuple`` functions always ignored
the ``__name__`` argument of the root object in a model graph (
effectively replacing it with a leading ``/`` in the returned value)
when a path or URL was generated. The code required to perform this
operation was not efficient. As of this release, the root object in
a model graph *must* have a ``__name__`` attribute that is either
``None`` or the empty string (``''``) for URLs and paths to be
generated properly from these APIs. If your root model object has a
``__name__`` argument that is not one of these values, you will need
to change your code for URLs and paths to be generated properly. If
your model graph has a root node with a string ``__name__`` that is
not null, the value of ``__name__`` will be prepended to every path
and URL generated.
|
|
``repoze.bfg.location.ClassAndInstanceDescr`` class have both been
removed in order to be able to eventually shed a dependency on
``zope.proxy``. Neither of these classes was ever an API.
- In all previous releases, the ``repoze.bfg.location.locate``
function worked like so: if a model did not explicitly provide the
``repoze.bfg.interfaces.ILocation`` interface, ``locate`` returned a
``LocationProxy`` object representing ``model`` with its
``__parent__`` attribute assigned to ``parent`` and a ``__name__``
attribute assigned to ``__name__``. In this release, the
``repoze.bfg.location.locate`` function simply jams the ``__name__``
and ``__parent__`` attributes on to the supplied model
unconditionally, no matter if the object implements ILocation or
not, and it never returns a proxy. This was done because the
LocationProxy behavior has now moved into an add-on package
(``repoze.bfg.traversalwrapper``), in order to eventually be able to
shed a dependency on ``zope.proxy``.
- In all previous releases, by default, if traversal was used (as
opposed to URL-dispatch), and the root object supplied
the``repoze.bfg.interfaces.ILocation`` interface, but the children
returned via its ``__getitem__`` returned an object that did not
implement the same interface, :mod:`repoze.bfg` provided some
implicit help during traversal. This traversal feature wrapped
subobjects from the root (and thereafter) that did not implement
``ILocation`` in proxies which automatically provided them with a
``__name__`` and ``__parent__`` attribute based on the name being
traversed and the previous object traversed. This feature has now
been removed from the base ``repoze.bfg`` package for purposes of
eventually shedding a dependency on ``zope.proxy``.
In order to re-enable the wrapper behavior for older applications
which cannot be changed, register the "traversalwrapper"
``ModelGraphTraverser`` as the traversal policy, rather than the
default ``ModelGraphTraverser``. To use this feature, you will need
to install the ``repoze.bfg.traversalwrapper`` package (an add-on
package, available at
http://svn.repoze.org/repoze.bfg.traversalwrapper) Then change your
application's ``configure.zcml`` to include the following stanza:
<adapter
factory="repoze.bfg.traversalwrapper.ModelGraphTraverser"
provides="repoze.bfg.interfaces.ITraverserFactory"
for="*"
/>
When this ITraverserFactory is used instead of the default, no
object in the graph (even the root object) must supply a
``__name__`` or ``__parent__`` attribute. Even if subobjects
returned from the root *do* implement the ILocation interface,
these will still be wrapped in proxies that override the object's
"real" ``__parent__`` and ``__name__`` attributes.
See also changes to the "Models" chapter of the documentation (in
the "Location-Aware Model Instances") section.
|
|
and '_model_path_list' functions.
|
|
|
|
|
|
ILocation. Make WrappingModelGraphTraverser assume that *no* traversed objects provide ILocation. This makes it unnecessary to explain why the root object in a WrappingModelGraphTraverser setup needs to supply the ILocation interface. Now it doesn't.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
built-in implementations that implement the interface
(``repoze.bfg.traversal.ModelGraphTraverser``, and
``repoze.bfg.urldispatch.RoutesModelTraverser``) now expect the
``__call__`` method of an ITraverser to return 3 additional
arguments: ``traversed``, ``virtual_root``, and
``virtual_root_path`` (the old contract was that the ``__call__``
method of an ITraverser returned; three arguments, the contract new
is that it returns six). ``traversed`` will be a sequence of
Unicode names that were traversed (including the virtual root path,
if any) or ``None`` if no traversal was performed, ``virtual_root``
will be a model object representing the virtual root (or the
physical root if traversal was not performed), and
``virtual_root_path`` will be a sequence representing the virtual
root path (a sequence of Unicode names) or ``None`` if traversal was
not performed.
Six arguments are now returned from BFG ITraversers. They are
returned in this order: ``context``, ``view_name``, ``subpath``,
``traversed``, ``virtual_root``, and ``virtual_root_path``.
Places in the BFG code which called an ITraverser continue to accept
a 3-argument return value, although BFG will generate and log a
warning when one is encountered.
- The request object now has the following attributes: ``traversed``
(the sequence of names traversed or ``None`` if traversal was not
performed), ``virtual_root`` (the model object representing the
virtual root, including the virtual root path if any), and
``virtual_root_path`` (the seuquence of names representing the
virtual root path or ``None`` if traversal was not performed).
- A new decorator named ``wsgiapp2`` was added to the
``repoze.bfg.wsgi`` module. This decorator performs the same
function as ``repoze.bfg.wsgi.wsgiapp`` except it fixes up the
``SCRIPT_NAME``, and ``PATH_INFO`` environment values before
invoking the WSGI subapplication.
- The ``repoze.bfg.testing.DummyRequest`` object now has default
attributes for ``traversed``, ``virtual_root``, and
``virtual_root_path``.
- The RoutesModelTraverser now behaves more like the Routes
"RoutesMiddleware" object when an element in the match dict is named
``path_info`` (usually when there's a pattern like
``http://foo/*path_info``). When this is the case, the
``PATH_INFO`` environment variable is set to the value in the match
dict, and the ``SCRIPT_NAME`` is appended to with the prefix of the
original ``PATH_INFO`` not including the value of the new variable.
- The notfound debug now shows the traversed path, the virtual root,
and the virtual root path too.
|
|
|
|
``GET``, and ``POST`` attributes that are instances of the class
``FauxMultiDict``. A FauxMultiDict differs from a "plain"
dictionary inasmuch as it has a ``getall`` method. ``getall`` is an
interface exposed by the MultiDict implementation used by WebOb for
``params``, ``GET``, and ``POST``.
|
|
the request machinery will attempt to decode values from the utf-8
encoding to Unicode automatically when they are obtained via
``request.params``, ``request.GET``, and ``request.POST``. The
previous behavior of BFG was to return a bytestring when a value was
accessed in this manner. This change will break form handling code
in apps that rely on values from those APIs being considered
bytestrings. If you are manually decoding values from form
submissions in your application, you'll either need to change the
code that does that to expect Unicode values from
``request.params``, ``request.GET`` and ``request.POST``, or you'll
need to explicitly reenable the previous behavior. To reenable the
previous behavior, add the following to your application's
``configure.zcml``::
<subscriber for="repoze.bfg.interfaces.INewRequest"
handler="repoze.bfg.request.make_request_ascii"/>
See also the documentation in the "Views" chapter of the BFG docs
entitled "Using Views to Handle Form Submissions (Unicode and
Character Set Issues)".
|
|
|
|
was returned as an int rather than as a string.
|
|
So this updates the paster template tests so they pass again.
-----
r7827 | ianb | 2009-03-11 14:58:38 -0400 (Wed, 11 Mar 2009) | 1 line
Use Content-Type consistently (not content-type)
-----
|
|
|
|
some nondefault string representation.
|
|
(one with models that had a non-root model with a ``__name__`` of
``None``) caused an inscrutable error to be thrown: ( if not
``_must_quote[cachekey].search(s): TypeError: expected string or
buffer``). Now URLs and paths generated against graphs that have
None names in intermediate nodes will replace the None with the
empty string, and, as a result, the error won't be raised. Of
course the URL or path will still be bogus.
|
|
tried to redelete a key in the cache that had already been deleted.
Symptom: line 64 in put:del data[oldkey]:KeyError: '/some/path'.
Now we just ignore the key error if we can't delete the key.
- add zip_safe = false to setup.cfg.
|
