clean up inappropriate discussions of ZCML

3 files changed, 6 insertions, 15 deletions

diff --git a/docs/narr/assets.rst b/docs/narr/assets.rst
index c8508f1b5..93b03fbc9 100644
--- a/docs/narr/assets.rst
+++ b/docs/narr/assets.rst
@@ -441,9 +441,6 @@ feature, a :term:`Configurator` API exists named
 - Any other asset (or set of assets) addressed by code that uses the
   setuptools :term:`pkg_resources` API.
 
-.. note:: The :term:`ZCML` directive named ``asset`` serves the same purpose
-   as the :meth:`~pyramid.config.Configurator.override_asset` method.
-
 .. index::
    single: override_asset
 
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index 63c31d340..97f63fcfe 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -122,9 +122,9 @@ application developer may use completely imperative code to perform common
 framework configuration tasks such as adding a view or a route.  In Zope,
 :term:`ZCML` is typically required for similar purposes.  In :term:`Grok`, a
 Zope-based web framework, :term:`decorator` objects and class-level
-declarations are used for this purpose.  :app:`Pyramid` supports :term:`ZCML`
-and decorator-based :term:`declarative configuration`, but does not require
-either. See :ref:`configuration_narr` for more information.
+declarations are used for this purpose.  Out of the box, Pyramid supports
+imperative and decorator-based configuration; :term:`ZCML` may be used via an
+add-on package named ``pyramid_zcml``.
 
 Also unlike :term:`Zope` and unlike other "full-stack" frameworks such
 as :term:`Django`, :app:`Pyramid` makes no assumptions about which
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index d5caed4be..6412c070d 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -335,9 +335,8 @@ template renderer:
    function.  View-configuration-relative asset specifications work only
    in Chameleon, not in Mako templates.
 
-Similar renderer configuration can be done imperatively and via
-:term:`ZCML`.  See :ref:`views_which_use_a_renderer`.  See also
-:ref:`built_in_renderers`.
+Similar renderer configuration can be done imperatively.  See
+:ref:`views_which_use_a_renderer`.  See also :ref:`built_in_renderers`.
 
 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
@@ -366,12 +365,7 @@ templates as renderers.  See :ref:`available_template_system_bindings`.
    with renderers externally via view configuration typically return a
    dictionary, as above.  Making assertions about results returned in a
    dictionary is almost always more direct and straightforward than
-   needing to parse HTML.  Specifying a renderer from within
-   :term:`ZCML` (as opposed to imperatively or via a ``view_config``
-   decorator, or using a template directly from within a view callable)
-   also makes it possible for someone to modify the template used to
-   render a view without needing to fork your code to do so.  See
-   :ref:`extending_chapter` for more information.
+   needing to parse HTML.
 
 By default, views rendered via a template renderer return a :term:`Response`
 object which has a *status code* of ``200 OK``, and a *content-type* of