| Age | Commit message (Collapse) | Author |
|---|
|
``pyramid.view.view_config`` API docs by pointing to
``pyramid.config.add_view`` documentation and narrative chapter
documentation.
|
|
|
|
|
|
|
|
|
|
implementations existed: one in ``pyramid.config`` and one in
``pyramid.view``. Now the one defined in ``pyramid.view`` is used
internally by ``pyramid.config`` and continues to be advertised as an API.
Closes #114.
|
|
templates (retry ZODB conflict errors which occur in normal operations).
|
|
|
|
|
|
|
|
|
|
``registerDummySecurityPolicy``, ``registerResources``, ``registerModels``,
``registerEventListener``, ``registerTemplateRenderer``,
``registerDummyRenderer``, ``registerView``, ``registerUtility``,
``registerAdapter``, ``registerSubscriber``, ``registerRoute``,
and ``registerSettings``.
- Deprecated-since-BFG-1.2 APIs from ``pyramid.testing`` now properly emit
deprecation warnings.
|
|
|
|
|
|
older version of sphinx which doesnt respect tab-width)
|
|
|
|
mention that default permissions also protect exception views.
|
|
parameters across redirects.
|
|
templates for the benefit of folks who cutnpaste and save to a non-UTF8
format.
|
|
|
|
would break any usage of an AuthTktAuthenticationPolicy when an auth tkt
authentication policy was configured to reissue its tokens
(``reissue_time`` < ``timeout`` / ``max_age``). Symptom: ``ValueError:
('Invalid token %r', '')``. See
https://github.com/Pylons/pyramid/issues#issue/108.
|
|
|
|
an incorrect value into the renderer for ``renderer_info``. It now passes
an instance of ``RendererHelper`` instead of a dictionary, which is
consistent with other usages. See
https://github.com/Pylons/pyramid/issues#issue/106
Closes #106
|
|
effective logging level of WARN, which prevents e.g. SQLAlchemy statement
logging and other inappropriate output.
- The ``production.ini`` of the ``pyramid_routesalchemy`` and
``pyramid_alchemy`` paster templates did not have a ``sqlalchemy`` logger
section, preventing ``paster serve production.ini`` from working.
- The ``pyramid_routesalchemy`` and ``pyramid_alchemy`` paster templates used
the ``{{package}}`` variable in a place where it should have used the
``{{project}}`` variable, causing applications created with uppercase
letters e.g. ``paster create -t pyramid_routesalchemy Dibbus`` to fail to
start when ``paster serve development.ini`` was used against the result.
See https://github.com/Pylons/pyramid/issues/#issue/107
Closes #107
|
|
|
|
https://github.com/Pylons/pyramid/issues#issue/95
Closes issue #95.
|
|
|
|
when it's passed a registry without any settings and when it creates one).
- The ``testing.setUp`` function now takes a ``settings`` argument, which
should be a dictionary. Its values will subsequently be available on the
returned ``config`` object as ``config.registry.settings``.
|
|
mmerickel-wild_domains
|
|
|
|
|
|
|
|
for the application package logger
Closes #94
|
|
(a backwards compatibility shim) now issues a deprecation warning.
|
|
paster templates now use a default "commit veto" hook when configuring the
``repoze.tm2`` transaction manager in ``development.ini``. This prevents a
transaction from being committed when the response status code is within
the 400 or 500 ranges. See also
http://docs.repoze.org/tm2/#using-a-commit-veto.
|
|
``pyramid.session.UnencyrptedCookieSessionFactory`` is now ``True``. This
means that when view code causes an exception to be raised, and the session
has been mutated, a cookie will be sent back in the response. Previously
its default value was ``False``.
|
|
|
|
|
|
|
|
|
|
|
|
now ``403 Forbidden``. It was previously ``401 Unauthorized``, for
backwards compatibility purposes with ``repoze.bfg``. This change will
cause problems for users of Pyramid with ``repoze.who``, which intercepts
``401 Unauthorized`` by default, but allows ``403 Forbidden`` to pass
through. Those deployments will need to configure ``repoze.who`` to also
react to ``403 Forbidden``.
|
|
|
|
|
|
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.
|
|
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``.
|
|
|
