clean up inappropriate discussions of ZCML

Chris McDonough

2011-08-29 55ce9d632f828d285360c1abee9f56042243cac9

clean up inappropriate discussions of ZCML

 docs/designdefense.rst

@@ -61,10 +61,11 @@
dispatch`).  After the initial public release of BFG, as time went on,
features were added to support people allergic to various Zope-isms in the
system, such as the ability to configure the application using
:term:`imperative configuration` rather than solely using :term:`ZCML`, and
the elimination of the required use of :term:`interface` objects.  It soon
became clear that we had a system that was very generic, and was beginning to
appeal to non-Zope users as well as ex-Zope users.
:term:`imperative configuration` and :term:`configuration decoration` rather
than solely using :term:`ZCML`, and the elimination of the required use of
:term:`interface` objects.  It soon became clear that we had a system that
was very generic, and was beginning to appeal to non-Zope users as well as
ex-Zope users.

As the result of this generalization, it became obvious BFG shared 90% of its
featureset with the featureset of Pylons 1, and thus had a very similar
@@ -323,9 +324,9 @@

- Composability.  A ZCA component registry can be populated imperatively, or
  there's an existing mechanism to populate a registry via the use of a
  configuration file (ZCML, via :term:`pyramid_zcml`).  We didn't need to
  write a frontend from scratch to make use of configuration-file-driven
  registry population.
  configuration file (ZCML, via the optional :term:`pyramid_zcml` package).
  We didn't need to write a frontend from scratch to make use of
  configuration-file-driven registry population.

- Pluggability.  Use of the ZCA registry allows for framework extensibility
  via a well-defined and widely understood plugin architecture.  As long as

 docs/glossary.rst

@@ -859,20 +859,14 @@

   pyramid_zcml
     An add-on package to :app:`Pyramid` which allows applications to be
     configured via ZCML.  It is available on :term:`PyPI`.  If you use
     ``pyramid_zcml``, you can use ZCML as an alternative to
     :term:`imperative configuration`.
     configured via :term:`ZCML`.  It is available on :term:`PyPI`.  If you
     use ``pyramid_zcml``, you can use ZCML as an alternative to
     :term:`imperative configuration` or :term:`configuration decoration`.

   ZCML
     `Zope Configuration Markup Language
     <http://www.muthukadan.net/docs/zca.html#zcml>`_, an XML dialect
     used by Zope and :term:`pyramid_zcml` for configuration tasks.

   ZCML directive
     A ZCML "tag" such as ``<view>`` or ``<route>``.

   ZCML declaration
     The concrete use of a :term:`ZCML directive` within a ZCML file.

   pyramid_handlers
     An add-on package which allows :app:`Pyramid` users to create classes

 docs/narr/assets.rst

@@ -441,9 +441,6 @@
- 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


 docs/narr/introduction.rst

@@ -122,9 +122,9 @@
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

 docs/narr/templates.rst

@@ -335,9 +335,8 @@
   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 @@
   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

 docs/tutorials/wiki/installation.rst

@@ -262,9 +262,6 @@

- you are willing to use :term:`traversal` to map URLs to code.

- you want to use imperative code plus a :term:`scan` to perform
  configuration.

.. note::

   :app:`Pyramid` supports any persistent storage mechanism (e.g. a SQL

 docs/tutorials/wiki2/installation.rst

@@ -232,9 +232,6 @@

- you are willing to use :term:`url dispatch` to map URLs to code.

- you want to configure your application *imperatively* (no
  :term:`declarative configuration` such as ZCML).

.. note::

   :app:`Pyramid` supports any persistent storage mechanism (e.g. object