diff options
| -rw-r--r-- | docs/designdefense.rst | 15 | ||||
| -rw-r--r-- | docs/glossary.rst | 12 | ||||
| -rw-r--r-- | docs/narr/assets.rst | 3 | ||||
| -rw-r--r-- | docs/narr/introduction.rst | 6 | ||||
| -rw-r--r-- | docs/narr/templates.rst | 12 | ||||
| -rw-r--r-- | docs/tutorials/wiki/installation.rst | 3 | ||||
| -rw-r--r-- | docs/tutorials/wiki2/installation.rst | 3 |
7 files changed, 17 insertions, 37 deletions
diff --git a/docs/designdefense.rst b/docs/designdefense.rst index 4975ae2a0..147a52c31 100644 --- a/docs/designdefense.rst +++ b/docs/designdefense.rst @@ -61,10 +61,11 @@ features we found compelling in other frameworks (such as :term:`url 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 @@ the ZCA registry: - 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 diff --git a/docs/glossary.rst b/docs/glossary.rst index 332006d9d..8bbd9ff7d 100644 --- a/docs/glossary.rst +++ b/docs/glossary.rst @@ -859,21 +859,15 @@ Glossary 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 that are analogues of Pylons 1 "controllers". See 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 diff --git a/docs/tutorials/wiki/installation.rst b/docs/tutorials/wiki/installation.rst index f3e22324c..822e0bd22 100644 --- a/docs/tutorials/wiki/installation.rst +++ b/docs/tutorials/wiki/installation.rst @@ -262,9 +262,6 @@ assumptions: - 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 diff --git a/docs/tutorials/wiki2/installation.rst b/docs/tutorials/wiki2/installation.rst index 488b4fb35..bfe75d82e 100644 --- a/docs/tutorials/wiki2/installation.rst +++ b/docs/tutorials/wiki2/installation.rst @@ -232,9 +232,6 @@ the following assumptions: - 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 |