diff options
Diffstat (limited to 'docs/narr')
| -rw-r--r-- | docs/narr/assets.rst | 3 | ||||
| -rw-r--r-- | docs/narr/introduction.rst | 6 | ||||
| -rw-r--r-- | docs/narr/templates.rst | 12 |
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 |