convert narrative docs to Pyramid

1 files changed, 38 insertions, 38 deletions

diff --git a/docs/narr/zca.rst b/docs/narr/zca.rst
index 11b7eabad..b558580b5 100644
--- a/docs/narr/zca.rst
+++ b/docs/narr/zca.rst
@@ -8,10 +8,10 @@
 
 .. _zca_chapter:
 
-Using the Zope Component Architecture in :mod:`repoze.bfg`
+Using the Zope Component Architecture in :mod:`pyramid`
 ==========================================================
 
-Under the hood, :mod:`repoze.bfg` uses a :term:`Zope Component
+Under the hood, :mod:`pyramid` uses a :term:`Zope Component
 Architecture` component registry as its :term:`application registry`.
 The Zope Component Architecture is referred to colloquially as the
 "ZCA."
@@ -25,7 +25,7 @@ as it might appear in a traditional Zope application:
 .. code-block:: python
    :linenos:
 
-   from repoze.bfg.interfaces import ISettings
+   from pyramid.interfaces import ISettings
    from zope.component import getUtility
    settings = getUtility(ISettings)
 
@@ -36,16 +36,16 @@ API is used by a developer, the conceptual load on a casual reader of
 code is high.
 
 While the ZCA is an excellent tool with which to build a *framework*
-such as :mod:`repoze.bfg`, it is not always the best tool with which
+such as :mod:`pyramid`, it is not always the best tool with which
 to build an *application* due to the opacity of the ``zope.component``
-APIs.  Accordingly, :mod:`repoze.bfg` tends to hide the the presence
+APIs.  Accordingly, :mod:`pyramid` tends to hide the the presence
 of the ZCA from application developers.  You needn't understand the
-ZCA to create a :mod:`repoze.bfg` application; its use is effectively
+ZCA to create a :mod:`pyramid` application; its use is effectively
 only a framework implementation detail.
 
 However, developers who are already used to writing :term:`Zope`
 applications often still wish to use the ZCA while building a
-:mod:`repoze.bfg` application; :mod:`repoze.bfg` makes this possible.
+:mod:`pyramid` application; :mod:`pyramid` makes this possible.
 
 .. index::
    single: get_current_registry
@@ -53,7 +53,7 @@ applications often still wish to use the ZCA while building a
    single: getSiteManager
    single: ZCA global API
 
-Using the ZCA Global API in a :mod:`repoze.bfg` Application
+Using the ZCA Global API in a :mod:`pyramid` Application
 -----------------------------------------------------------
 
 :term:`Zope` uses a single ZCA registry -- the "global" ZCA registry
@@ -72,28 +72,28 @@ process.
 
 Most production Zope applications are relatively large, making it
 impractical due to memory constraints to run more than one Zope
-application per Python process.  However, a :mod:`repoze.bfg`
+application per Python process.  However, a :mod:`pyramid`
 application may be very small and consume very little memory, so it's
 a reasonable goal to be able to run more than one BFG application per
 process.
 
-In order to make it possible to run more than one :mod:`repoze.bfg`
-application in a single process, :mod:`repoze.bfg` defaults to using a
+In order to make it possible to run more than one :mod:`pyramid`
+application in a single process, :mod:`pyramid` defaults to using a
 separate ZCA registry *per application*.
 
 While this services a reasonable goal, it causes some issues when
 trying to use patterns which you might use to build a typical
-:term:`Zope` application to build a :mod:`repoze.bfg` application.
+:term:`Zope` application to build a :mod:`pyramid` application.
 Without special help, ZCA "global" APIs such as
 ``zope.component.getUtility`` and ``zope.component.getSiteManager``
 will use the ZCA "global" registry.  Therefore, these APIs
-will appear to fail when used in a :mod:`repoze.bfg` application,
+will appear to fail when used in a :mod:`pyramid` application,
 because they'll be consulting the ZCA global registry rather than the
-component registry associated with your :mod:`repoze.bfg` application.
+component registry associated with your :mod:`pyramid` application.
 
 There are three ways to fix this: by disusing the ZCA global API
 entirely, by using
-:meth:`repoze.bfg.configuration.Configurator.hook_zca` or by passing
+:meth:`pyramid.configuration.Configurator.hook_zca` or by passing
 the ZCA global registry to the :term:`Configurator` constructor at
 startup time.  We'll describe all three methods in this section.
 
@@ -123,21 +123,21 @@ but it largely mirrors the "global" API almost exactly.
 
 If you are willing to disuse the "global" ZCA APIs and use the method
 interface of a registry instead, you need only know how to obtain the
-:mod:`repoze.bfg` component registry.
+:mod:`pyramid` component registry.
 
 There are two ways of doing so:
 
-- use the :func:`repoze.bfg.threadlocal.get_current_registry`
-  function within :mod:`repoze.bfg` view or model code.  This will
-  always return the "current" :mod:`repoze.bfg` application registry.
+- use the :func:`pyramid.threadlocal.get_current_registry`
+  function within :mod:`pyramid` view or model code.  This will
+  always return the "current" :mod:`pyramid` application registry.
 
 - use the attribute of the :term:`request` object named ``registry``
-  in your :mod:`repoze.bfg` view code, eg. ``request.registry``.  This
+  in your :mod:`pyramid` view code, eg. ``request.registry``.  This
   is the ZCA component registry related to the running
-  :mod:`repoze.bfg` application.
+  :mod:`pyramid` application.
 
 See :ref:`threadlocals_chapter` for more information about
-:func:`repoze.bfg.threadlocal.get_current_registry`.
+:func:`pyramid.threadlocal.get_current_registry`.
 
 .. index::
    single: hook_zca (configurator method)
@@ -147,13 +147,13 @@ See :ref:`threadlocals_chapter` for more information about
 Enabling the ZCA Global API by Using ``hook_zca``
 +++++++++++++++++++++++++++++++++++++++++++++++++
 
-Consider the following bit of idiomatic :mod:`repoze.bfg` startup code:
+Consider the following bit of idiomatic :mod:`pyramid` startup code:
 
 .. code-block:: python
    :linenos:
 
    from zope.component import getGlobalSiteManager
-   from repoze.bfg.configuration import Configurator
+   from pyramid.configuration import Configurator
 
    def app(global_settings, **settings):
        config = Configurator(settings=settings)
@@ -172,7 +172,7 @@ when a :term:`Configurator` constructor is called, or when a
 
 During a request, the application registry created by the Configurator
 is "made current".  This means calls to
-:func:`repoze.bfg.threadlocal.get_current_registry` in the thread
+:func:`pyramid.threadlocal.get_current_registry` in the thread
 handling the request will return the component registry associated
 with the application.
 
@@ -185,14 +185,14 @@ always return the global ZCA registry (the one in
 
 To "fix" this and make the ZCA global APIs use the "current" BFG
 registry, you need to call
-:meth:`repoze.bfg.configuration.Configurator.hook_zca` within your
+:meth:`pyramid.configuration.Configurator.hook_zca` within your
 setup code.  For example:
 
 .. code-block:: python
    :linenos:
 
    from zope.component import getGlobalSiteManager
-   from repoze.bfg.configuration import Configurator
+   from pyramid.configuration import Configurator
 
    def app(global_settings, **settings):
        config = Configurator(settings=settings)
@@ -210,17 +210,17 @@ is that an analogue of the following code is executed:
    :linenos:
 
    from zope.component import getSiteManager
-   from repoze.bfg.threadlocal import get_current_registry
+   from pyramid.threadlocal import get_current_registry
    getSiteManager.sethook(get_current_registry)
 
-This causes the ZCA global API to start using the :mod:`repoze.bfg`
-application registry in threads which are running a :mod:`repoze.bfg`
+This causes the ZCA global API to start using the :mod:`pyramid`
+application registry in threads which are running a :mod:`pyramid`
 request.
 
 Calling ``hook_zca`` is usually sufficient to "fix" the problem of
-being able to use the global ZCA API within a :mod:`repoze.bfg`
+being able to use the global ZCA API within a :mod:`pyramid`
 application.  However, it also means that a Zope application that is
-running in the same process may start using the :mod:`repoze.bfg`
+running in the same process may start using the :mod:`pyramid`
 global registry instead of the Zope global registry, effectively
 inverting the original problem.  In such a case, follow the steps in
 the next section, :ref:`using_the_zca_global_registry`.
@@ -235,14 +235,14 @@ the next section, :ref:`using_the_zca_global_registry`.
 Enabling the ZCA Global API by Using The ZCA Global Registry
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-You can tell your :mod:`repoze.bfg` application to use the ZCA global
+You can tell your :mod:`pyramid` application to use the ZCA global
 registry at startup time instead of constructing a new one:
 
 .. code-block:: python
    :linenos:
 
    from zope.component import getGlobalSiteManager
-   from repoze.bfg.configuration import Configurator
+   from pyramid.configuration import Configurator
 
    def app(global_settings, **settings):
        globalreg = getGlobalSiteManager()
@@ -262,7 +262,7 @@ registry with BFG-specific registrations; this is code that is
 normally executed when a registry is constructed rather than created,
 but we must call it "by hand" when we pass an explicit registry.
 
-At this point, :mod:`repoze.bfg` will use the ZCA global registry
+At this point, :mod:`pyramid` will use the ZCA global registry
 rather than creating a new application-specific registry; since by
 default the ZCA global API will use this registry, things will work as
 you might expect a Zope app to when you use the global ZCA API.
@@ -280,15 +280,15 @@ Some :term:`Zope` and third-party :term:`ZCML` directives use the
 they should actually be calling ``zope.component.getSiteManager``.
 
 ``zope.component.getSiteManager`` can be overridden by
-:mod:`repoze.bfg` via
-:meth:`repoze.bfg.configuration.Configurator.hook_zca`, while
+:mod:`pyramid` via
+:meth:`pyramid.configuration.Configurator.hook_zca`, while
 ``zope.component.getGlobalSiteManager`` cannot.  Directives that use
 ``zope.component.getGlobalSiteManager`` are effectively broken; no
 ZCML directive should be using this function to find a registry to
 populate.
 
 You cannot use ZCML directives which use
-``zope.component.getGlobalSiteManager`` within a :mod:`repoze.bfg`
+``zope.component.getGlobalSiteManager`` within a :mod:`pyramid`
 application without passing the ZCA global registry to the
 :term:`Configurator` constructor at application startup, as per
 :ref:`using_the_zca_global_registry`.