Backwards Incompatibilities (Major)

  - Rather than prepare the "stock" implementations of the ZCML
    directives from the ``zope.configuration`` package for use under
    :mod:`repoze.bfg`, :mod:`repoze.bfg` now makes available the
    implementations of directives from the ``repoze.zcml`` package
    (see http://static.repoze.org/zcmldocs).  As a result, the
    :mod:`repoze.bfg` package now depends on the ``repoze.zcml``
    package, and no longer depends directly on the ``zope.component``,
    ``zope.configuration``, ``zope.interface``, or ``zope.proxy``
    packages.

    The primary reason for this change is to enable us to eventually
    reduce the number of inappropriate :mod:`repoze.bfg` Zope package
    dependencies, as well as to shed features of dependent package
    directives that don't make sense for :mod:`repoze.bfg`.

    Note that currently the set of requirements necessary to use bfg
    has not changed.  This is due to inappropriate Zope package
    requirements in ``chameleon.zpt``, which will hopefully be
    remedied soon.

  - BFG applications written prior to this release which expect the
    "stock" ``zope.component`` ZCML directive implementations
    (e.g. ``adapter``, ``subscriber``, or ``utility``) to function now
    must either 1) include the ``meta.zcml`` file from
    ``zope.component`` manually (e.g. ``<include
    package="zope.component" file="meta.zcml">``) and include the
    ``zope.security`` package as an ``install_requires`` dependency or
    2) change the ZCML in their applications to use the declarations
    from `repoze.zcml <http://static.repoze.org/zcmldocs/>`_ instead
    of the stock declarations.  ``repoze.zcml`` only makes available
    the ``adapter``, ``subscriber`` and ``utility`` directives.

  - The ``http://namespaces.repoze.org/bfg`` XML namespace is now the
    default XML namespace in ZCML for paster-generated applications.

  - The copies of BFG's ``meta.zcml`` and ``configure.zcml`` were
    removed from the root of the ``repoze.bfg`` package.  In 0.3.6, a
    new package named ``repoze.bfg.includes`` was added, which
    contains the "correct" copies of these ZCML files; the ones that
    were removed were for backwards compatibility purposes.

  Other

  - The minimum requirement for ``chameleon.core`` is now 1.0b13.  The
    minimum requirement for ``chameleon.zpt`` is now 1.0b7.  The
    minimum requirement for ``chameleon.genshi`` is now 1.0b2.

1 files changed, 15 insertions, 15 deletions

diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index d61cdb06e..9e2d2887f 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -66,12 +66,12 @@ Mapping Views to URLs
 
 You may associate a view with a URL by adding information to your
 :term:`application registry` via :term:`ZCML` in your
-``configure.zcml`` file using a ``bfg:view`` declaration.
+``configure.zcml`` file using a ``view`` declaration.
 
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for=".models.Hello"
        view=".views.hello_world"
        name="hello.html"
@@ -83,9 +83,9 @@ Python class represented by ``.models.Hello`` when the *view name* is
 ``hello.html``.
 
 .. note:: Values prefixed with a period (``.``)for the ``for`` and
-   ``view`` attributes of a ``bfg:view`` (such as those above) mean
+   ``view`` attributes of a ``view`` (such as those above) mean
    "relative to the Python package directory in which this
-   :term:`ZCML` file is stored".  So if the above ``bfg:view``
+   :term:`ZCML` file is stored".  So if the above ``view``
    declaration was made inside a ``configure.zcml`` file that lived in
    the ``hello`` package, you could replace the relative
    ``.models.Hello`` with the absolute ``hello.models.Hello``;
@@ -100,7 +100,7 @@ You can also declare a *default view* for a model type:
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for=".models.Hello"
        view=".views.hello_world"
        />
@@ -115,7 +115,7 @@ the special ``*`` character in the ``for`` attribute:
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for="*"
        view=".views.hello_world"
        name="hello.html"
@@ -204,7 +204,7 @@ this interface.
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for=".models.IHello"
        view=".views.hello_world"
        name="hello.html"
@@ -223,10 +223,10 @@ implemented by the context, the view registered for the class will
 See :term:`Interface` in the glossary to find more information about
 interfaces.
 
-The ``bfg:view`` ZCML Element
------------------------------
+The ``view`` ZCML Element
+-------------------------
 
-The ``bfg:view`` ZCML element has these possible attributes:
+The ``view`` ZCML element has these possible attributes:
 
 view
 
@@ -262,14 +262,14 @@ request_type
 View Request Types
 ------------------
 
-You can optionally add a *request_type* attribute to your ``bfg:view``
+You can optionally add a *request_type* attribute to your ``view``
 declaration, which indicates what "kind" of request the view should be
 used for.  For example:
 
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for=".models.IHello"
        view=".views.hello_json"
        name="hello.json"
@@ -325,16 +325,16 @@ View Security
 -------------
 
 If a :term:`security policy` is active, any :term:`permission`
-attached to a ``bfg:view`` declaration will be consulted to ensure
+attached to a ``view`` declaration will be consulted to ensure
 that the currently authenticated user possesses that permission
 against the context before the view function is actually called.
-Here's an example of specifying a permission in a ``bfg:view``
+Here's an example of specifying a permission in a ``view``
 declaration:
 
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for=".models.IBlog"
        view=".views.add_entry"
        name="add.html"