- Most references to ZCML in narrative chapters have been removed or

  redirected to ``pyramid_zcml`` locations.

20 files changed, 0 insertions, 1589 deletions

diff --git a/docs/zcml/aclauthorizationpolicy.rst b/docs/zcml/aclauthorizationpolicy.rst
deleted file mode 100644
index f09531415..000000000
--- a/docs/zcml/aclauthorizationpolicy.rst
+++ /dev/null
@@ -1,35 +0,0 @@
-.. _aclauthorizationpolicy_directive:
-
-``aclauthorizationpolicy``
---------------------------
-
-When this directive is used, authorization information is obtained
-from :term:`ACL` objects attached to :term:`resource` objects.
-
-Attributes
-~~~~~~~~~~
-
-None.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <aclauthorizationpolicy/>
-
-Alternatives
-~~~~~~~~~~~~
-
-You may create an instance of the
-:class:`pyramid.authorization.ACLAuthorizationPolicy` and pass it
-to the :class:`pyramid.config.Configurator` constructor as
-the ``authorization_policy`` argument during initial application
-configuration.
-
-See Also
-~~~~~~~~
-
-See also :ref:`authorization_policies_directives_section` and
-:ref:`security_chapter`.
diff --git a/docs/zcml/adapter.rst b/docs/zcml/adapter.rst
deleted file mode 100644
index 83cce0c39..000000000
--- a/docs/zcml/adapter.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-.. _adapter_directive:
-
-``adapter``
------------
-
-Register a :term:`Zope Component Architecture` "adapter".
-
-Attributes
-~~~~~~~~~~
-
-``factory``
-  The adapter factory (often a class).
-
-``provides``
-  The :term:`interface` that an adapter instance resulting from a
-  lookup will provide.
-
-``for``
-  Interfaces or classes to be adapted, separated by spaces,
-  e.g. ``interfaces.IFoo interfaces.IBar``.
-
-``name``
-  The adapter name.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <adapter
-     for=".foo.IFoo .bar.IBar"
-     provides=".interfaces.IMyAdapter"
-     factory=".adapters.MyAdapter"
-     />
-
-Alternatives
-~~~~~~~~~~~~
-
-Use the ``registerAdapter`` method of the ``registry`` attribute of a
-:term:`Configurator` instance during initial application setup.
-
-See Also
-~~~~~~~~
-
-None.
-
diff --git a/docs/zcml/asset.rst b/docs/zcml/asset.rst
deleted file mode 100644
index af7a6db94..000000000
--- a/docs/zcml/asset.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. _asset_directive:
-
-``asset``
----------
-
-The ``asset`` directive adds an asset override for a single
-static file/directory asset.
-
-Attributes
-~~~~~~~~~~
-
-``to_override``
-   A :term:`asset specification` specifying the asset to be
-   overridden.
-
-``override_with``
-   A :term:`asset specification` specifying the asset which
-   is used as the override.
-
-Examples
-~~~~~~~~
-
-.. topic:: Overriding a Single Asset File
-
-  .. code-block:: xml
-     :linenos:
-
-     <asset
-       to_override="some.package:templates/mytemplate.pt"
-       override_with="another.package:othertemplates/anothertemplate.pt"
-     />
-
-.. topic:: Overriding all Assets in a Package
-
-  .. code-block:: xml
-     :linenos:
-
-     <asset
-       to_override="some.package"
-       override_with="another.package"
-      />
-
-.. topic:: Overriding all Assets in a Subdirectory of a Package
-
-  .. code-block:: xml
-     :linenos:
-
-     <asset
-       to_override="some.package:templates/"
-       override_with="another.package:othertemplates/"
-      />
-
-Alternatives
-~~~~~~~~~~~~
-
-The :meth:`pyramid.config.Configurator.override_asset`
-method can be used instead of the ``resource`` ZCML directive.
-
-This directive can also be invoked as the ``resource`` ZCML directive for
-backwards compatibility purposes.
-
-See Also
-~~~~~~~~
-
-See also :ref:`asset_zcml_directive`.
diff --git a/docs/zcml/authtktauthenticationpolicy.rst b/docs/zcml/authtktauthenticationpolicy.rst
deleted file mode 100644
index 25be4186c..000000000
--- a/docs/zcml/authtktauthenticationpolicy.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-.. _authtktauthenticationpolicy_directive:
-
-``authtktauthenticationpolicy``
--------------------------------
-
-When this directive is used, authentication information is obtained
-from an :mod:`paste.auth.auth_tkt` cookie value, assumed to be set by
-a custom login form.
-
-Attributes
-~~~~~~~~~~
-
-``secret``
-    The ``secret`` is a string that will be used to sign the data
-    stored by the cookie.  It is required and has no default.
-
-``callback``
-    The ``callback`` is a Python dotted name to a function passed the
-    string representing the userid stored in the cookie and the
-    request as positional arguments.  The callback is expected to
-    return None if the user represented by the string doesn't exist or
-    a sequence of group identifiers (possibly empty) if the user does
-    exist.  If ``callback`` is None, the userid will be assumed to
-    exist with no groups.  It defaults to ``None``.
-
-``cookie_name``
-    The ``cookie_name`` is the name used for the cookie that contains
-    the user information.  It defaults to ``auth_tkt``.
-
-``secure``
-    ``secure`` is a boolean value.  If it's set to "true", the cookie
-    will only be sent back by the browser over a secure (HTTPS)
-    connection.  It defaults to "false".
-
-``include_ip``
-    ``include_ip`` is a boolean value.  If it's set to true, the
-    requesting IP address is made part of the authentication data in
-    the cookie; if the IP encoded in the cookie differs from the IP of
-    the requesting user agent, the cookie is considered invalid.  It
-    defaults to "false".
-
-``timeout``
-    ``timeout`` is an integer value.  It represents the maximum age in
-    seconds which the auth_tkt ticket will be considered valid.  If
-    ``timeout`` is specified, and ``reissue_time`` is also specified,
-    ``reissue_time`` must be a smaller value than ``timeout``.  It
-    defaults to ``None``, meaning that the ticket will be considered
-    valid forever.
-
-``reissue_time``
-    ``reissue_time`` is an integer value.  If ``reissue_time`` is
-    specified, when we encounter a cookie that is older than the
-    reissue time (in seconds), but younger that the ``timeout``, a new
-    cookie will be issued.  It defaults to ``None``, meaning that
-    authentication cookies are never reissued.  A value of ``0`` means
-    reissue a cookie in the response to every request that requires
-    authentication.
-
-``max_age``
-    ``max_age`` is the maximum age of the auth_tkt *cookie*, in
-    seconds.  This differs from ``timeout`` inasmuch as ``timeout``
-    represents the lifetime of the ticket contained in the cookie,
-    while this value represents the lifetime of the cookie itself.
-    When this value is set, the cookie's ``Max-Age`` and ``Expires``
-    settings will be set, allowing the auth_tkt cookie to last between
-    browser sessions.  It is typically nonsensical to set this to a
-    value that is lower than ``timeout`` or ``reissue_time``, although
-    it is not explicitly prevented.  It defaults to ``None``, meaning
-    (on all major browser platforms) that auth_tkt cookies will last
-    for the lifetime of the user's browser session.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <authtktauthenticationpolicy
-    secret="goshiamsosecret"
-    callback=".somemodule.somefunc"
-    cookie_name="mycookiename"
-    secure="false"
-    include_ip="false"
-    timeout="86400"
-    reissue_time="600"
-    max_age="31536000"
-    />
-
-Alternatives
-~~~~~~~~~~~~
-
-You may create an instance of the
-:class:`pyramid.authentication.AuthTktAuthenticationPolicy` and
-pass it to the :class:`pyramid.config.Configurator`
-constructor as the ``authentication_policy`` argument during initial
-application configuration.
-
-See Also
-~~~~~~~~
-
-See also :ref:`authentication_policies_directives_section` and
-:class:`pyramid.authentication.AuthTktAuthenticationPolicy`.
diff --git a/docs/zcml/configure.rst b/docs/zcml/configure.rst
deleted file mode 100644
index cab8ec204..000000000
--- a/docs/zcml/configure.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-.. _configure_directive:
-
-``configure``
--------------
-
-Because :term:`ZCML` is XML, and because XML requires a single root
-tag for each document, every ZCML file used by :app:`Pyramid` must
-contain a ``configure`` container directive, which acts as the root
-XML tag.  It is a "container" directive because its only job is to
-contain other directives.
-
-Attributes
-~~~~~~~~~~
-
-``xmlns``
-   The default XML namespace used for subdirectives.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <configure xmlns="http://pylonshq.com/pyramid">
-
-      <!-- other directives -->
-
-   </configure>
-
-.. _word_on_xml_namespaces:
-
-A Word On XML Namespaces
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Usually, the start tag of the ``<configure>`` container tag has a
-default *XML namespace* associated with it. This is usually
-``http://pylonshq.com/pyramid``, named by the ``xmlns`` attribute of
-the ``configure`` start tag.
-
-Using the ``http://pylonshq.com/pyramid`` namespace as the default XML
-namespace isn't strictly necessary; you can use a different default
-namespace as the default.  However, if you do, the declaration tags
-which are defined by :app:`Pyramid` such as the ``view`` declaration
-tag will need to be defined in such a way that the XML parser that
-:app:`Pyramid` uses knows which namespace the :mod:`pyramid` tags are
-associated with.  For example, the following files are all completely
-equivalent:
-
-.. topic:: Use of A Non-Default XML Namespace
-
-  .. code-block:: xml
-     :linenos:
-
-      <configure xmlns="http://namespaces.zope.org/zope"
-                 xmlns:pyramid="http://pylonshq.com/pyramid">
-
-        <include package="pyramid.includes" />
-
-        <pyramid:view
-           view="helloworld.hello_world"
-           />
-
-      </configure>
-
-.. topic:: Use of A Per-Tag XML Namespace Without A Default XML Namespace
-
-  .. code-block:: xml
-     :linenos:
-
-      <configure>
-
-        <include package="pyramid.includes" />
-
-        <view xmlns="http://pylonshq.com/pyramid"
-           view="helloworld.hello_world"
-           />
-
-      </configure>
-
-For more information about XML namespaces, see `this older, but simple
-XML.com article <http://www.xml.com/pub/a/1999/01/namespaces.html>`_.
-
-The conventions in this document assume that the default XML namespace
-is ``http://pylonshq.com/pyramid``.
-
-Alternatives
-~~~~~~~~~~~~
-
-None.
-
-See Also
-~~~~~~~~
-
-See also :ref:`helloworld_declarative`.
-
diff --git a/docs/zcml/default_permission.rst b/docs/zcml/default_permission.rst
deleted file mode 100644
index 54e720ea6..000000000
--- a/docs/zcml/default_permission.rst
+++ /dev/null
@@ -1,57 +0,0 @@
-.. _default_permission_directive:
-
-``default_permission``
--------------------------------
-
-Set the default permission to be used by all :term:`view
-configuration` registrations.
-
-This directive accepts a single attribute ,``name``, which should be
-used as the default permission string.  An example of a permission
-string: ``view``.  Adding a default permission makes it unnecessary to
-protect each view configuration with an explicit permission, unless
-your application policy requires some exception for a particular view.
-
-If a default permission is *not* set, views represented by view
-configuration registrations which do not explicitly declare a
-permission will be executable by entirely anonymous users (any
-authorization policy is ignored).
-
-There can be only one default permission active at a time within an
-application, thus the ``default_permission`` directive can only be
-used once in any particular set of ZCML.
-
-Attributes
-~~~~~~~~~~
-
-``name``
-    Must be a string representing a :term:`permission`,
-    e.g. ``view``.
-
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <default_permission
-    name="view"
-    />
-
-Alternatives
-~~~~~~~~~~~~
-
-Using the ``default_permission`` argument to the
-:class:`pyramid.config.Configurator` constructor can be used
-to achieve the same purpose.
-
-Using the 
-:meth:`pyramid.config.Configurator.set_default_permission`
-method can be used to achieve the same purpose when using imperative
-configuration.
-
-See Also
-~~~~~~~~
-
-See also :ref:`setting_a_default_permission`.
diff --git a/docs/zcml/forbidden.rst b/docs/zcml/forbidden.rst
deleted file mode 100644
index 70f65069e..000000000
--- a/docs/zcml/forbidden.rst
+++ /dev/null
@@ -1,78 +0,0 @@
-.. _forbidden_directive:
-
-``forbidden``
--------------
-
-When :app:`Pyramid` can't authorize execution of a view based on
-the :term:`authorization policy` in use, it invokes a :term:`forbidden
-view`.  The default forbidden response has a 401 status code and is
-very plain, but it can be overridden as necessary using the
-``forbidden`` ZCML directive.
-
-.. warning::
-
-   The ``forbidden`` ZCML directive is deprecated in :app:`Pyramid`
-   version 1.3.  Instead, you should use the :ref:`view_directive`
-   directive with a ``context`` that names the
-   :exc:`pyramid.exceptions.Forbidden` class.  See
-   :ref:`changing_the_forbidden_view` form more information.
-
-Attributes
-~~~~~~~~~~
-
-``view``
-  The :term:`dotted Python name` to a :term:`view callable`.  This
-  attribute is required unless a ``renderer`` attribute also exists.
-  If a ``renderer`` attribute exists on the directive, this attribute
-  defaults to a view that returns an empty dictionary (see
-  :ref:`views_which_use_a_renderer`).
-
-``attr``
-  The attribute of the view callable to use if ``__call__`` is not
-  correct (has the same meaning as in the context of
-  :ref:`view_directive`; see the description of ``attr``
-  there).
-
-``renderer``
-  This is either a single string term (e.g. ``json``) or a string
-  implying a path or :term:`asset specification`
-  (e.g. ``templates/views.pt``) used when the view returns a
-  non-:term:`response` object.  This attribute has the same meaning as
-  it would in the context of :ref:`view_directive`; see the
-  description of ``renderer`` there).
-
-``wrapper``
-  The :term:`view name` (*not* an object dotted name) of another view
-  declared elsewhere in ZCML (or via the ``@view_config`` decorator)
-  which will receive the response body of this view as the
-  ``request.wrapped_body`` attribute of its own request, and the
-  response returned by this view as the ``request.wrapped_response``
-  attribute of its own request.  This attribute has the same meaning
-  as it would in the context of :ref:`view_directive`; see the
-  description of ``wrapper`` there).  Note that the wrapper view
-  *should not* be protected by any permission; behavior is undefined
-  if it does.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <forbidden
-       view="helloworld.views.forbidden_view"/>
-
-Alternatives
-~~~~~~~~~~~~
-
-Use the :ref:`view_directive` directive with a ``context`` that names
-the :exc:`pyramid.exceptions.Forbidden` class.
-
-Use the :meth:`pyramid.config.Configurator.add_view` method,
-passing it a ``context`` which is the
-:exc:`pyramid.exceptions.Forbidden` class.
-
-See Also
-~~~~~~~~
-
-See also :ref:`changing_the_forbidden_view`.
diff --git a/docs/zcml/include.rst b/docs/zcml/include.rst
deleted file mode 100644
index f55caa07c..000000000
--- a/docs/zcml/include.rst
+++ /dev/null
@@ -1,71 +0,0 @@
-.. _include_directive:
-
-``include``
------------
-
-The ``include`` directive includes configuration from an external ZCML
-file.  Use of the ``include`` tag allows a user to split configuration
-across multiple ZCML files, and allows package distributors to provide
-default ZCML configuration for specific purposes which can be
-included by the integrator of the package as necessary.
-
-Attributes
-~~~~~~~~~~
-
-``package``
-   A :term:`dotted Python name` which references a Python :term:`package`.
-
-``file``
-   An absolute or relative filename which references a ZCML file.
-
-The ``package`` and ``file`` attributes can be used together or
-separately as necessary.
-
-Examples
-~~~~~~~~
-
-.. topic:: Loading the File Named ``configure.zcml`` from a Package Implicitly
-
-   .. code-block:: xml
-      :linenos:
-
-      <include package="some.package" />
-
-.. topic:: Loading the File Named ``other.zcml`` From the Current Package
-
-   .. code-block:: xml
-      :linenos:
-
-      <include file="other.zcml" />
-
-.. topic:: Loading a File From a Subdirectory of the Current Package
-
-   .. code-block:: xml
-      :linenos:
-
-      <include file="subdir/other.zcml" />
-
-.. topic:: Loading the File Named ``/absolute/path/other.zcml``
-
-   .. code-block:: xml
-      :linenos:
-
-      <include file="/absolute/path/other.zcml" />
-
-.. topic:: Loading the File Named ``other.zcml`` From a Package Explicitly
-
-   .. code-block:: xml
-      :linenos:
-
-      <include package="some.package" file="other.zcml" />
-
-Alternatives
-~~~~~~~~~~~~
-
-None.
-
-See Also
-~~~~~~~~
-
-See also :ref:`helloworld_declarative`.
-
diff --git a/docs/zcml/localenegotiator.rst b/docs/zcml/localenegotiator.rst
deleted file mode 100644
index c90e649f6..000000000
--- a/docs/zcml/localenegotiator.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-.. _localenegotiator_directive:
-
-``localenegotiator``
---------------------
-
-Set the :term:`locale negotiator` for the current configurator to
-support localization of text.
-
-Attributes
-~~~~~~~~~~
-
-``negotiator``
-
-  The :term:`dotted Python name` to a :term:`locale negotiator`
-  implementation.  This attribute is required.  If it begins with a
-  dot (``.``), the name will be considered relative to the directory
-  in which the ZCML file which contains this directive lives.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <localenegotiator
-     negotiator="some.package.module.my_locale_negotiator"
-     />
-
-Alternatives
-~~~~~~~~~~~~
-
-Use :meth:`pyramid.config.Configurator.set_locale_negotiator`
-method instance during initial application setup.
-
-See Also
-~~~~~~~~
-
-See also :ref:`activating_translation`.
-
diff --git a/docs/zcml/notfound.rst b/docs/zcml/notfound.rst
deleted file mode 100644
index 739eccd49..000000000
--- a/docs/zcml/notfound.rst
+++ /dev/null
@@ -1,78 +0,0 @@
-.. _notfound_directive:
-
-``notfound``
-------------
-
-.. warning::
-
-   The ``notfound`` ZCML directive is deprecated in :app:`Pyramid`
-   version 1.0.  Instead, you should use the :ref:`view_directive`
-   directive with a ``context`` that names the
-   :exc:`pyramid.exceptions.NotFound` class.  See
-   :ref:`changing_the_notfound_view` form more information.
-
-When :app:`Pyramid` can't map a URL to view code, it invokes a
-:term:`not found view`.  The default not found view is very plain, but
-the view callable used can be configured via the ``notfound`` ZCML
-tag.
-
-Attributes
-~~~~~~~~~~
-
-``view``
-  The :term:`dotted Python name` to a :term:`view callable`.  This
-  attribute is required unless a ``renderer`` attribute also exists.
-  If a ``renderer`` attribute exists on the directive, this attribute
-  defaults to a view that returns an empty dictionary (see
-  :ref:`views_which_use_a_renderer`).
-
-``attr``
-  The attribute of the view callable to use if ``__call__`` is not
-  correct (has the same meaning as in the context of
-  :ref:`view_directive`; see the description of ``attr``
-  there).
-
-``renderer``
-  This is either a single string term (e.g. ``json``) or a string
-  implying a path or :term:`asset specification`
-  (e.g. ``templates/views.pt``) used when the view returns a
-  non-:term:`response` object.  This attribute has the same meaning as
-  it would in the context of :ref:`view_directive`; see the
-  description of ``renderer`` there).
-
-``wrapper``
-  The :term:`view name` (*not* an object dotted name) of another view
-  declared elsewhere in ZCML (or via the ``@view_config`` decorator)
-  which will receive the response body of this view as the
-  ``request.wrapped_body`` attribute of its own request, and the
-  response returned by this view as the ``request.wrapped_response``
-  attribute of its own request.  This attribute has the same meaning
-  as it would in the context of :ref:`view_directive`; see
-  the description of ``wrapper`` there).  Note that the wrapper view
-  *should not* be protected by any permission; behavior is undefined
-  if it does.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <notfound 
-       view="helloworld.views.notfound_view"/>
-
-Alternatives
-~~~~~~~~~~~~
-
-Use the :ref:`view_directive` directive with a ``context`` that names
-the :exc:`pyramid.exceptions.NotFound` class.
-
-Use the :meth:`pyramid.config.Configurator.add_view` method,
-passing it a ``context`` which is the
-:exc:`pyramid.exceptions.NotFound` class.
-
-See Also
-~~~~~~~~
-
-See also :ref:`changing_the_notfound_view`.
-
diff --git a/docs/zcml/remoteuserauthenticationpolicy.rst b/docs/zcml/remoteuserauthenticationpolicy.rst
deleted file mode 100644
index 56e73ee7a..000000000
--- a/docs/zcml/remoteuserauthenticationpolicy.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-.. _remoteuserauthenticationpolicy_directive:
-
-``remoteuserauthenticationpolicy``
-----------------------------------
-
-When this directive is used, authentication information is obtained
-from a ``REMOTE_USER`` key in the WSGI environment, assumed to
-be set by a WSGI server or an upstream middleware component.
-
-Attributes
-~~~~~~~~~~
-
-``environ_key``
-    The ``environ_key`` is the name that will be used to obtain the
-    remote user value from the WSGI environment.  It defaults to
-    ``REMOTE_USER``.
-
-``callback``
-    The ``callback`` is a Python dotted name to a function passed the
-    string representing the remote user and the request as positional
-    arguments.  The callback is expected to return None if the user
-    represented by the string doesn't exist or a sequence of group
-    identifiers (possibly empty) if the user does exist.  If
-    ``callback`` is None, the userid will be assumed to exist with no
-    groups.  It defaults to ``None``.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <remoteuserauthenticationpolicy
-    environ_key="REMOTE_USER"
-    callback=".somemodule.somefunc"
-    />
-
-Alternatives
-~~~~~~~~~~~~
-
-You may create an instance of the
-:class:`pyramid.authentication.RemoteUserAuthenticationPolicy` and
-pass it to the :class:`pyramid.config.Configurator`
-constructor as the ``authentication_policy`` argument during initial
-application configuration.
-
-See Also
-~~~~~~~~
-
-See also :ref:`authentication_policies_directives_section` and
-:class:`pyramid.authentication.RemoteUserAuthenticationPolicy`.
diff --git a/docs/zcml/renderer.rst b/docs/zcml/renderer.rst
deleted file mode 100644
index c7beead32..000000000
--- a/docs/zcml/renderer.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-.. _renderer_directive:
-
-``renderer``
-------------
-
-The ``renderer`` ZCML directive can be used to override an existing
-existing :term:`renderer` or to add a new renderer.
-
-Attributes
-~~~~~~~~~~
-
-``factory``
-    A :term:`dotted Python name` referencing a callable object that
-    accepts a renderer name and returns a :term:`renderer` object.
-
-``name``
-   The renderer name, which is a string.
-
-Examples
-~~~~~~~~
-
-.. topic:: Registering a Non-Template Renderer
-
-   .. code-block:: xml
-      :linenos:
-
-      <renderer
-         factory="some.renderer"
-         name="mynewrenderer"
-         />
-
-.. topic:: Registering a Template Renderer
-
-   .. code-block:: xml
-      :linenos:
-
-      <renderer
-         factory="some.jinja2.renderer"
-         name=".jinja2"
-         />
-
-Alternatives
-~~~~~~~~~~~~
-
-The :meth:`pyramid.config.Configurator.add_renderer` method
-is equivalent to the ``renderer`` ZCML directive.
-
-See Also
-~~~~~~~~
-
-See also :ref:`adding_and_overriding_renderers`.
diff --git a/docs/zcml/repozewho1authenticationpolicy.rst b/docs/zcml/repozewho1authenticationpolicy.rst
deleted file mode 100644
index 11907ce31..000000000
--- a/docs/zcml/repozewho1authenticationpolicy.rst
+++ /dev/null
@@ -1,53 +0,0 @@
-.. _repozewho1authenticationpolicy_directive:
-
-``repozewho1authenticationpolicy``
-----------------------------------
-
-When this directive is used, authentication information is obtained
-from a ``repoze.who.identity`` key in the WSGI environment, assumed to
-be set by :term:`repoze.who` middleware.
-
-Attributes
-~~~~~~~~~~
-
-``identifier_name``
-    The ``identifier_name`` controls the name used to look up the
-    :term:`repoze.who` "identifier" plugin within
-    ``request.environ['repoze.who.plugins']`` which is used by this
-    policy to "remember" and "forget" credentials.  It defaults to
-    ``auth_tkt``.
-
-``callback``
-    The ``callback`` is a Python dotted name to a function passed the
-    repoze.who identity and the request as positional arguments.  The
-    callback is expected to return None if the user represented by the
-    identity doesn't exist or a sequence of group identifiers
-    (possibly empty) if the user does exist.  If ``callback`` is None,
-    the userid will be assumed to exist with no groups.  It defaults
-    to ``None``.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <repozewho1authenticationpolicy
-    identifier_name="auth_tkt"
-    callback=".somemodule.somefunc"
-    />
-
-Alternatives
-~~~~~~~~~~~~
-
-You may create an instance of the
-:class:`pyramid.authentication.RepozeWho1AuthenticationPolicy` and
-pass it to the :class:`pyramid.config.Configurator`
-constructor as the ``authentication_policy`` argument during initial
-application configuration.
-
-See Also
-~~~~~~~~
-
-See also :ref:`authentication_policies_directives_section` and
-:class:`pyramid.authentication.RepozeWho1AuthenticationPolicy`.
diff --git a/docs/zcml/route.rst b/docs/zcml/route.rst
deleted file mode 100644
index 0f94fa11b..000000000
--- a/docs/zcml/route.rst
+++ /dev/null
@@ -1,223 +0,0 @@
-.. _route_directive:
-
-``route``
----------
-
-The ``route`` directive adds a single :term:`route configuration` to
-the :term:`application registry`.
-
-Attributes
-~~~~~~~~~~
-
-``pattern``
-  The pattern of the route e.g. ``ideas/{idea}``.  This attribute is
-  required.  See :ref:`route_pattern_syntax` for information
-  about the syntax of route patterns.
-
-  .. note:: For backwards compatibility purposes, the ``path``
-     attribute can also be used instead of ``pattern``.
-
-``name``
-  The name of the route, e.g. ``myroute``.  This attribute is
-  required.  It must be unique among all defined routes in a given
-  configuration.
-
-``factory``
-  The :term:`dotted Python name` to a function that will generate a
-  :app:`Pyramid` context object when this route matches.
-  e.g. ``mypackage.resources.MyResource``.  If this argument is not
-  specified, a default root factory will be used.
-
-``view``
-  The :term:`dotted Python name` to a function that will be used as a
-  view callable when this route matches.
-  e.g. ``mypackage.views.my_view``.
-
-``xhr``
-  This value should be either ``True`` or ``False``.  If this value is
-  specified and is ``True``, the :term:`request` must possess an
-  ``HTTP_X_REQUESTED_WITH`` (aka ``X-Requested-With``) header for this
-  route to match.  This is useful for detecting AJAX requests issued
-  from jQuery, Prototype and other Javascript libraries.  If this
-  predicate returns false, route matching continues.
-
-``traverse``
-  If you would like to cause the :term:`context` to be something other
-  than the :term:`root` object when this route matches, you can spell
-  a traversal pattern as the ``traverse`` argument.  This traversal
-  pattern will be used as the traversal path: traversal will begin at
-  the root object implied by this route (either the global root, or
-  the object returned by the ``factory`` associated with this route).
-
-  The syntax of the ``traverse`` argument is the same as it is for
-  ``pattern``. For example, if the ``pattern`` provided to the
-  ``route`` directive is ``articles/{article}/edit``, and the
-  ``traverse`` argument provided to the ``route`` directive is
-  ``/{article}``, when a request comes in that causes the route to
-  match in such a way that the ``article`` match value is '1' (when
-  the request URI is ``/articles/1/edit``), the traversal path will be
-  generated as ``/1``.  This means that the root object's
-  ``__getitem__`` will be called with the name ``1`` during the
-  traversal phase.  If the ``1`` object exists, it will become the
-  :term:`context` of the request.  :ref:`traversal_chapter` has more
-  information about traversal.
-
-  If the traversal path contains segment marker names which are not
-  present in the ``pattern`` argument, a runtime error will occur.
-  The ``traverse`` pattern should not contain segment markers that do
-  not exist in the ``pattern``.
-
-  A similar combining of routing and traversal is available when a
-  route is matched which contains a ``*traverse`` remainder marker in
-  its ``pattern`` (see :ref:`using_traverse_in_a_route_pattern`).  The
-  ``traverse`` argument to the ``route`` directive allows you to
-  associate route patterns with an arbitrary traversal path without
-  using a a ``*traverse`` remainder marker; instead you can use other
-  match information.
-
-  Note that the ``traverse`` argument to the ``route`` directive is
-  ignored when attached to a route that has a ``*traverse`` remainder
-  marker in its pattern.
-
-``request_method``
-  A string representing an HTTP method name, e.g. ``GET``, ``POST``,
-  ``HEAD``, ``DELETE``, ``PUT``.  If this argument is not specified,
-  this route will match if the request has *any* request method.  If
-  this predicate returns false, route matching continues.
-
-``path_info``
-  The value of this attribute represents a regular expression pattern
-  that will be tested against the ``PATH_INFO`` WSGI environment
-  variable.  If the regex matches, this predicate will be true.  If
-  this predicate returns false, route matching continues.
-
-``request_param``
-  This value can be any string.  A view declaration with this
-  attribute ensures that the associated route will only match when the
-  request has a key in the ``request.params`` dictionary (an HTTP
-  ``GET`` or ``POST`` variable) that has a name which matches the
-  supplied value.  If the value supplied to the attribute has a ``=``
-  sign in it, e.g. ``request_params="foo=123"``, then the key
-  (``foo``) must both exist in the ``request.params`` dictionary, and
-  the value must match the right hand side of the expression (``123``)
-  for the route to "match" the current request.  If this predicate
-  returns false, route matching continues.
-
-``header``
-  The value of this attribute represents an HTTP header name or a
-  header name/value pair.  If the value contains a ``:`` (colon), it
-  will be considered a name/value pair (e.g. ``User-Agent:Mozilla/.*``
-  or ``Host:localhost``).  The *value* of an attribute that represent
-  a name/value pair should be a regular expression.  If the value does
-  not contain a colon, the entire value will be considered to be the
-  header name (e.g. ``If-Modified-Since``).  If the value evaluates to
-  a header name only without a value, the header specified by the name
-  must be present in the request for this predicate to be true.  If
-  the value evaluates to a header name/value pair, the header
-  specified by the name must be present in the request *and* the
-  regular expression specified as the value must match the header
-  value.  Whether or not the value represents a header name or a
-  header name/value pair, the case of the header name is not
-  significant.  If this predicate returns false, route matching
-  continues.
-
-``accept``
-  The value of this attribute represents a match query for one or more
-  mimetypes in the ``Accept`` HTTP request header.  If this value is
-  specified, it must be in one of the following forms: a mimetype
-  match token in the form ``text/plain``, a wildcard mimetype match
-  token in the form ``text/*`` or a match-all wildcard mimetype match
-  token in the form ``*/*``.  If any of the forms matches the
-  ``Accept`` header of the request, this predicate will be true.  If
-  this predicate returns false, route matching continues.
-
-``custom_predicates``
-
-  This value should be a sequence of references to custom predicate
-  callables.  Use custom predicates when no set of predefined
-  predicates does what you need.  Custom predicates can be combined
-  with predefined predicates as necessary.  Each custom predicate
-  callable should accept two arguments: ``info`` and ``request``
-  and should return either ``True`` or ``False`` after doing arbitrary
-  evaluation of the info and/or the request.  If all custom and
-  non-custom predicate callables return ``True`` the associated route
-  will be considered viable for a given request.  If any predicate
-  callable returns ``False``, route matching continues.  Note that the
-  value ``info`` passed to a custom route predicate is a dictionary
-  containing matching information; see :ref:`custom_route_predicates`
-  for more information about ``info``.
-
-``view_context``
-  The :term:`dotted Python name` to a class or an interface that the
-  :term:`context` of the view should match for the view named by the
-  route to be used.  This attribute is only useful if the ``view``
-  attribute is used.  If this attribute is not specified, the default
-  (``None``) will be used.
-
-  If the ``view`` attribute is not provided, this attribute has no
-  effect.
-
-  This attribute can also be spelled as ``view_for`` or ``for_``;
-  these are valid older spellings.
-
-``view_permission``
-  The permission name required to invoke the view associated with this
-  route.  e.g. ``edit``. (see :ref:`using_security_with_urldispatch`
-  for more information about permissions).
-
-  If the ``view`` attribute is not provided, this attribute has no
-  effect.
-
-  This attribute can also be spelled as ``permission``.
-
-``view_renderer``
-  This is either a single string term (e.g. ``json``) or a string
-  implying a path or :term:`asset specification`
-  (e.g. ``templates/views.pt``).  If the renderer value is a single
-  term (does not contain a dot ``.``), the specified term will be used
-  to look up a renderer implementation, and that renderer
-  implementation will be used to construct a response from the view
-  return value.  If the renderer term contains a dot (``.``), the
-  specified term will be treated as a path, and the filename extension
-  of the last element in the path will be used to look up the renderer
-  implementation, which will be passed the full path.  The renderer
-  implementation will be used to construct a response from the view
-  return value.  See :ref:`views_which_use_a_renderer` for more
-  information.
-
-  If the ``view`` attribute is not provided, this attribute has no
-  effect.
-
-  This attribute can also be spelled as ``renderer``.
-
-``view_attr``
-  The view machinery defaults to using the ``__call__`` method of the
-  view callable (or the function itself, if the view callable is a
-  function) to obtain a response dictionary.  The ``attr`` value allows
-  you to vary the method attribute used to obtain the response.  For
-  example, if your view was a class, and the class has a method named
-  ``index`` and you wanted to use this method instead of the class'
-  ``__call__`` method to return the response, you'd say
-  ``attr="index"`` in the view configuration for the view.  This is
-  most useful when the view definition is a class.
-
-  If the ``view`` attribute is not provided, this attribute has no
-  effect.
-
-``use_global_views``
-  When a request matches this route, and view lookup cannot find a view
-  which has a 'route_name' predicate argument that matches the route,
-  try to fall back to using a view that otherwise matches the context,
-  request, and view name (but does not match the route name predicate).
-
-Alternatives
-~~~~~~~~~~~~
-
-You can also add a :term:`route configuration` via:
-
-- Using the :meth:`pyramid.config.Configurator.add_route` method.
-
-See Also
-~~~~~~~~
-
-See also :ref:`urldispatch_chapter`.
diff --git a/docs/zcml/scan.rst b/docs/zcml/scan.rst
deleted file mode 100644
index df2cdd281..000000000
--- a/docs/zcml/scan.rst
+++ /dev/null
@@ -1,34 +0,0 @@
-.. _scan_directive:
-
-``scan``
---------
-
-To make use of :term:`configuration decoration` decorators, you must
-perform a :term:`scan`.  A scan finds these decorators in code.  The
-``scan`` ZCML directive tells :app:`Pyramid` to begin such a scan.
-
-Attributes
-~~~~~~~~~~
-
-``package``
-    The package to scan or the single dot (``.``), meaning the
-    "current" package (the package in which the ZCML file lives).
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-    
-   <scan package="."/>
-
-Alternatives
-~~~~~~~~~~~~
-
-The :meth:`pyramid.config.Configurator.scan` method performs
-the same job as the ``scan`` ZCML directive.
-
-See Also
-~~~~~~~~
-
-See also :ref:`mapping_views_using_a_decorator_section`.
diff --git a/docs/zcml/static.rst b/docs/zcml/static.rst
deleted file mode 100644
index 9538d18f0..000000000
--- a/docs/zcml/static.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-.. _static_directive:
-
-``static``
-----------
-
-Use of the ``static`` ZCML directive or allows you to serve static
-resources (such as JavaScript and CSS files) within a
-:app:`Pyramid` application. This mechanism makes static files
-available at a name relative to the application root URL.
-
-Attributes
-~~~~~~~~~~
-
-``name``
-  The (application-root-relative) URL prefix of the static directory.
-  For example, to serve static files from ``/static`` in most
-  applications, you would provide a ``name`` of ``static``.
-
-``path``
-  A path to a directory on disk where the static files live.  This
-  path may either be 1) absolute (e.g. ``/foo/bar/baz``) 2)
-  Python-package-relative (e.g. (``packagename:foo/bar/baz``) or 3)
-  relative to the package directory in which the ZCML file which
-  contains the directive (e.g. ``foo/bar/baz``).
-
-``cache_max_age``
-  The number of seconds that the static resource can be cached, as
-  represented in the returned response's ``Expires`` and/or
-  ``Cache-Control`` headers, when any static file is served from this
-  directive.  This defaults to 3600 (5 minutes).  Optional.
-
-``permission``
-  Used to specify the :term:`permission` required by a user to execute
-  this static view.  This value defaults to the string
-  ``__no_permission_required__``.  The ``__no_permission_required__``
-  string is a special sentinel which indicates that, even if a
-  :term:`default permission` exists for the current application, the
-  static view should be renderered to completely anonymous users.
-  This default value is permissive because, in most web apps, static
-  resources seldom need protection from viewing.  You should use this
-  option only if you register a static view which points at a
-  directory that contains resources which should be shown only if the
-  calling user has (according to the :term:`authorization policy`) a
-  particular permission.
-
-Examples
-~~~~~~~~
-
-.. topic:: Serving Static Files from an Absolute Path
-
-   .. code-block:: xml
-      :linenos:
-
-      <static
-         name="static"
-         path="/var/www/static"
-         />
-
-.. topic:: Serving Static Files from a Package-Relative Path
-
-   .. code-block:: xml
-      :linenos:
-
-      <static
-         name="static"
-         path="some_package:a/b/c/static"
-         />
-
-.. topic:: Serving Static Files from a Current-Package-Relative Path
-
-   .. code-block:: xml
-      :linenos:
-
-      <static
-         name="static"
-         path="static_files"
-         />
-
-Alternatives
-~~~~~~~~~~~~
-
-:meth:`pyramid.config.Configurator.add_static_view` can also
-be used to add a static view.
-
-See Also
-~~~~~~~~
-
-See also :ref:`static_resources_section` and
-:ref:`generating_static_resource_urls`.
diff --git a/docs/zcml/subscriber.rst b/docs/zcml/subscriber.rst
deleted file mode 100644
index 25c4abf2e..000000000
--- a/docs/zcml/subscriber.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-.. _subscriber_directive:
-
-``subscriber``
---------------
-
-The ``subscriber`` ZCML directive configures an :term:`subscriber`
-callable to listen for events broadcast by the :app:`Pyramid` web
-framework.
-
-Attributes
-~~~~~~~~~~
-
-``for``
-   The class or :term:`interface` that you are subscribing the listener for,
-   e.g. :class:`pyramid.events.NewRequest`.  Registering a subscriber for a
-   specific class or interface limits the event types that the subscriber
-   will receive to those specified by the interface or class.  Default:
-   ``zope.interface.Interface`` (implying *any* event type).
-
-``handler``
-   A :term:`dotted Python name` which references an event handler
-   callable.  The callable should accept a single argument: ``event``.
-   The return value of the callable is ignored.
-
-Examples
-~~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <subscriber
-      for="pyramid.events.NewRequest"
-      handler=".subscribers.handle_new_request"
-    />
-
-Alternatives
-~~~~~~~~~~~~
-
-You can also register an event listener by using the
-:meth:`pyramid.config.Configurator.add_subscriber` method.
-
-See Also
-~~~~~~~~
-
-See also :ref:`events_chapter`.
diff --git a/docs/zcml/translationdir.rst b/docs/zcml/translationdir.rst
deleted file mode 100644
index 5cf615d26..000000000
--- a/docs/zcml/translationdir.rst
+++ /dev/null
@@ -1,64 +0,0 @@
-.. _translationdir_directive:
-
-``translationdir``
-------------------
-
-Add a :term:`gettext` :term:`translation directory` to the current
-configuration for use in localization of text.
-
-Attributes
-~~~~~~~~~~
-
-``dir``
-  The path to the translation directory.  This path may either be 1)
-  absolute (e.g. ``/foo/bar/baz``) 2) Python-package-relative
-  (e.g. ``packagename:foo/bar/baz``) or 3) relative to the package
-  directory in which the ZCML file which contains the directive
-  (e.g. ``foo/bar/baz``).
-
-Example 1
-~~~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <!-- relative to configure.zcml file -->
-
-   <translationdir
-     dir="locale"
-     />
-
-Example 2
-~~~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <!-- relative to another package -->
-
-   <translationdir
-     dir="another.package:locale"
-     />
-
-Example 3
-~~~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <!-- an absolute directory name -->
-
-   <translationdir
-     dir="/usr/share/locale"
-     />
-
-Alternatives
-~~~~~~~~~~~~
-
-Use :meth:`pyramid.config.Configurator.add_translation_dirs`
-method instance during initial application setup.
-
-See Also
-~~~~~~~~
-
-See also :ref:`activating_translation`.
diff --git a/docs/zcml/utility.rst b/docs/zcml/utility.rst
deleted file mode 100644
index 1341dfb83..000000000
--- a/docs/zcml/utility.rst
+++ /dev/null
@@ -1,46 +0,0 @@
-.. _utility_directive:
-
-``utility``
------------
-
-Register a :term:`Zope Component Architecture` "utility".
-
-Attributes
-~~~~~~~~~~
-
-``component``
-  The utility component (cannot be specified if ``factory`` is
-  specified).
-
-``factory``
-  A factory that creates a component (cannot be specified if
-  ``component`` is specified).
-
-``provides``
-  The :term:`interface` that an utility instance resulting from a
-  lookup will provide.
-
-``name``
-  The utility name.
-
-Example
-~~~~~~~
-
-.. code-block:: xml
-   :linenos:
-
-   <utility
-     provides=".interfaces.IMyUtility"
-     component=".utilities.MyUtility"
-     />
-
-Alternatives
-~~~~~~~~~~~~
-
-Use the ``registerUtility`` method of the ``registry`` attribute of a
-:term:`Configurator` instance during initial application setup.
-
-See Also
-~~~~~~~~
-
-None.
diff --git a/docs/zcml/view.rst b/docs/zcml/view.rst
deleted file mode 100644
index ba5c7bf23..000000000
--- a/docs/zcml/view.rst
+++ /dev/null
@@ -1,266 +0,0 @@
-.. _view_directive:
-
-``view``
---------
-
-A ``view`` declaration directs :app:`Pyramid` to create a single
-:term:`view configuration` registration in the current
-:term:`application registry`.
-
-The ``view`` ZCML directive has many possible attributes.  Some of the
-attributes are descriptive or influence rendering.  Other attributes
-are :term:`predicate` attributes, meaning that they imply an
-evaluation to true or false when view lookup is performed.
-
-*All* predicates named in a view configuration must evaluate to true
-in order for the view callable it names to be considered "invokable"
-for a given request.  See :ref:`view_lookup` for a description of how
-a view configuration matches (or doesn't match) during a request.
-
-The possible attributes of the ``view`` ZCML directive are described
-below.  They are divided into predicate and non-predicate categories.
-
-Attributes
-~~~~~~~~~~
-
-Non-Predicate Attributes
-########################
-
-``view``
-  The :term:`dotted Python name` to a :term:`view callable`.  This
-  attribute is required unless a ``renderer`` attribute also exists.
-  If a ``renderer`` attribute exists on the directive, this attribute
-  defaults to a view that returns an empty dictionary (see
-  :ref:`views_which_use_a_renderer`).
-
-``permission``
-  The name of a *permission* that the user must possess in order to
-  call the view.  See :ref:`view_security_section` for more
-  information about view security and permissions.
-
-``attr``
-  The view machinery defaults to using the ``__call__`` method of the
-  view callable (or the function itself, if the view callable is a
-  function) to obtain a response dictionary.  The ``attr`` value
-  allows you to vary the method attribute used to obtain the response.
-  For example, if your view was a class, and the class has a method
-  named ``index`` and you wanted to use this method instead of the
-  class' ``__call__`` method to return the response, you'd say
-  ``attr="index"`` in the view configuration for the view.  This is
-  most useful when the view definition is a class.
-
-``renderer``
-  This is either a single string term (e.g. ``json``) or a string
-  implying a path or :term:`asset specification`
-  (e.g. ``templates/views.pt``).  If the renderer value is a single
-  term (does not contain a dot ``.``), the specified term will be used
-  to look up a renderer implementation, and that renderer
-  implementation will be used to construct a response from the view
-  return value.  If the renderer term contains a dot (``.``), the
-  specified term will be treated as a path, and the filename extension
-  of the last element in the path will be used to look up the renderer
-  implementation, which will be passed the full path.  The renderer
-  implementation will be used to construct a response from the view
-  return value.
-
-  Note that if the view itself returns a response (see
-  :ref:`the_response`), the specified renderer implementation is never
-  called.
-
-  When the renderer is a path, although a path is usually just a
-  simple relative pathname (e.g. ``templates/foo.pt``, implying that a
-  template named "foo.pt" is in the "templates" directory relative to
-  the directory in which the ZCML file is defined), a path can be
-  absolute, starting with a slash on UNIX or a drive letter prefix on
-  Windows.  The path can alternately be a :term:`asset
-  specification` in the form
-  ``some.dotted.package_name:relative/path``, making it possible to
-  address template assets which live in a separate package.
-
-  The ``renderer`` attribute is optional.  If it is not defined, the
-  "null" renderer is assumed (no rendering is performed and the value
-  is passed back to the upstream BFG machinery unmolested).
-
-``wrapper``
-  The :term:`view name` (*not* an object dotted name) of another view
-  declared elsewhere in ZCML (or via the ``@view_config`` decorator)
-  which will receive the response body of this view as the
-  ``request.wrapped_body`` attribute of its own request, and the
-  response returned by this view as the ``request.wrapped_response``
-  attribute of its own request.  Using a wrapper makes it possible to
-  "chain" views together to form a composite response.  The response
-  of the outermost wrapper view will be returned to the user.  The
-  wrapper view will be found as any view is found: see
-  :ref:`view_lookup`.  The "best" wrapper view will be found based on
-  the lookup ordering: "under the hood" this wrapper view is looked up
-  via ``pyramid.view.render_view_to_response(context, request,
-  'wrapper_viewname')``. The context and request of a wrapper view is
-  the same context and request of the inner view.  If this attribute
-  is unspecified, no view wrapping is done.
-
-Predicate Attributes
-####################
-
-``name``
-  The *view name*.  Read the :ref:`traversal_chapter` to understand
-  the concept of a view name.
-
-``context``
-  A :term:`dotted Python name` representing the Python class that the
-  :term:`context` must be an instance of, *or* the :term:`interface`
-  that the :term:`context` must provide in order for this view to be
-  found and called.  This predicate is true when the :term:`context`
-  is an instance of the represented class or if the :term:`context`
-  provides the represented interface; it is otherwise false.  An
-  alternate name for this attribute is ``for`` (this is an older
-  spelling).
-
-``route_name``
-  *This attribute services an advanced feature that isn't often used
-  unless you want to perform traversal after a route has matched.*
-  This value must match the ``name`` of a ``<route>`` declaration (see
-  :ref:`urldispatch_chapter`) that must match before this view will be
-  called.  Note that the ``route`` configuration referred to by
-  ``route_name`` usually has a ``*traverse`` token in the value of its
-  ``path``, representing a part of the path that will be used by
-  traversal against the result of the route's :term:`root factory`.
-  See :ref:`hybrid_chapter` for more information on using this
-  advanced feature.
-
-``request_type``
-  This value should be a :term:`dotted Python name` string
-  representing the :term:`interface` that the :term:`request` must
-  have in order for this view to be found and called.  The presence of
-  this attribute is largely for backwards compatibility with
-  older iterations of this framework.  
-
-``request_method``
-  This value can either be one of the strings 'GET', 'POST', 'PUT',
-  'DELETE', or 'HEAD' representing an HTTP ``REQUEST_METHOD``.  A view
-  declaration with this attribute ensures that the view will only be
-  called when the request's ``method`` (aka ``REQUEST_METHOD``) string
-  matches the supplied value.
-
-``request_param``
-  This value can be any string.  A view declaration with this
-  attribute ensures that the view will only be called when the request
-  has a key in the ``request.params`` dictionary (an HTTP ``GET`` or
-  ``POST`` variable) that has a name which matches the supplied value.
-  If the value supplied to the attribute has a ``=`` sign in it,
-  e.g. ``request_params="foo=123"``, then the key (``foo``) must both
-  exist in the ``request.params`` dictionary, and the value must match
-  the right hand side of the expression (``123``) for the view to
-  "match" the current request.
-
-``containment``
-  This value should be a :term:`dotted Python name` string
-  representing the class that a graph traversal parent object of the
-  :term:`context` must be an instance of (or :term:`interface` that a
-  parent object must provide) in order for this view to be found and
-  called.  Your resources must be "location-aware" to use this feature.
-  See :ref:`location_aware` for more information about
-  location-awareness.
-
-``xhr``
-  This value should be either ``True`` or ``False``.  If this value is
-  specified and is ``True``, the :term:`request` must possess an
-  ``HTTP_X_REQUESTED_WITH`` (aka ``X-Requested-With``) header that has
-  the value ``XMLHttpRequest`` for this view to be found and called.
-  This is useful for detecting AJAX requests issued from jQuery,
-  Prototype and other Javascript libraries.
-
-``accept``
-  The value of this attribute represents a match query for one or more
-  mimetypes in the ``Accept`` HTTP request header.  If this value is
-  specified, it must be in one of the following forms: a mimetype
-  match token in the form ``text/plain``, a wildcard mimetype match
-  token in the form ``text/*`` or a match-all wildcard mimetype match
-  token in the form ``*/*``.  If any of the forms matches the
-  ``Accept`` header of the request, this predicate will be true.
-
-``header``
-  The value of this attribute represents an HTTP header name or a
-  header name/value pair.  If the value contains a ``:`` (colon), it
-  will be considered a name/value pair (e.g. ``User-Agent:Mozilla/.*``
-  or ``Host:localhost``).  The *value* of an attribute that represent
-  a name/value pair should be a regular expression.  If the value does
-  not contain a colon, the entire value will be considered to be the
-  header name (e.g. ``If-Modified-Since``).  If the value evaluates to
-  a header name only without a value, the header specified by the name
-  must be present in the request for this predicate to be true.  If
-  the value evaluates to a header name/value pair, the header
-  specified by the name must be present in the request *and* the
-  regular expression specified as the value must match the header
-  value.  Whether or not the value represents a header name or a
-  header name/value pair, the case of the header name is not
-  significant.
-
-``path_info``
-  The value of this attribute represents a regular expression pattern
-  that will be tested against the ``PATH_INFO`` WSGI environment
-  variable.  If the regex matches, this predicate will be true.
-
-``custom_predicates``
-  This value should be a sequence of references to custom predicate
-  callables (e.g. ``dotted.name.one dotted.name.two``, if used in
-  ZCML; a :term:`dotted Python name` to each callable separated by a
-  space).  Use custom predicates when no set of predefined predicates
-  do what you need.  Custom predicates can be combined with predefined
-  predicates as necessary.  Each custom predicate callable should
-  accept two arguments: ``context`` and ``request`` and should return
-  either ``True`` or ``False`` after doing arbitrary evaluation of the
-  context and/or the request.  If all callables return ``True``, the
-  associated view callable will be considered viable for a given
-  request.
-
-``decorator``
-  A :term:`dotted Python name` to a function that will be used to decorate
-  the registered :term:`view callable`.  The decorator function will be
-  called with the view callable as a single argument.  The view callable it
-  is passed will accept ``(context, request)``.  The decorator must return a
-  replacement view callable which also accepts ``(context, request)``.
-
-``mapper``
-  A :term:`dotted Python name` which refers to a :term:`view mapper`, or
-  ``None``.  By default it is ``None``, which indicates that the view should
-  use the default view mapper.  This plug-point is useful for Pyramid
-  extension developers, but it's not very useful for 'civilians' who are just
-  developing stock Pyramid applications.
-
-Examples
-~~~~~~~~
-
-.. topic:: Registering A Default View for a Class
-
-  .. code-block:: xml
-     :linenos:
-
-        <view
-           context=".resources.MyResource"
-           view=".views.hello_world"
-         />
-
-.. topic:: Registering A View With a Predicate
-
-  .. code-block:: xml
-     :linenos:
-
-        <view
-           context=".resources.MyResource"
-           view=".views.hello_world_post"
-           request_method="POST"
-         />
-
-Alternatives
-~~~~~~~~~~~~
-
-You can also add a :term:`view configuration` via:
-
-- Using the :class:`pyramid.view.view_config` class as a decorator.
-
-- Using the :meth:`pyramid.config.Configurator.add_view` method.
-
-See Also
-~~~~~~~~
-
-See also :ref:`views_chapter`.