From aa7b06b946b4e8e66818da29e64e9cbccb6ccb10 Mon Sep 17 00:00:00 2001
From: Chris McDonough <chrism@plope.com>
Date: Mon, 2 Sep 2013 01:03:02 -0400
Subject: move docs section to a more appropriate place

---
 docs/narr/viewconfig.rst | 59 ++++++++++++++++++++++++------------------------
 1 file changed, 30 insertions(+), 29 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index e09fd83ab..76cf1daac 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -465,6 +465,36 @@ configured view.
 
   .. versionadded:: 1.4a1
 
+Inverting Predicate Values
+++++++++++++++++++++++++++
+
+You can invert the meaning of any predicate value by wrapping it in a call to
+:class:`pyramid.config.not_`.
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.config import not_
+
+   config.add_view(
+       'mypackage.views.my_view',
+       route_name='ok',
+       request_method=not_('POST')
+       )
+
+The above example will ensure that the view is called if the request method
+is *not* ``POST``, at least if no other view is more specific.
+
+This technique of wrapping a predicate value in ``not_`` can be used anywhere
+predicate values are accepted:
+
+- :meth:`pyramid.config.Configurator.add_view`
+
+- :meth:`pyramid.view.view_config`
+
+.. versionadded:: 1.5
+
+
 .. index::
    single: view_config decorator
 
@@ -557,35 +587,6 @@ form of :term:`declarative configuration`, while
 :meth:`pyramid.config.Configurator.add_view` is a form of :term:`imperative
 configuration`.  However, they both do the same thing.
 
-Inverting Predicate Values
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can invert the meaning of any predicate value by wrapping it in a call to
-:class:`pyramid.config.not_`.
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.config import not_
-
-   config.add_view(
-       'mypackage.views.my_view',
-       route_name='ok',
-       request_method=not_('POST')
-       )
-
-The above example will ensure that the view is called if the request method
-is *not* ``POST``, at least if no other view is more specific.
-
-This technique of wrapping a predicate value in ``not_`` can be used anywhere
-predicate values are accepted:
-
-- :meth:`pyramid.config.Configurator.add_view`
-
-- :meth:`pyramid.view.view_config`
-
-.. versionadded:: 1.5
-
 .. index::
    single: view_config placement
 
-- 
cgit v1.2.3


From 6ca99b5b42ca13a25a22474c927733d2d16d7cbe Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Wed, 4 Sep 2013 23:32:43 -0500
Subject: remove some mako/chameleon renderer docs

---
 docs/narr/renderers.rst | 179 ++++++------------------------------------------
 1 file changed, 21 insertions(+), 158 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index a2811dbae..212832474 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -365,136 +365,6 @@ The same custom-object serialization scheme defined used for a "normal" JSON
 renderer in :ref:`json_serializing_custom_objects` can be used when passing
 values to a JSONP renderer too.
 
-.. index::
-   pair: renderer; chameleon
-
-.. _chameleon_template_renderers:
-
-``*.pt`` or ``*.txt``: Chameleon Template Renderers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Two built-in renderers exist for :term:`Chameleon` templates.
-
-If the ``renderer`` attribute of a view configuration is an absolute path, a
-relative path or :term:`asset specification` which has a final path element
-with a filename extension of ``.pt``, the Chameleon ZPT renderer is used.
-See :ref:`chameleon_zpt_templates` for more information about ZPT templates.
-
-If the ``renderer`` attribute of a view configuration is an absolute path or
-a :term:`asset specification` which has a final path element with a filename
-extension of ``.txt``, the :term:`Chameleon` text renderer is used.  See
-:ref:`chameleon_text_templates` for more information about Chameleon text
-templates.
-
-The behavior of these renderers is the same, except for the engine
-used to render the template.
-
-When a ``renderer`` attribute that names a template path or :term:`asset
-specification` (e.g. ``myproject:templates/foo.pt`` or
-``myproject:templates/foo.txt``) is used, the view must return a
-:term:`Response` object or a Python *dictionary*.  If the view callable with
-an associated template returns a Python dictionary, the named template will
-be passed the dictionary as its keyword arguments, and the template renderer
-implementation will return the resulting rendered template in a response to
-the user.  If the view callable returns anything but a Response object or a
-dictionary, an error will be raised.
-
-Before passing keywords to the template, the keyword arguments derived from
-the dictionary returned by the view are augmented.  The callable object --
-whatever object was used to define the view -- will be automatically inserted
-into the set of keyword arguments passed to the template as the ``view``
-keyword.  If the view callable was a class, the ``view`` keyword will be an
-instance of that class.  Also inserted into the keywords passed to the
-template are ``renderer_name`` (the string used in the ``renderer`` attribute
-of the directive), ``renderer_info`` (an object containing renderer-related
-information), ``context`` (the context resource of the view used to render
-the template), and ``request`` (the request passed to the view used to render
-the template).  ``request`` is also available as ``req`` in Pyramid 1.3+.
-
-Here's an example view configuration which uses a Chameleon ZPT renderer:
-
-.. code-block:: python
-   :linenos:
-
-    # config is an instance of pyramid.config.Configurator
-
-    config.add_view('myproject.views.hello_world',
-                    name='hello',
-                    context='myproject.resources.Hello',
-                    renderer='myproject:templates/foo.pt')
-
-Here's an example view configuration which uses a Chameleon text renderer:
-
-.. code-block:: python
-   :linenos:
-
-    config.add_view('myproject.views.hello_world',
-                    name='hello',
-                    context='myproject.resources.Hello',
-                    renderer='myproject:templates/foo.txt')
-
-Views which use a Chameleon renderer can vary response attributes by using
-the API of the ``request.response`` attribute.  See
-:ref:`request_response_attr`.
-
-.. index::
-   pair: renderer; mako
-
-.. _mako_template_renderers:
-
-``*.mak`` or ``*.mako``: Mako Template Renderer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The ``Mako`` template renderer renders views using a Mako template.  When
-used, the view must return a Response object or a Python *dictionary*.  The
-dictionary items will then be used in the global template space. If the view
-callable returns anything but a Response object or a dictionary, an error
-will be raised.
-
-When using a ``renderer`` argument to a :term:`view configuration` to specify
-a Mako template, the value of the ``renderer`` may be a path relative to the
-``mako.directories`` setting (e.g.  ``some/template.mak``) or, alternately,
-it may be a :term:`asset specification`
-(e.g. ``apackage:templates/sometemplate.mak``).  Mako templates may
-internally inherit other Mako templates using a relative filename or a
-:term:`asset specification` as desired.
-
-Here's an example view configuration which uses a relative path:
-
-.. code-block:: python
-   :linenos:
-
-    # config is an instance of pyramid.config.Configurator
-
-    config.add_view('myproject.views.hello_world',
-                    name='hello',
-                    context='myproject.resources.Hello',
-                    renderer='foo.mak')
-
-It's important to note that in Mako's case, the 'relative' path name
-``foo.mak`` above is not relative to the package, but is relative to the
-directory (or directories) configured for Mako via the ``mako.directories``
-configuration file setting.
-
-The renderer can also be provided in :term:`asset specification`
-format. Here's an example view configuration which uses one:
-
-.. code-block:: python
-   :linenos:
-
-    config.add_view('myproject.views.hello_world',
-                    name='hello',
-                    context='myproject.resources.Hello',
-                    renderer='mypackage:templates/foo.mak')
-
-The above configuration will use the file named ``foo.mak`` in the
-``templates`` directory of the ``mypackage`` package.
-
-The ``Mako`` template renderer can take additional arguments beyond the
-standard ``pyramid.reload_templates`` setting, see the
-:ref:`environment_chapter` for additional
-:ref:`mako_template_renderer_settings`.
-
 .. index::
    single: response headers (from a renderer)
    single: renderer response headers
@@ -739,44 +609,37 @@ ending with ``.jinja2`` in its ``renderer`` value.  The ``name`` passed
 to the ``MyJinja2Renderer`` constructor will be the full value that was
 set as ``renderer=`` in the view configuration.
 
-.. index::
-   pair: renderer; changing
+Adding a Default Renderer
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Changing an Existing Renderer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can associate more than one filename extension with the same existing
-renderer implementation as necessary if you need to use a different file
-extension for the same kinds of templates.  For example, to associate the
-``.zpt`` extension with the Chameleon ZPT renderer factory, use the
-:meth:`pyramid.config.Configurator.add_renderer` method:
+To associate a *default* renderer with *all* view configurations (even
+ones which do not possess a ``renderer`` attribute), pass ``None`` as
+the ``name`` attribute to the renderer tag:
 
 .. code-block:: python
 
-   config.add_renderer('.zpt', 'pyramid.chameleon_zpt.renderer_factory')
-
-After you do this, :app:`Pyramid` will treat templates ending in both the
-``.pt`` and ``.zpt`` filename extensions as Chameleon ZPT templates.
-
-To change the default mapping in which files with a ``.pt`` extension are
-rendered via a Chameleon ZPT page template renderer, use a variation on the
-following in your application's startup code:
-
-.. code-block:: python
+   config.add_renderer(None, 'mypackage.json_renderer_factory')
 
-   config.add_renderer('.pt', 'mypackage.pt_renderer')
+.. index::
+   pair: renderer; changing
 
-After you do this, the :term:`renderer factory` in
-``mypackage.pt_renderer`` will be used to render templates which end
-in ``.pt``, replacing the default Chameleon ZPT renderer.
+Changing an Existing Renderer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To associate a *default* renderer with *all* view configurations (even
-ones which do not possess a ``renderer`` attribute), pass ``None`` as
-the ``name`` attribute to the renderer tag:
+Pyramid supports overriding almost every aspect of its setup through its
+:ref:`Conflict Resolution <automatic_conflict_resolution>` mechanism. This
+means that in most cases overriding a renderer is as simple as using the
+:meth:`pyramid.config.Configurator.add_renderer` method to re-define the
+template extension. For example, if we'd like to override the ``json``
+extension to specify a new renderer we could do the following:
 
 .. code-block:: python
 
-   config.add_renderer(None, 'mypackage.json_renderer_factory')
+   json_renderer = pyramid.renderers.JSON()
+   config.add_renderer('json', json_renderer)
+
+After you do this, any views registered with the ``json`` renderer will use
+the new renderer.
 
 .. index::
    pair: renderer; overriding at runtime
-- 
cgit v1.2.3


From b56a6ee9c0c58992df67cdeb021f69d51bcfd26d Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Wed, 4 Sep 2013 23:36:01 -0500
Subject: change focus from we to you

---
 docs/narr/renderers.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 212832474..bc96f3d7b 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -630,15 +630,15 @@ Pyramid supports overriding almost every aspect of its setup through its
 :ref:`Conflict Resolution <automatic_conflict_resolution>` mechanism. This
 means that in most cases overriding a renderer is as simple as using the
 :meth:`pyramid.config.Configurator.add_renderer` method to re-define the
-template extension. For example, if we'd like to override the ``json``
-extension to specify a new renderer we could do the following:
+template extension. For example, if you would like to override the ``.txt``
+extension to specify a new renderer you could do the following:
 
 .. code-block:: python
 
    json_renderer = pyramid.renderers.JSON()
    config.add_renderer('json', json_renderer)
 
-After you do this, any views registered with the ``json`` renderer will use
+After doing this, any views registered with the ``json`` renderer will use
 the new renderer.
 
 .. index::
-- 
cgit v1.2.3


From 004d847fe87424f187a920086cb8b9baa8b41b42 Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 00:02:51 -0500
Subject: more chameleon builtin references

---
 docs/narr/renderers.rst | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index bc96f3d7b..dd67c779c 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -67,9 +67,8 @@ When this configuration is added to an application, the
 ``myproject.views.my_view`` view callable will now use a ``json`` renderer,
 which renders view return values to a :term:`JSON` response serialization.
 
-Other built-in renderers include renderers which use the :term:`Chameleon`
-templating language to render a dictionary to a response.  Additional
-renderers can be added by developers to the system as necessary.
+Pyramid defines several :ref:`built_in_renderers`, and additional renderers
+can be added by developers to the system as necessary.
 See :ref:`adding_and_overriding_renderers`.
 
 Views which use a renderer and return a non-Response value can vary non-body
-- 
cgit v1.2.3


From 6f2d0468856b2a3ca84cb22c379196298b2399ea Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 00:35:41 -0500
Subject: add a section mentioning external template bindings

---
 docs/narr/renderers.rst | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index dd67c779c..21c59c06a 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -364,6 +364,31 @@ The same custom-object serialization scheme defined used for a "normal" JSON
 renderer in :ref:`json_serializing_custom_objects` can be used when passing
 values to a JSONP renderer too.
 
+Available Add-On Template System Bindings
+-----------------------------------------
+
+The Pylons Project maintains several packages providing bindings to different
+templating languages including the following:
+
++------------------------------+------------------------------+
+| Template Language            | Pyramid Bindings             |
++==============================+==============================+
+| Chameleon_                   | pyramid_chameleon_           |
++------------------------------+------------------------------+
+| Jinja2_                      | pyramid_jinja2_              |
++------------------------------+------------------------------+
+| Mako_                        | pyramid_mako_                |
++------------------------------+------------------------------+
+
+.. _Chameleon: http://chameleon.readthedocs.org/en/latest/
+.. _pyramid_chameleon: https://pypi.python.org/pypi/pyramid_chameleon
+
+.. _Jinja2: http://jinja.pocoo.org/docs/
+.. _pyramid_jinja2: https://pypi.python.org/pypi/pyramid_jinja2
+
+.. _Mako: http://www.makotemplates.org/
+.. _pyramid_mako: https://pypi.python.org/pypi/pyramid_mako
+
 .. index::
    single: response headers (from a renderer)
    single: renderer response headers
-- 
cgit v1.2.3


From f6f1d1685f09f1ecd3717c90e687a6e3652b4fdc Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 02:32:41 -0500
Subject: remove the deprecated request.response_* attributes

---
 docs/narr/renderers.rst | 34 ----------------------------------
 1 file changed, 34 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index a2811dbae..9132606b3 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -556,40 +556,6 @@ For more information on attributes of the request, see the API documentation
 in :ref:`request_module`.  For more information on the API of
 ``request.response``, see :attr:`pyramid.request.Request.response`.
 
-.. _response_prefixed_attrs:
-
-Deprecated Mechanism to Vary Attributes of Rendered Responses
--------------------------------------------------------------
-
-In previous releases of Pyramid (1.0 and before), the ``request.response``
-attribute did not exist.  Instead, Pyramid required users to set special
-``response_`` -prefixed attributes of the request to influence response
-behavior.  As of Pyramid 1.1, those request attributes are deprecated and
-their use will cause a deprecation warning to be issued when used.  Until
-their existence is removed completely, we document them below, for benefit of
-people with older code bases.
-
-``response_content_type``
-  Defines the content-type of the resulting response,
-  e.g. ``text/xml``.
-
-``response_headerlist``
-  A sequence of tuples describing header values that should be set in the
-  response, e.g. ``[('Set-Cookie', 'abc=123'), ('X-My-Header', 'foo')]``.
-
-``response_status``
-  A WSGI-style status code (e.g. ``200 OK``) describing the status of the
-  response.
-
-``response_charset``
-  The character set (e.g. ``UTF-8``) of the response.
-
-``response_cache_for``
-  A value in seconds which will influence ``Cache-Control`` and ``Expires``
-  headers in the returned response.  The same can also be achieved by
-  returning various values in the ``response_headerlist``, this is purely a
-  convenience.
-
 .. _adding_and_overriding_renderers:
 
 Adding and Changing Renderers
-- 
cgit v1.2.3


From bc0a26ac2b75de362a4bf8142b3385788f318f47 Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 02:50:15 -0500
Subject: add index for custom template engines

---
 docs/narr/renderers.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 21c59c06a..8de3cd29d 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -364,6 +364,14 @@ The same custom-object serialization scheme defined used for a "normal" JSON
 renderer in :ref:`json_serializing_custom_objects` can be used when passing
 values to a JSONP renderer too.
 
+.. index::
+   single: template system bindings
+   single: Chameleon
+   single: Jinja2
+   single: Mako
+
+.. _available_template_system_bindings:
+
 Available Add-On Template System Bindings
 -----------------------------------------
 
-- 
cgit v1.2.3


From a50494f22bc0e4ee1e2546a192e5a60b0ff46aa3 Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 22:46:40 -0500
Subject: remove chameleon and mako template-specific documentation

---
 docs/narr/templates.rst | 337 +-----------------------------------------------
 1 file changed, 1 insertion(+), 336 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 26bb6b6cd..24973f253 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -8,10 +8,6 @@ dynamic data provided by a :term:`view`.  :app:`Pyramid` offers a
 number of ways to perform templating tasks out of the box, and
 provides add-on templating support through a set of bindings packages.
 
-Out of the box, :app:`Pyramid` provides templating via the :term:`Chameleon`
-and :term:`Mako` templating libraries. :term:`Chameleon` provides support for
-two different types of templates: :term:`ZPT` templates, and text templates.
-
 Before discussing how built-in templates are used in
 detail, we'll discuss two ways to render templates within
 :app:`Pyramid` in general: directly, and via renderer
@@ -32,7 +28,7 @@ given templating engine to do so.
 
 :app:`Pyramid` provides various APIs that allow you to render templates
 directly from within a view callable.  For example, if there is a
-:term:`Chameleon` ZPT template named ``foo.pt`` in a directory  named
+:term:`Chameleon` ZPT template named ``foo.pt`` in a directory named
 ``templates`` in your application, you can render the template from
 within the body of a view callable like so:
 
@@ -383,236 +379,6 @@ The same set of system values are provided to templates rendered via a
 renderer view configuration as those provided to templates rendered
 imperatively.  See :ref:`renderer_system_values`.
 
-
-.. index::
-   single: Chameleon ZPT templates
-   single: ZPT templates (Chameleon)
-
-.. _chameleon_zpt_templates:
-
-:term:`Chameleon` ZPT Templates
--------------------------------
-
-Like :term:`Zope`, :app:`Pyramid` uses :term:`ZPT` (Zope Page
-Templates) as its default templating language.  However,
-:app:`Pyramid` uses a different implementation of the :term:`ZPT`
-specification than Zope does: the :term:`Chameleon` templating
-engine. The Chameleon engine complies largely with the `Zope Page
-Template <http://wiki.zope.org/ZPT/FrontPage>`_ template
-specification.  However, it is significantly faster.
-
-The language definition documentation for Chameleon ZPT-style
-templates is available from `the Chameleon website
-<http://chameleon.repoze.org/>`_.
-
-Given a :term:`Chameleon` ZPT template named ``foo.pt`` in a directory
-in your application named ``templates``, you can render the template as
-a :term:`renderer` like so:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.view import view_config
-
-   @view_config(renderer='templates/foo.pt')
-   def my_view(request):
-       return {'foo':1, 'bar':2}
-
-See also :ref:`built_in_renderers` for more general information about
-renderers, including Chameleon ZPT renderers.
-
-.. index::
-   single: ZPT template (sample)
-
-A Sample ZPT Template
-~~~~~~~~~~~~~~~~~~~~~
-
-Here's what a simple :term:`Chameleon` ZPT template used under
-:app:`Pyramid` might look like:
-
-.. code-block:: xml
-   :linenos:
-
-    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
-        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-    <html xmlns="http://www.w3.org/1999/xhtml"
-          xmlns:tal="http://xml.zope.org/namespaces/tal">
-    <head>
-        <meta http-equiv="content-type" content="text/html; charset=utf-8" />
-        <title>${project} Application</title>
-    </head>
-      <body>
-         <h1 class="title">Welcome to <code>${project}</code>, an
-	  application generated by the <a
-	  href="http://docs.pylonsproject.org/projects/pyramid/current/"
-         >pyramid</a> web
-	  application framework.</h1>
-      </body>
-    </html>
-
-Note the use of :term:`Genshi` -style ``${replacements}`` above.  This
-is one of the ways that :term:`Chameleon` ZPT differs from standard
-ZPT.  The above template expects to find a ``project`` key in the set
-of keywords passed in to it via :func:`~pyramid.renderers.render` or
-:func:`~pyramid.renderers.render_to_response`. Typical ZPT
-attribute-based syntax (e.g. ``tal:content`` and ``tal:replace``) also
-works in these templates.
-
-.. index::
-   single: ZPT macros
-   single: Chameleon ZPT macros
-
-Using ZPT Macros in :app:`Pyramid`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When a :term:`renderer` is used to render a template, :app:`Pyramid` makes at
-least two top-level names available to the template by default: ``context``
-and ``request``.  One of the common needs in ZPT-based templates is to use
-one template's "macros" from within a different template.  In Zope, this is
-typically handled by retrieving the template from the ``context``.  But the
-context in :app:`Pyramid` is a :term:`resource` object, and templates cannot
-usually be retrieved from resources.  To use macros in :app:`Pyramid`, you
-need to make the macro template itself available to the rendered template by
-passing the macro template, or even the macro itself, *into* the rendered
-template.  To do this you can use the :func:`pyramid.renderers.get_renderer`
-API to retrieve the macro template, and pass it into the template being
-rendered via the dictionary returned by the view.  For example, using a
-:term:`view configuration` via a :class:`~pyramid.view.view_config` decorator
-that uses a :term:`renderer`:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.renderers import get_renderer
-   from pyramid.view import view_config
-
-   @view_config(renderer='templates/mytemplate.pt')
-   def my_view(request):
-       main = get_renderer('templates/master.pt').implementation()
-       return {'main':main}
-
-Where ``templates/master.pt`` might look like so:
-
-.. code-block:: xml
-   :linenos:
-
-    <html xmlns="http://www.w3.org/1999/xhtml" 
-          xmlns:tal="http://xml.zope.org/namespaces/tal"
-          xmlns:metal="http://xml.zope.org/namespaces/metal">
-      <span metal:define-macro="hello">
-        <h1>
-          Hello <span metal:define-slot="name">Fred</span>!
-        </h1>
-      </span>
-    </html>
-
-And ``templates/mytemplate.pt`` might look like so:
-
-.. code-block:: xml
-   :linenos:
-
-    <html xmlns="http://www.w3.org/1999/xhtml" 
-          xmlns:tal="http://xml.zope.org/namespaces/tal"
-          xmlns:metal="http://xml.zope.org/namespaces/metal">
-      <span metal:use-macro="main.macros['hello']">
-        <span metal:fill-slot="name">Chris</span>
-      </span>
-    </html>
-
-
-Using A Chameleon Macro Name Within a Renderer Name
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-At times, you may want to render a macro inside of a Chameleon ZPT template
-instead of the full Chameleon ZPT template. To render the content of a
-``define-macro`` field inside a Chameleon ZPT template, given a Chameleon
-template file named ``foo.pt`` and a macro named ``bar`` defined within it
-(e.g. ``<div metal:define-macro="bar">...</div>``), you can configure the
-template as a :term:`renderer` like so:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.view import view_config
-
-   @view_config(renderer='foo#bar.pt')
-   def my_view(request):
-       return {'project':'my project'}
-
-The above will render only the ``bar`` macro defined within the ``foo.pt``
-template instead of the entire template.
-
-.. versionadded:: 1.4
-
-.. index::
-   single: Chameleon text templates
-
-.. _chameleon_text_templates:
-
-Templating with :term:`Chameleon` Text Templates
-------------------------------------------------
-
-:app:`Pyramid` also allows for the use of templates which are
-composed entirely of non-XML text via :term:`Chameleon`.  To do so,
-you can create templates that are entirely composed of text except for
-``${name}`` -style substitution points.
-
-Here's an example usage of a Chameleon text template.  Create a file
-on disk named ``mytemplate.txt`` in your project's ``templates``
-directory with the following contents:
-
-.. code-block:: text
-
-   Hello, ${name}!
-
-Then in your project's ``views.py`` module, you can create a view
-which renders this template:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.view import view_config
-
-   @view_config(renderer='templates/mytemplate.txt')
-   def my_view(request):
-       return {'name':'world'}
-
-When the template is rendered, it will show:
-
-.. code-block:: text
-
-   Hello, world!
-
-See also :ref:`built_in_renderers` for more general information about
-renderers, including Chameleon text renderers.
-
-.. index::
-   single: template renderer side effects
-
-Side Effects of Rendering a Chameleon Template
-----------------------------------------------
-
-When a Chameleon template is rendered from a file, the templating
-engine writes a file in the same directory as the template file itself
-as a kind of cache, in order to do less work the next time the
-template needs to be read from disk. If you see "strange" ``.py``
-files showing up in your ``templates`` directory (or otherwise
-directly "next" to your templates), it is due to this feature.
-
-If you're using a version control system such as Subversion, you
-should configure it to ignore these files.  Here's the contents of the
-author's ``svn propedit svn:ignore .`` in each of my ``templates``
-directories.
-
-.. code-block:: text
-
-   *.pt.py
-   *.txt.py
-
-Note that I always name my Chameleon ZPT template files with a ``.pt``
-extension and my Chameleon text template files with a ``.txt``
-extension so that these ``svn:ignore`` patterns work.
-
 .. index::
    pair: debugging; templates
 
@@ -643,107 +409,6 @@ undefined variable (e.g. ``${wrong}``) might end up looking like this:
 The output tells you which template the error occurred in, as well as
 displaying the arguments passed to the template itself.
 
-.. index::
-   single: template internationalization
-   single: internationalization (of templates)
-
-:term:`Chameleon` Template Internationalization
------------------------------------------------
-
-See :ref:`chameleon_translation_strings` for information about
-supporting internationalized units of text within :term:`Chameleon`
-templates.
-
-.. index::
-   single: Mako
-
-.. _mako_templates:
-
-Templating With Mako Templates
-------------------------------
-
-:term:`Mako` is a templating system written by Mike Bayer.  :app:`Pyramid`
-has built-in bindings for the Mako templating system.  The language
-definition documentation for Mako templates is available from `the Mako
-website <http://www.makotemplates.org/>`_.
-
-To use a Mako template, given a :term:`Mako` template file named ``foo.mak``
-in the ``templates`` subdirectory in your application package named
-``mypackage``, you can configure the template as a :term:`renderer` like so:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.view import view_config
-
-   @view_config(renderer='foo.mak')
-   def my_view(request):
-       return {'project':'my project'}
-
-For the above view callable to work, the following setting needs to be
-present in the application stanza of your configuration's ``ini`` file:
-
-.. code-block:: ini
-
-   mako.directories = mypackage:templates
-
-This lets the Mako templating system know that it should look for templates
-in the ``templates`` subdirectory of the ``mypackage`` Python package.  See
-:ref:`mako_template_renderer_settings` for more information about the
-``mako.directories`` setting and other Mako-related settings that can be
-placed into the application's ``ini`` file.
-
-.. index::
-   single: Mako template (sample)
-
-A Sample Mako Template
-~~~~~~~~~~~~~~~~~~~~~~
-
-Here's what a simple :term:`Mako` template used under :app:`Pyramid` might
-look like:
-
-.. code-block:: xml
-   :linenos:
-
-    <html>
-    <head>
-        <title>${project} Application</title>
-    </head>
-      <body>
-         <h1 class="title">Welcome to <code>${project}</code>, an
-	  application generated by the <a
-	  href="http://docs.pylonsproject.org/projects/pyramid/current/"
-         >pyramid</a> web framework.</h1>
-      </body>
-    </html>
-
-This template doesn't use any advanced features of Mako, only the
-``${}`` replacement syntax for names that are passed in as
-:term:`renderer globals`.  See the `the Mako documentation
-<http://www.makotemplates.org/>`_ to use more advanced features.
-
-Using A Mako def name Within a Renderer Name
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sometimes you'd like to render a ``def`` inside of a Mako template instead of
-the full Mako template. To render a def inside a Mako template, given a
-:term:`Mako` template file named ``foo.mak`` and a def named ``bar``, you can
-configure the template as a :term:`renderer` like so:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.view import view_config
-
-   @view_config(renderer='foo#bar.mak')
-   def my_view(request):
-       return {'project':'my project'}
-
-The above will render the ``bar`` def from within the ``foo.mak`` template
-instead of the entire template.
-
-.. versionadded:: 1.4
-
 .. index::
    single: automatic reloading of templates
    single: template automatic reload
-- 
cgit v1.2.3


From 7a60e44961309f5453fba84c7f606af6b19ab096 Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 22:57:37 -0500
Subject: whitespace fixes

---
 docs/narr/templates.rst | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 24973f253..46d836813 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -318,7 +318,9 @@ template renderer:
    def my_view(request):
        return {'foo':1, 'bar':2}
 
-.. note:: You do not need to supply the ``request`` value as a key
+.. note::
+
+   You do not need to supply the ``request`` value as a key
    in the dictionary result returned from a renderer-configured view
    callable. :app:`Pyramid` automatically supplies this value for
    you so that the "most correct" system values are provided to
@@ -424,9 +426,11 @@ appear immediately without needing to restart the application process.
 environment so that a change to a template will be automatically
 detected, and the template will be reloaded on the next rendering.
 
-.. warning:: Auto-template-reload behavior is not recommended for
-             production sites as it slows rendering slightly; it's
-             usually only desirable during development.
+.. warning::
+
+   Auto-template-reload behavior is not recommended for
+   production sites as it slows rendering slightly; it's
+   usually only desirable during development.
 
 In order to turn on automatic reloading of templates, you can use an
 environment variable, or a configuration file setting.
@@ -437,18 +441,18 @@ variable set to ``1``, For example:
 
 .. code-block:: text
 
-  $ PYRAMID_RELOAD_TEMPLATES=1 $VENV/bin/pserve myproject.ini
+   $ PYRAMID_RELOAD_TEMPLATES=1 $VENV/bin/pserve myproject.ini
 
 To use a setting in the application ``.ini`` file for the same
 purpose, set the ``pyramid.reload_templates`` key to ``true`` within the
 application's configuration section, e.g.:
 
 .. code-block:: ini
-  :linenos:
+   :linenos:
 
-  [app:main]
-  use = egg:MyProject
-  pyramid.reload_templates = true
+   [app:main]
+   use = egg:MyProject
+   pyramid.reload_templates = true
 
 .. index::
    single: template system bindings
-- 
cgit v1.2.3


From b9ce00bee0b6f1f5b0174960f2087a418c1488a7 Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 22:57:46 -0500
Subject: move templating bindings back into the templating chapter

---
 docs/narr/renderers.rst | 38 +++++---------------------------------
 docs/narr/templates.rst | 27 ++++++++++++++++++++++-----
 2 files changed, 27 insertions(+), 38 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 8de3cd29d..8afc9c4ab 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -128,6 +128,11 @@ Built-In Renderers
 Several built-in renderers exist in :app:`Pyramid`.  These renderers can be
 used in the ``renderer`` attribute of view configurations.
 
+.. note::
+
+   Bindings for officially supported templating languages can be found
+   at :ref:`available_template_system_bindings`.
+
 .. index::
    pair: renderer; string
 
@@ -364,39 +369,6 @@ The same custom-object serialization scheme defined used for a "normal" JSON
 renderer in :ref:`json_serializing_custom_objects` can be used when passing
 values to a JSONP renderer too.
 
-.. index::
-   single: template system bindings
-   single: Chameleon
-   single: Jinja2
-   single: Mako
-
-.. _available_template_system_bindings:
-
-Available Add-On Template System Bindings
------------------------------------------
-
-The Pylons Project maintains several packages providing bindings to different
-templating languages including the following:
-
-+------------------------------+------------------------------+
-| Template Language            | Pyramid Bindings             |
-+==============================+==============================+
-| Chameleon_                   | pyramid_chameleon_           |
-+------------------------------+------------------------------+
-| Jinja2_                      | pyramid_jinja2_              |
-+------------------------------+------------------------------+
-| Mako_                        | pyramid_mako_                |
-+------------------------------+------------------------------+
-
-.. _Chameleon: http://chameleon.readthedocs.org/en/latest/
-.. _pyramid_chameleon: https://pypi.python.org/pypi/pyramid_chameleon
-
-.. _Jinja2: http://jinja.pocoo.org/docs/
-.. _pyramid_jinja2: https://pypi.python.org/pypi/pyramid_jinja2
-
-.. _Mako: http://www.makotemplates.org/
-.. _pyramid_mako: https://pypi.python.org/pypi/pyramid_mako
-
 .. index::
    single: response headers (from a renderer)
    single: renderer response headers
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 46d836813..af8f9150a 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -456,16 +456,33 @@ application's configuration section, e.g.:
 
 .. index::
    single: template system bindings
+   single: Chameleon
    single: Jinja2
+   single: Mako
 
 .. _available_template_system_bindings:
 
 Available Add-On Template System Bindings
 -----------------------------------------
 
-Jinja2 template bindings are available for :app:`Pyramid` in the
-``pyramid_jinja2`` package. You can get the latest release of
-this package from the 
-`Python package index <http://pypi.python.org/pypi/pyramid_jinja2>`_
-(pypi).
+The Pylons Project maintains several packages providing bindings to different
+templating languages including the following:
 
++------------------------------+------------------------------+
+| Template Language            | Pyramid Bindings             |
++==============================+==============================+
+| Chameleon_                   | pyramid_chameleon_           |
++------------------------------+------------------------------+
+| Jinja2_                      | pyramid_jinja2_              |
++------------------------------+------------------------------+
+| Mako_                        | pyramid_mako_                |
++------------------------------+------------------------------+
+
+.. _Chameleon: http://chameleon.readthedocs.org/en/latest/
+.. _pyramid_chameleon: https://pypi.python.org/pypi/pyramid_chameleon
+
+.. _Jinja2: http://jinja.pocoo.org/docs/
+.. _pyramid_jinja2: https://pypi.python.org/pypi/pyramid_jinja2
+
+.. _Mako: http://www.makotemplates.org/
+.. _pyramid_mako: https://pypi.python.org/pypi/pyramid_mako
-- 
cgit v1.2.3


From f1aaf1577dfeb9e094a5a9d7130984b95531d5cb Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 23:40:27 -0500
Subject: remove some more mako/chameleon references

---
 docs/narr/templates.rst | 50 ++++++++++++++-----------------------------------
 1 file changed, 14 insertions(+), 36 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index af8f9150a..3e19f7198 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -56,19 +56,8 @@ In this case, this is the directory containing the file that
 defines the ``sample_view`` function.  Although a renderer path is
 usually just a simple relative pathname, a path named as a renderer
 can be absolute, starting with a slash on UNIX or a drive letter
-prefix on Windows.
-
-.. warning::
-
-   Only :term:`Chameleon` templates support defining a renderer for a
-   template relative to the location of the module where the view callable is
-   defined.  Mako templates, and other templating system bindings work
-   differently.  In particular, Mako templates use a "lookup path" as defined
-   by the ``mako.directories`` configuration file instead of treating
-   relative paths as relative to the current view module.  See
-   :ref:`mako_templates`.
-
-The path can alternately be a :term:`asset specification` in the form
+prefix on Windows. The path can alternately be a
+:term:`asset specification` in the form
 ``some.dotted.package_name:relative/path``. This makes it possible to
 address template assets which live in another package.  For example:
 
@@ -86,16 +75,9 @@ An asset specification points at a file within a Python *package*.
 In this case, it points at a file named ``foo.pt`` within the
 ``templates`` directory of the ``mypackage`` package.  Using a
 asset specification instead of a relative template name is usually
-a good idea, because calls to ``render_to_response`` using asset
-specifications will continue to work properly if you move the code
-containing them around.
-
-.. note::
-
-   Mako templating system bindings also respect absolute asset
-   specifications as an argument to any of the ``render*`` commands.  If a
-   template name defines a ``:`` (colon) character and is not an absolute
-   path, it is treated as an absolute asset specification.
+a good idea, because calls to :func:`~pyramid.renderers.render_to_response`
+using asset specifications will continue to work properly if you move the
+code containing them around.
 
 In the examples above we pass in a keyword argument named ``request``
 representing the current :app:`Pyramid` request. Passing a request
@@ -143,8 +125,8 @@ import its API functions into your views module, use those APIs to generate a
 string, then return that string as the body of a :app:`Pyramid`
 :term:`Response` object.
 
-For example, here's an example of using "raw" `Mako
-<http://www.makotemplates.org/>`_ from within a :app:`Pyramid` :term:`view`:
+For example, here's an example of using "raw" Mako_ from within a
+:app:`Pyramid` :term:`view`:
 
 .. code-block:: python
    :linenos:
@@ -159,10 +141,10 @@ For example, here's an example of using "raw" `Mako
        return response
 
 You probably wouldn't use this particular snippet in a project, because it's
-easier to use the Mako renderer bindings which already exist in
-:app:`Pyramid`. But if your favorite templating system is not supported as a
-renderer extension for :app:`Pyramid`, you can create your own simple
-combination as shown above.
+easier to use the supported
+:ref:`Mako bindings <available_template_system_bindings>`. But if your
+favorite templating system is not supported as a renderer extension for
+:app:`Pyramid`, you can create your own simple combination as shown above.
 
 .. note::
 
@@ -277,8 +259,8 @@ You can define more values which will be passed to every template executed as
 a result of rendering by defining :term:`renderer globals`.
 
 What any particular renderer does with these system values is up to the
-renderer itself, but most template renderers, including Chameleon and Mako
-renderers, make these names available as top-level template variables.
+renderer itself, but most template renderers make these names available as
+top-level template variables.
 
 .. index::
    pair: renderer; templates
@@ -348,11 +330,7 @@ it possible to address template assets which live in another package.
 
 Not just any template from any arbitrary templating system may be used as a
 renderer.  Bindings must exist specifically for :app:`Pyramid` to use a
-templating language template as a renderer.  Currently, :app:`Pyramid` has
-built-in support for two Chameleon templating languages: ZPT and text, and
-the Mako templating system.  See :ref:`built_in_renderers` for a discussion
-of their details.  :app:`Pyramid` also supports the use of :term:`Jinja2`
-templates as renderers.  See :ref:`available_template_system_bindings`.
+templating language template as a renderer.
 
 .. sidebar:: Why Use A Renderer via View Configuration
 
-- 
cgit v1.2.3


From 2207ed5c82dfd8c259f6032ff84eb8998be40fa8 Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 23:51:03 -0500
Subject: update the MyProject example app to use pyramid_chameleon

---
 docs/narr/MyProject/myproject/__init__.py |  1 +
 docs/narr/MyProject/setup.py              |  1 +
 docs/narr/project.rst                     | 17 ++++++++++-------
 3 files changed, 12 insertions(+), 7 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/MyProject/myproject/__init__.py b/docs/narr/MyProject/myproject/__init__.py
index 6c512f52f..ad5ecbc6f 100644
--- a/docs/narr/MyProject/myproject/__init__.py
+++ b/docs/narr/MyProject/myproject/__init__.py
@@ -5,6 +5,7 @@ def main(global_config, **settings):
     """ This function returns a Pyramid WSGI application.
     """
     config = Configurator(settings=settings)
+    config.include('pyramid_chameleon')
     config.add_static_view('static', 'static', cache_max_age=3600)
     config.add_route('home', '/')
     config.scan()
diff --git a/docs/narr/MyProject/setup.py b/docs/narr/MyProject/setup.py
index 6969c73e7..a23f46c91 100644
--- a/docs/narr/MyProject/setup.py
+++ b/docs/narr/MyProject/setup.py
@@ -10,6 +10,7 @@ with open(os.path.join(here, 'CHANGES.txt')) as f:
 
 requires = [
     'pyramid',
+    'pyramid_chameleon',
     'pyramid_debugtoolbar',
     'waitress',
     ]
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 52f13d5a8..f3050f805 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -570,8 +570,8 @@ adding more settings to this section.
 
 The ``pyramid.reload_templates`` setting in the ``[app:main]`` section is a
 :app:`Pyramid` -specific setting which is passed into the framework.  If it
-exists, and its value is ``true``, :term:`Chameleon` and :term:`Mako`
-template changes will not require an application restart to be detected.  See
+exists, and its value is ``true``, supported template changes will not
+require an application restart to be detected.  See
 :ref:`reload_templates_section` for more information.
 
 .. warning:: The ``pyramid.reload_templates`` option should be turned off for
@@ -818,7 +818,7 @@ also informs Python that the directory which contains it is a *package*.
 #. Line 1 imports the :term:`Configurator` class from :mod:`pyramid.config`
    that we use later.
 
-#. Lines 4-11 define a function named ``main`` that returns a :app:`Pyramid`
+#. Lines 4-12 define a function named ``main`` that returns a :app:`Pyramid`
    WSGI application.  This function is meant to be called by the
    :term:`PasteDeploy` framework as a result of running ``pserve``.
 
@@ -826,17 +826,20 @@ also informs Python that the directory which contains it is a *package*.
 
    Line 7 creates an instance of a :term:`Configurator`.
 
-   Line 8 registers a static view, which will serve up the files from the
+   Line 8 adds support for Chameleon templating bindings, allowing us to
+   specify renderers with the ``.pt`` extension.
+
+   Line 9 registers a static view, which will serve up the files from the
    ``myproject:static`` :term:`asset specification` (the ``static``
    directory of the ``myproject`` package).
 
-   Line 9 adds a :term:`route` to the configuration.  This route is later
+   Line 10 adds a :term:`route` to the configuration.  This route is later
    used by a view in the ``views`` module.
 
-   Line 10 calls ``config.scan()``, which picks up view registrations declared
+   Line 11 calls ``config.scan()``, which picks up view registrations declared
    elsewhere in the package (in this case, in the ``views.py`` module).
 
-   Line 11 returns a :term:`WSGI` application to the caller of the function
+   Line 12 returns a :term:`WSGI` application to the caller of the function
    (Pyramid's pserve).
 
 .. index::
-- 
cgit v1.2.3


From ac681bc83778443bcb70b9c1ea370368044614fb Mon Sep 17 00:00:00 2001
From: Michael Merickel <michael@merickel.org>
Date: Thu, 5 Sep 2013 23:56:46 -0500
Subject: remove chameleon refs from asset specs

---
 docs/narr/assets.rst | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/assets.rst b/docs/narr/assets.rst
index 26b3e3a92..b0a8d18b0 100644
--- a/docs/narr/assets.rst
+++ b/docs/narr/assets.rst
@@ -227,14 +227,14 @@ API to generate them for you.  For example:
 .. code-block:: python
    :linenos:
 
-   from pyramid.chameleon_zpt import render_template_to_response
+   from pyramid.renderers import render_to_response
 
    def my_view(request):
        css_url = request.static_url('mypackage:assets/1/foo.css')
        js_url = request.static_url('mypackage:assets/2/foo.js')
-       return render_template_to_response('templates/my_template.pt',
-                                          css_url = css_url,
-                                          js_url = js_url)
+       return render_to_response('templates/my_template.pt',
+                                 dict(css_url=css_url, js_url=js_url),
+                                 request=request)
 
 If the request "application URL" of the running system is
 ``http://example.com``, the ``css_url`` generated above would be:
@@ -336,7 +336,9 @@ your application root as below.
    from pyramid.static import static_view
    static_view = static_view('/path/to/static/dir', use_subpath=True)
 
-.. note:: For better cross-system flexibility, use an :term:`asset
+.. note::
+
+   For better cross-system flexibility, use an :term:`asset
    specification` as the argument to :class:`~pyramid.static.static_view`
    instead of a physical absolute filesystem path, e.g. ``mypackage:static``
    instead of ``/path/to/mypackage/static``.
@@ -432,9 +434,9 @@ feature, a :term:`Configurator` API exists named
 :meth:`pyramid.config.Configurator.override_asset`.  This API allows you to
 *override* the following kinds of assets defined in any Python package:
 
-- Individual :term:`Chameleon` templates.
+- Individual template files.
 
-- A directory containing multiple Chameleon templates.
+- A directory containing multiple template files.
 
 - Individual static files served up by an instance of the
   ``pyramid.static.static_view`` helper class.
@@ -460,8 +462,8 @@ can override a single asset.  For example:
    :linenos:
 
    config.override_asset(
-            to_override='some.package:templates/mytemplate.pt',
-            override_with='another.package:othertemplates/anothertemplate.pt')
+       to_override='some.package:templates/mytemplate.pt',
+       override_with='another.package:othertemplates/anothertemplate.pt')
 
 The string value passed to both ``to_override`` and ``override_with`` sent to
 the ``override_asset`` API is called an :term:`asset specification`.  The
-- 
cgit v1.2.3


From fc477b2e4b20ae2788e468e45b2831e774be8ced Mon Sep 17 00:00:00 2001
From: Chris McDonough <chrism@plope.com>
Date: Sat, 7 Sep 2013 21:59:41 -0400
Subject: - The ``pyramid.events.NewResponse`` event is now sent **after**
 response   callbacks are executed.  It previously executed before response
 callbacks   were executed.  Rationale: it's more useful to be able to inspect
 the response   after response callbacks have done their jobs instead of
 before.

Closes #1116.
---
 docs/narr/hooks.rst      | 2 +-
 docs/narr/subrequest.rst | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index 3a2568775..8ffda1a5f 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -514,7 +514,7 @@ callback will be an exception object instead of its default value of
 ``None``.
 
 Response callbacks are called in the order they're added
-(first-to-most-recently-added).  All response callbacks are called *after*
+(first-to-most-recently-added).  All response callbacks are called *before*
 the :class:`~pyramid.events.NewResponse` event is sent.  Errors raised by
 response callbacks are not handled specially.  They will be propagated to the
 caller of the :app:`Pyramid` router application.
diff --git a/docs/narr/subrequest.rst b/docs/narr/subrequest.rst
index 6437bd0fa..4b4e99d41 100644
--- a/docs/narr/subrequest.rst
+++ b/docs/narr/subrequest.rst
@@ -232,12 +232,12 @@ unconditionally:
 - Ensures that the user implied by the request passed has the necessary
   authorization to invoke view callable before calling it.
 
-- causes a :class:`~pyramid.events.NewResponse` event to be sent when the
-  Pyramid application returns a response.
-
 - Calls any :term:`response callback` functions defined within the subrequest's
   lifetime if a response is obtained from the Pyramid application.
 
+- causes a :class:`~pyramid.events.NewResponse` event to be sent if a response
+  is obtained.
+
 - Calls any :term:`finished callback` functions defined within the subrequest's
   lifetime.
 
-- 
cgit v1.2.3


From d71acabebb804ebbd37703e78ac9886fcdded827 Mon Sep 17 00:00:00 2001
From: Bert JW Regeer <bertjw@regeer.org>
Date: Sun, 8 Sep 2013 15:15:58 -0600
Subject: Update documentation to reflect the dotted python name

---
 docs/narr/hooks.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index 8ffda1a5f..a7dc3e78b 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -1384,9 +1384,11 @@ The first argument to :meth:`pyramid.config.Configurator.add_view_predicate`,
 the name, is a string representing the name that is expected to be passed to
 ``view_config`` (or its imperative analogue ``add_view``).
 
-The second argument is a view or route predicate factory.  A view or route
-predicate factory is most often a class with a constructor (``__init__``), a
-``text`` method, a ``phash`` method and a ``__call__`` method.  For example:
+The second argument is a view or route predicate factory, or a :term:`dotted
+Python name` which refers to a view or route predicate factory.  A view or
+route predicate factory is most often a class with a constructor
+(``__init__``), a ``text`` method, a ``phash`` method and a ``__call__``
+method. For example:
 
 .. code-block:: python
    :linenos:
-- 
cgit v1.2.3


From fdf30b3bb6f47d93d2f255a09e75be0c33d54789 Mon Sep 17 00:00:00 2001
From: Chris McDonough <chrism@plope.com>
Date: Sun, 8 Sep 2013 21:12:10 -0400
Subject: - Removed the ability to pass the following arguments to  
 ``pyramid.config.Configurator.add_route``: `view``, ``view_context``.  
 ``view_for``, ``view_permission``, ``view_renderer``, and ``view_attr``.  
 Using these arguments had been deprecated since Pyramid 1.1.  Instead of  
 passing view-related arguments to ``add_route``, use a separate call to  
 ``pyramid.config.Configurator.add_view`` to associate a view with a route  
 using its ``route_name`` argument.  Note that this impacts the  
 ``pyramid.config.Configurator.add_static_view`` function too, because it  
 delegates to ``add_route``.

---
 docs/narr/urldispatch.rst | 7 -------
 1 file changed, 7 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 62eb89348..61849c3c0 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -399,13 +399,6 @@ process.  Examples of route predicate arguments are ``pattern``, ``xhr``, and
 Other arguments are ``name`` and ``factory``.  These arguments represent
 neither predicates nor view configuration information.
 
-.. warning::
-
-   Some arguments are view-configuration related arguments, such as
-   ``view_renderer``.  These only have an effect when the route configuration
-   names a ``view`` and these arguments have been deprecated as of
-   :app:`Pyramid` 1.1.
-
 .. index::
    single: route matching
 
-- 
cgit v1.2.3


From c6601f77f91dc933ca429d1448f4c6b27857b608 Mon Sep 17 00:00:00 2001
From: Chris McDonough <chrism@plope.com>
Date: Sun, 8 Sep 2013 22:52:54 -0400
Subject: - The ``renderer_globals_factory`` argument to the  
 ``pyramid.config.Configurator` constructor and its ``setup_registry`` method 
  has been removed.  The ``set_renderer_globals_factory`` method of  
 ``pyramid.config.Configurator`` has also been removed.  The (internal)  
 ``pyramid.interfaces.IRendererGlobals`` interface was also removed.  These  
 arguments, methods and interfaces had been deprecated since 1.1.  Use a  
 ``BeforeRender`` event subscriber as documented in the "Hooks" chapter of the
   Pyramid narrative documentation instead of providing renderer globals
 values   to the configurator.

---
 docs/narr/advconfig.rst    |  1 -
 docs/narr/hooks.rst        | 66 ++--------------------------------------------
 docs/narr/introspector.rst | 12 ---------
 3 files changed, 2 insertions(+), 77 deletions(-)

(limited to 'docs/narr')

diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst
index 1b8e33de3..d3431e39e 100644
--- a/docs/narr/advconfig.rst
+++ b/docs/narr/advconfig.rst
@@ -302,7 +302,6 @@ These are the methods of the configurator which provide conflict detection:
 :meth:`~pyramid.config.Configurator.set_view_mapper`,
 :meth:`~pyramid.config.Configurator.set_authentication_policy`,
 :meth:`~pyramid.config.Configurator.set_authorization_policy`,
-:meth:`~pyramid.config.Configurator.set_renderer_globals_factory`,
 :meth:`~pyramid.config.Configurator.set_locale_negotiator`,
 :meth:`~pyramid.config.Configurator.set_default_permission`,
 :meth:`~pyramid.config.Configurator.add_traverser`,
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index a7dc3e78b..0c450fad7 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -372,10 +372,8 @@ that can be used for this purpose.  For example:
     def add_global(event):
         event['mykey'] = 'foo'
 
-An object of this type is sent as an event just before a :term:`renderer` is
-invoked (but *after* the application-level renderer globals factory added via
-:class:`~pyramid.config.Configurator.set_renderer_globals_factory`, if any,
-has injected its own keys into the renderer globals dictionary).
+An object of this type is sent as an event just before a :term:`renderer`
+is invoked.
 
 If a subscriber attempts to add a key that already exist in the renderer
 globals dictionary, a :exc:`KeyError` is raised.  This limitation is enforced
@@ -417,66 +415,6 @@ your view callable, like so:
 See the API documentation for the :class:`~pyramid.events.BeforeRender` event
 interface at :class:`pyramid.interfaces.IBeforeRender`.
 
-Another (deprecated) mechanism which allows event subscribers more control
-when adding renderer global values exists in :ref:`adding_renderer_globals`.
-
-.. index::
-   single: adding renderer globals
-
-.. _adding_renderer_globals:
-
-Adding Renderer Globals (Deprecated)
-------------------------------------
-
-.. deprecated:: 1.1
-   An alternative mechanism which allows event subscribers to add renderer
-   global values is documented in :ref:`beforerender_event`.
-
-Whenever :app:`Pyramid` handles a request to perform a rendering (after a
-view with a ``renderer=`` configuration attribute is invoked, or when any of
-the methods beginning with ``render`` within the :mod:`pyramid.renderers`
-module are called), *renderer globals* can be injected into the *system*
-values sent to the renderer.  By default, no renderer globals are injected,
-and the "bare" system values (such as ``request``, ``context``, ``view``, and
-``renderer_name``) are the only values present in the system dictionary
-passed to every renderer.
-
-A callback that :app:`Pyramid` will call every time a renderer is invoked can
-be added by passing a ``renderer_globals_factory`` argument to the
-constructor of the :term:`configurator`.  This callback can either be a
-callable object or a :term:`dotted Python name` representing such a callable.
-
-.. code-block:: python
-   :linenos:
-
-   def renderer_globals_factory(system):
-       return {'a': 1}
-
-   config = Configurator(
-            renderer_globals_factory=renderer_globals_factory)
-
-Such a callback must accept a single positional argument (notionally named
-``system``) which will contain the original system values.  It must return a
-dictionary of values that will be merged into the system dictionary.  See
-:ref:`renderer_system_values` for description of the values present in the
-system dictionary.
-
-If you're doing imperative configuration, and you'd rather do it after you've
-already constructed a :term:`configurator` it can also be registered via the
-:meth:`pyramid.config.Configurator.set_renderer_globals_factory` method:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.config import Configurator
-
-   def renderer_globals_factory(system):
-       return {'a': 1}
-
-   config = Configurator()
-   config.set_renderer_globals_factory(renderer_globals_factory)
-
-
 .. index::
    single: response callback
 
diff --git a/docs/narr/introspector.rst b/docs/narr/introspector.rst
index dec22c5b1..3c0a6744f 100644
--- a/docs/narr/introspector.rst
+++ b/docs/narr/introspector.rst
@@ -232,18 +232,6 @@ introspectables in categories not described here.
     The factory object (the resolved ``factory`` argument to
     ``add_renderer``).
 
-``renderer globals factory``
-
-  There will be one and only one introspectable in the ``renderer globals
-  factory`` category.  It represents a call to
-  :meth:`pyramid.config.Configurator.set_renderer_globals_factory`; it will
-  have the following data.
-
-  ``factory``
-
-    The factory object (the resolved ``factory`` argument to
-    ``set_renderer_globals_factory``).
-
 ``routes``
 
   Each introspectable in the ``routes`` category represents a call to
-- 
cgit v1.2.3