| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- Added a summary of the steps
- Fixed a couple of typos
|
|
Clarify two steps in the SQL wiki tutorial
|
|
highlighted it.
|
|
- Highlight the added or changed lines
|
|
|
|
models.py.
|
|
Added links to 'Starting the Application'
|
|
|
|
- Sections 'Viewing the Application in a Browser' in the
'Defining the Domain Model' and 'Defining the Views'
chapters now offer a quick link in both wiki tutorials,
as suggested by Paulo.
|
|
|
|
wrapper for ``pyramid.Config.configurator.add_view`` which does the right
thing about permissions. It should be preferred over calling ``add_view``
directly with ``context=HTTPForbidden`` as was previously recommended.
- New API: ``pyramid.view.forbidden_view_config``. This is a decorator
constructor like ``pyramid.view.view_config`` that calls
``pyramid.config.Configurator.add_forbidden_view`` when scanned. It should
be preferred over using ``pyramid.view.view_config`` with
``context=HTTPForbidden`` as was previously recommended.
- Updated the "Creating a Not Forbidden View" section of the "Hooks" chapter,
replacing explanations of registering a view using ``add_view`` or
``view_config`` with ones using ``add_forbidden_view`` or
``forbidden_view_config``.
- Updated all tutorials to use ``pyramid.view.forbidden_view_config`` rather
than ``pyramid.view.view_config`` with an HTTPForbidden context.
|
|
lines in order to be able to tell people to comment out only the
``pyramid_debugtoolbar`` line when they want to disable the toolbar.
|
|
``DBSession`` instead (this is more common in real SQLA apps).
|
|
|
|
issue #398)
|
|
|
|
|
|
|
|
|
|
|
|
``@view_config`` decorators and an explicit database population script.
Closes #359.
|
|
rendering; emit logging statements when populate is run
|
|
- The ``routesalchemy`` scaffold has been renamed ``alchemy``.
|
|
|
|
Previously it was: test, start, coverage, view.
|
|
|
|
added a hide toc for glossary to prevent warnings
|
|
|
|
replicable on my own
|
|
|
|
|
|
and narrative docs.
- Break out awkward description of PasteDeploy entry points from
project chapter into its own Paste chapter.
|
|
|
|
``resource_url``, ``static_url``, and ``current_route_url`` methods of the
request rather than the function variants imported from ``pyramid.url``.
|
|
package at all; configuration in the ``production.ini`` file which used to
require its ``error_catcher`` middleware has been removed. Configuring
error catching / email sending is now the domain of the ``pyramid_exclog``
package (see https://docs.pylonsproject.org/projects/pyramid_exclog/dev/).
|
|
|
|
|
|
|
|
use ``/projects/pyramid/current`` rather than ``/projects/pyramid/dev``.
|
|
|
|
inappropriately used ``DBSession.rollback()`` instead of
``transaction.abort()`` in one place.
- Wiki2 (SQLAlchemy + URL Dispatch) tutorial ``models.initialize_sql`` didn't
match the ``pyramid_routesalchemy`` scaffold function of the same name; it
didn't get synchronized when it was changed in the scaffold.
|
|
|
|
|
|
|
|
to depend on WebTest, and 2 tests failed as the result of changes to
Pyramid itself. These issues have been fixed.
|
|
|
|
abstraction.
- It is now possible to return an arbitrary object from a Pyramid view
callable even if a renderer is not used, as long as a suitable adapter to
``pyramid.interfaces.IResponse`` is registered for the type of the returned
object. See the section in the Hooks chapter of the documentation entitled
"Changing How Pyramid Treats View Responses".
- The Pyramid router now, by default, expects response objects returned from
view callables to implement the ``pyramid.interfaces.IResponse`` interface.
Unlike the Pyramid 1.0 version of this interface, objects which implement
IResponse now must define a ``__call__`` method that accepts ``environ``
and ``start_response``, and which returns an ``app_iter`` iterable, among
other things. Previously, it was possible to return any object which had
the three WebOb ``app_iter``, ``headerlist``, and ``status`` attributes as
a response, so this is a backwards incompatibility. It is possible to get
backwards compatibility back by registering an adapter to IResponse from
the type of object you're now returning from view callables. See the
section in the Hooks chapter of the documentation entitled "Changing How
Pyramid Treats View Responses".
- The ``pyramid.interfaces.IResponse`` interface is now much more extensive.
Previously it defined only ``app_iter``, ``status`` and ``headerlist``; now
it is basically intended to directly mirror the ``webob.Response`` API,
which has many methods and attributes.
- Documentation changes to support above.
|
|
method which implements the WSGI application interface
instead of the three webob attrs status, headerlist
and app_iter. Backwards compatibility exists for
code which returns response objects that do not
have a __call__.
- pyramid.response.Response is no longer an exception
(and therefore cannot be raised in order to generate
a response).
- Changed my mind about moving stuff from pyramid.httpexceptions
to pyramid.response. The stuff I moved over has been moved
back to pyramid.httpexceptions.
|
|
|
