| 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.
|
|
|
|
|
|
|
|
|
|
sample template and correct macro example).
|
|
|
|
|
|
|
|
"Available Add On Template System Bindings" in Templates chapter in
narrative docs.
- Noted existence of ``alchemy`` paster template.
|
|
|
|
``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``.
|
|
|
|
a cleanup function at the end of a request (e.g. close the SQL
connection).
|
|
|
|
|
|
the root URL.
|
|
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"
/>
|
|
|
|
|
|
|
|
|
|
|
|
tests can still use that function indefinitely. However, for
maximum forward compatibility, they should import ``cleanUp`` from
``repoze.bfg.testing`` instead of from ``zope.testing.cleanup``.
The BFG paster templates and docs have been changed to use this
function instead of the ``zope.testing.cleanup`` version.
|
|
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
|
