Pyramid

Latest version: v2.0.2

Safety actively analyzes 685838 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 21 of 30

0.8a7

==================

Backwards Incompatibilities
---------------------------

- The ``RoutesMapper`` class in ``repoze.bfg.urldispatch`` has been
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.

Documentation
-------------

- Added API docs for the ``repoze.bfg.testing`` methods
``registerAdapter``, ``registerUtiity``, ``registerSubscriber``, and
``cleanUp``.

- Added glossary entry for "root factory".

- Noted existence of ``repoze.bfg.pagetemplate`` template bindings in
"Available Add On Template System Bindings" in Templates chapter in
narrative docs.

- Update "Templates" narrative chapter in docs (expand to show a
sample template and correct macro example).

Features
--------

- Courtesty Carlos de la Guardia, added an ``alchemy`` Paster
template. This paster template sets up a BFG project that uses
SQAlchemy (with SQLite) and uses traversal to resolve URLs. (no
Routes areused). This template can be used via ``paster create -t
bfg_alchemy``.

- The Routes ``Route`` object used to resolve the match is now put
into the environment as ``bfg.route`` when URL dispatch is used.

- You can now change the default Routes "context factory" globally.
See the "ZCML Hooks" chapter of the documentation (in the "Changing
the Default Routes Context Factory" section).

0.8a6

==================

Features
--------

- Added a ``routesalchemy`` Paster template. This paster template
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``.

Documentation
-------------

- Added documentation to the URL Dispatch chapter about how to catch
the root URL using a ZCML ``route`` directive.

- Added documentation to the URL Dispatch chapter about how to perform
a cleanup function at the end of a request (e.g. close the SQL
connection).

Bug Fixes
---------

- In version 0.6.3, passing a ``get_root`` callback (a "root factory")
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/`` (broken link);
its contents have been merged into the Routes trunk
(what will be Routes 1.11).

0.8a5

==================

Features
--------

- 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"
/>

0.8a4

==================

Features
--------

- ``zope.testing`` is no longer a direct dependency, although our
dependencies (such as ``zope.interface``, ``repoze.zcml``, etc)
still depend on it.

- Tested on Google App Engine. Added a tutorial to the documentation
explaining how to deploy a BFG app to GAE.

Backwards Incompatibilities
---------------------------

- Applications which rely on ``zope.testing.cleanup.cleanUp`` in unit
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.

0.8a3

===================

Features
--------

- Don't require a successful import of ``zope.testing`` at BFG
application runtime. This allows us to get rid of ``zope.testing``
on platforms like GAE which have file limits.

0.8a2

==================

Features
--------

- We no longer include the ``configure.zcml`` of the ``chameleon.zpt``
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.

Page 21 of 30

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.