| Age | Commit message (Collapse) | Author |
|---|
|
- Most are changing http to https, or readthedocs.org to readthedocs.io,
and some for Python packaging reorganizing some docs into tutorials,
as well as miscellaneous changes.
|
|
|
|
SPHINXBUILD=$VENV/bin/sphinx-build`, but don't bother with HISTORY.txt or whatsnew-xx
|
|
errors. See https://github.com/sphinx-doc/sphinx/issues/2264
|
|
mah intersphinx on yo!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from most-important-concept-to-least
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
pyramid.response
|
|
interface API documentation.
|
|
``route_path``, ``route_url``, and ``static_url`` methods to
``pyramid.request.Request`` API docs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to :app:`Pyramid`. A custom role setting was added to ``docs/conf.py`` to
allow for this. (internal)
|
|
that it is imported from pyramid. API docs can mention its inheritance from
webob (aka "Provide a webob.Response class facade for forward compat").
|
|
|
|
|
|
|
|
|
|
|
|
-------------
- Add an API chapter for the ``repoze.bfg.request`` module, which
includes documentation for the ``repoze.bfg.request.Request`` class
(the "request object").
- Modify the "Request and Response" narrative chapter to reference the
new ``repoze.bfg.request`` API chapter. Some content was moved from
this chapter into the API documentation itself.
Features
--------
- A new ``repoze.bfg.request.Request.add_response_callback`` API has
been added. This method is documented in the new
``repoze.bfg.request`` API chapter. It can be used to influence
response values before a concrete response object has been created.
Internal
--------
- The (internal) feature which made it possible to attach a
``global_response_headers`` attribute to the request (which was
assumed to contain a sequence of header key/value pairs which would
later be added to the response by the router), has been removed.
The functionality of
``repoze.bfg.request.Request.add_response_callback`` takes its
place.
|
|
|
|
---------
- When the ``Configurator`` is passed an instance of
``zope.component.registry.Components`` as a ``registry`` constructor
argument, fix the instance up to have the attributes we expect of an
instance of ``repoze.bfg.registry.Registry`` when ``setup_registry``
is called. This makes it possible to use the global Zope component
registry as a BFG application registry.
Documentation
-------------
- Change renderings of ZCML directive documentation.
- Add a narrative documentation chapter: "Using the Zope Component
Architecture in ``repoze.bfg``"
|
|
Merge a bunch of paper-based docs fixes
Configure logging during bfgshell.
|
|
|
|
code.
|
|
|
|
|
|
|
