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.

6 files changed, 25 insertions, 27 deletions

diff --git a/docs/narr/MyProject/myproject/configure.zcml b/docs/narr/MyProject/myproject/configure.zcml
index 96f51d3c1..584dee906 100644
--- a/docs/narr/MyProject/myproject/configure.zcml
+++ b/docs/narr/MyProject/myproject/configure.zcml
@@ -1,11 +1,9 @@
-<configure xmlns="http://namespaces.zope.org/zope"
-	   xmlns:bfg="http://namespaces.repoze.org/bfg"
-	   i18n_domain="repoze.bfg">
+<configure xmlns="http://namespaces.repoze.org/bfg">
 
   <!-- this must be included for the view declarations to work -->
   <include package="repoze.bfg.includes" />
 
-  <bfg:view
+  <view
      for=".models.MyModel"
      view=".views.my_view"
      />
diff --git a/docs/narr/events.rst b/docs/narr/events.rst
index c6242c25d..adb0ae7b0 100644
--- a/docs/narr/events.rst
+++ b/docs/narr/events.rst
@@ -152,13 +152,13 @@ the same model object.
     />
 
    <!-- html default view -->
-   <bfg:view
+   <view
       for=".models.MyModel"
       request_type="repoze.bfg.interfaces.IRequest"
       view=".views.html_view"/>
 
    <!-- JSON default view -->
-   <bfg:view
+   <view
       for=".models.MyModel"
       request_type=".interfaces.IJSONRequest"
       view=".views.json_view"/>
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 041fff89d..87eaeae0a 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -50,7 +50,7 @@ For example, the following declaration protects the view named
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for=".models.IBlog"
        view=".views.blog_entry_add_view"
        name="add_entry.html"
diff --git a/docs/narr/unittesting.rst b/docs/narr/unittesting.rst
index b3b2321dd..165e92411 100644
--- a/docs/narr/unittesting.rst
+++ b/docs/narr/unittesting.rst
@@ -31,9 +31,9 @@ this view function will result in an error.  When a :mod:`repoze.bfg`
 application starts normally, it will create an application registry
 from the information it finds in the application's ``configure.zcml``
 file.  But if this application registry is not created and populated
-(e.g. with ``bfg:view`` statements), like when you invoke application
-code via a unit test, :mod:`repoze.bfg` API functions will tend to
-fail.
+(e.g. with ``view`` declarations in ZCML), like when you invoke
+application code via a unit test, :mod:`repoze.bfg` API functions will
+tend to fail.
 
 The testing API provided by ``repoze.bfg`` allows you to simulate
 various application registry registrations for use under a unit
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index e1f07f88e..7572ddd65 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -134,14 +134,14 @@ call the "fallback" ``get_root`` callable provided to it above.
 Example 2
 ---------
 
-An example of configuring a ``bfg:view`` stanza in ``configure.zcml``
+An example of configuring a ``view`` declaration in ``configure.zcml``
 that maps a context found via :term:`Routes` URL dispatch to a view
 function is as follows:
 
 .. code-block:: xml
    :linenos:
 
-   <bfg:view
+   <view
        for="repoze.bfg.interfaces.IRoutesContext"
        view=".views.articles_view"
        name="articles"
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"