redirected to ``pyramid_zcml`` locations.
module. It continues life within the ``pyramid_zcml`` package. This leaves the ``pyramid.router`` module without any API functions. - The ``configure_zcml`` setting within the deployment settings (within ``**settings`` passed to a Pyramid ``main`` function) has ceased to have any meaning. - The ``starter_zcml`` paster template has been moved to the ``pyramid_zcml`` package. - The ``bfg2pyramid`` script now converts ZCML include tags that have ``repoze.bfg.includes`` as a package attribute to the value ``pyramid_zcml``. For example, ``<include package="repoze.bfg.includes">`` will be converted to ``<include package="pyramid_zcml">``. - The ``load_zcml`` method of a Configurator has been removed from the Pyramid core. Loading ZCML is now a feature of the ``pyramid_zcml`` package, which can be downloaded from PyPI. Documentation for the package should be available via http://pylonsproject.org, which describes how to get this method back after depending upon ``pyramid_zcml`` as an ``install_requires`` dependency. - The ``pyramid.includes`` subpackage has been removed. ZCML files which use include the package ``pyramid.includes`` (e.g. ``<include package="pyramid.includes">``) now must include the ``pyramid_zcml`` package instead (e.g. ``<include package="pyramid_zcml"/>). - The "Declarative Configuration" narrative chapter has been removed (it was moved to the ``pyramid_zcml`` pakcage). - The add_directive method now accepts an "action_wrap" flag. - Fix some orphaned references. - Remove some docstring references to ZCML directives. - All integration test fixtures have been changed to use imperative configuration rather than ZCML configuration.
templates were removed. Use ``pyramid_sqla`` (available from PyPI) as a generic replacement for Pylons-esque development. - All references to ``add_handler`` and the ``handler`` ZCML directive have been removed from the docs, and stubs which point to ``pylons_handlers`` package have replaced them.
…s from pyramid.view, handler ZCML directive. This functionality is to be moved to a "pyramid_handlers" package. Fix add_directive to properly persist directives across configurator creations.
defaults to attempting to find and use a callable named ``includeme`` within that module. This makes it possible to use ``config.include('some.module')`` rather than ``config.include('some.module.somefunc')`` as long as the include function within ``some.module`` is named ``includeme``.
extenders to add methods to the configurator (ala ZCML directives).
when used inside brackets. Resolve Issue #90.
…ns were added: ``pyramid.traversal.find_model``, ``pyramid.traversal.model_path``, ``pyramid.traversal.model_path_tuple``, ``pyramid.url.model_url``. The instructions emitted by the deprecation warnings instruct the developer to change these method spellings to their ``resource`` equivalents. This is a consequence of the mass concept rename of "model" to "resource" performed in 1.0a7.
…rative "Renderers" chapter in a section named "Overriding A Renderer at Runtime".
-------- - ``pyramid.testing.setUp`` and ``pyramid.testing.tearDown`` have been undeprecated. They are now the canonical setup and teardown APIs for test configuration, replacing "direct" creation of a Configurator. This is a change designed to provide a facade that will protect against any future Configurator deprecations. Paster Templates ---------------- - All paster templates now use ``pyramid.testing.setUp`` and ``pyramid.testing.tearDown`` rather than creating a Configurator "by hand" within their ``tests.py`` module, as per decision in features above. Documentation ------------- - The wiki and wiki2 tutorials now use ``pyramid.testing.setUp`` and ``pyramid.testing.tearDown`` rather than creating a Configurator "by hand", as per decision in features above. - The "Testing" narrative chapter now explains ``pyramid.testing.setUp`` and ``pyramid.testing.tearDown`` instead of Configurator creation and ``Configurator.begin()`` and ``Configurator.end()``.
implementation should return a *new* token if one doesn't already exist in the session (previously it would return None). The internal sessioning implementation has been changed.
``pyramid.traversal.resource_path_tuple`` for backwards compatibility.
object, which is mostly a dictionary, but also implements the other session API methods for flash and CSRF.
…RL based on the "current" route (if any) and its matchdict values.
…idden at request time via a request attribute named ``override_renderer``, which should be the name of a registered renderer. Useful to provide "omnipresent" RPC for existing views. - Convert ``add_view_mapper`` to ``set_view_mapper``. There will only be a single default view mapper. We no longer register named utilities for view mappers to provide alternates. - Previoulsy the ``view_mapper`` argument was required to be the *name* of an existing registered view mapper. We no longer register named utilities for view mappers, so now if an extension wants to override the view mapper used for a particular view registration, it can use the dotted name to a view mapper class or provide that class as ``view_mapper``.
…to add a named implementation of a ``pyramid.interfaces.IViewMapperFactory`` interface. Its name can be passed as a ``view_mapper`` argument to ``config.add_view``. A view mapper allows objects that are meant to be used as view callables to have an arbitrary argument list and an arbitrary result. This feature will be used by Pyramid extension developers, not by "civilians". - New constructor argument to Configurator: ``default_view_mapper``. Useful to create systems that have view callables with alternate default calling conventions. - ``view_mapper`` argument to ``add_view`` should now be a view mapper *name* rather than an implementation. - Add ``view_mapper`` argument to ``view_config`` decorator constructor. - Remove (non-API) function of config.py named _map_view. - Fix docstring for ``decorator`` argument to add_view. - Factor invocation of view mapper into a viewderiver method. - Promote view rendering and decorating into viewderiver, out of view mapper. - Make requestonly into a function rather than a method of the default view mapper.
…API. This class can be used by third-party authentication policy developers to help in the mechanics of authentication cookie-setting.
…ifies an ``unauthenticated_userid`` method. This method supports an important optimization required by people who are using persistent storages which do not support object caching and whom want to create a "user object" as a request attribute. - A new API has been added to the ``pyramid.security`` module named ``unauthenticated_userid``. This API function calls the ``unauthenticated_userid`` method of the effective security policy. - An ``unauthenticated_userid`` method has been added to the dummy authentication policy returned by ``pyramid.config.Configurator.testing_securitypolicy``. It returns the same thing as that the dummy authentication policy's ``authenticated_userid`` method. - Since the ``pyramid.interfaces.IAuthenticationPolicy`` interface now specifies that a policy implementation must implement an ``unauthenticated_userid`` method, all third-party custom authentication policies now must implement this method. It, however, will only be called when the global function named ``pyramid.security.unauthenticated_userid`` is invoked, so if you're not invoking that, you will not notice any issues. - The (non-API) method of all internal authentication policy implementations previously named ``_get_userid`` is now named ``unauthenticated_userid``, promoted to an API method. If you were overriding this method, you'll now need to override it as ``unauthenticated_userid`` instead.
``__original_view__`` attribute which references the original view callable (or class).
…ther than a large number of standalone functions (a side effect of the ``view_mapper`` refactoring). - The ``pyramid.renderer.RendererHelper`` class has grown a ``render_view`` method, which is used by the default view mapper (a side effect of the ``view_mapper`` refactoring). - The object passed as ``renderer`` to the "view deriver" is now an instance of ``pyramid.renderers.RendererHelper`` rather than a dictionary (a side effect of ``view_mapper`` refactoring).