Features

--------

- The ``Configurator.add_view`` method now accepts an argument named
  ``context``.  This is an alias for the older argument named
  ``for_``; it is preferred over ``for_``, but ``for_`` will continue
  to be supported "forever".

- The ``view`` ZCML directive now accepts an attribute named
  ``context``.  This is an alias for the older attribute named
  ``for``; it is preferred over ``for``, but ``for`` will continue to
  be supported "forever".

- The ``Configurator.add_route`` method now accepts an argument named
  ``view_context``.  This is an alias for the older argument named
  ``view_for``; it is preferred over ``view_for``, but ``view_for``
  will continue to be supported "forever".

- The ``route`` ZCML directive now accepts an attribute named
  ``view_context``.  This is an alias for the older attribute named
  ``view_for``; it is preferred over ``view_for``, but ``view_for``
  will continue to be supported "forever".

Documentation and Paster Templates
----------------------------------

- All uses of the ``Configurator.add_view`` method that used its
  ``for_`` argument now use the ``context``argument instead.

- All uses of the ``Configurator.add_route`` method that used its
  ``view_for`` argument now use the ``view_context``argument instead.

- All uses of the ``view`` ZCML directive that used its ``for``
  attribute now use the ``context`` attribute instead.

- All uses of the ``route`` ZCML directive that used its ``view_for``
  attribute now use the ``view_context`` attribute instead.

7 files changed, 68 insertions, 64 deletions

diff --git a/docs/narr/MyProject/myproject/configure.zcml b/docs/narr/MyProject/myproject/configure.zcml
index fe9633fe1..95b7355b1 100644
--- a/docs/narr/MyProject/myproject/configure.zcml
+++ b/docs/narr/MyProject/myproject/configure.zcml
@@ -3,7 +3,7 @@
   <include package="repoze.bfg.includes" />
 
   <view
-     for=".models.MyModel"
+     context=".models.MyModel"
      view=".views.my_view"
      renderer="templates/mytemplate.pt"
      />
diff --git a/docs/narr/extending.rst b/docs/narr/extending.rst
index 0f9bc433d..0b2d5a876 100644
--- a/docs/narr/extending.rst
+++ b/docs/narr/extending.rst
@@ -181,7 +181,7 @@ Overriding Views
 ~~~~~~~~~~~~~~~~~
 
 The ZCML ``<view>`` declarations you make which *override* application
-behavior will usually have the same ``for`` and ``name`` (and
+behavior will usually have the same ``context`` and ``name`` (and
 :term:`predicate` attributes, if used) as the original.  These
 ``<view>`` declarations will point at "new" view code.  The new view
 code itself will usually be cut-n-paste copies of view callables from
@@ -190,7 +190,7 @@ the original application with slight tweaks.  For example:
 .. code-block:: xml
    :linenos:
 
-    <view for="theoriginalapplication.models.SomeModel"
+    <view context="theoriginalapplication.models.SomeModel"
           name="theview"
           view=".views.a_view_that_does_something_slightly_different"
      />
diff --git a/docs/narr/hooks.rst b/docs/narr/hooks.rst
index 990290744..47495b68c 100644
--- a/docs/narr/hooks.rst
+++ b/docs/narr/hooks.rst
@@ -225,11 +225,11 @@ a class that implements the following interface:
 
 More than one traversal algorithm can be active at the same time.  For
 instance, if your :term:`root factory` returns more than one type of
-object conditionally, you could claim that an alternate traverser is
-``for`` only one particular class or interface.  When the root factory
-returned an object that implemented that class or interface, a custom
-traverser would be used.  Otherwise, the default traverser would be
-used.  For example:
+object conditionally, you could claim that an alternate traverser
+adapter is ``for`` only one particular class or interface.  When the
+root factory returned an object that implemented that class or
+interface, a custom traverser would be used.  Otherwise, the default
+traverser would be used.  For example:
 
 .. code-block:: xml
    :linenos:
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst
index 14cb1d4ab..5c3775e59 100644
--- a/docs/narr/hybrid.rst
+++ b/docs/narr/hybrid.rst
@@ -361,12 +361,13 @@ then both the request type and the context type are "more specific"
 for the view registration).
 
 What it all boils down to is: if a request that matches a route
-resolves to a view you don't expect it to, use the ``view_for``
-attribute of the ``route`` statement (*or* the ``for`` attribute of
-the ZCML statement that also has a ``route_name`` *or* the equivalent
-``for_`` parameter to the :class:`repoze.bfg.view.bfg_view` decorator
-that also has a ``route_name`` parameter) to name the specific context
-interface you want the route-related view to match.
+resolves to a view you don't expect it to, use the ``view_context``
+attribute of the ``route`` statement (*or* the ``context`` attribute
+of the ZCML statement that also has a ``route_name`` *or* the
+equivalent ``context`` parameter to the
+:class:`repoze.bfg.view.bfg_view` decorator that also has a
+``route_name`` parameter) to name the specific context interface you
+want the route-related view to match.
 
 Yes, that was as painful for me to write as it was for you to read.
 
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 41b0bce02..02d9e30ba 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -603,12 +603,13 @@ the :term:`application registry`. It looks like so:
    in this file.
 
 #. Lines 6-10 register a "default view" (a view that has no ``name``
-   attribute).  It is ``for`` model objects that are instances of the
+   attribute).  It is registered so that it will be found when the
+   :term:`context` of the request is an instance of the
    :class:`myproject.models.MyModel` class.  The ``view`` attribute
    points at a Python function that does all the work for this view.
-   Note that the values of both the ``for`` attribute and the ``view``
-   attribute begin with a single period.  Names that begin with a
-   period are "shortcuts" which point at files relative to the
+   Note that the values of both the ``context`` attribute and the
+   ``view`` attribute begin with a single period.  Names that begin
+   with a period are "shortcuts" which point at files relative to the
    :term:`package` in which the ``configure.zcml`` file lives.  In
    this case, since the ``configure.zcml`` file lives within the
    :mod:`myproject` package, the shortcut ``.models.MyModel`` could
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index e83e2f8b8..4c86c7f5e 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -125,7 +125,7 @@ when invoked against a ``Blog`` context with the ``add`` permission:
    :linenos:
 
    <view
-       for=".models.Blog"
+       context=".models.Blog"
        view=".views.blog_entry_add_view"
        name="add_entry.html"
        permission="add"
@@ -142,7 +142,7 @@ module of your project's package
    from repoze.bfg.view import bfg_view
    from models import Blog
 
-   @bfg_view(for_=Blog, name='add_entry.html', permission='add')
+   @bfg_view(context=Blog, name='add_entry.html', permission='add')
    def blog_entry_add_view(request):
        """ Add blog entry code goes here """
        pass
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 8ad343f39..df3c92fc1 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -310,7 +310,7 @@ declaration in ZCML is as follows:
    :linenos:
 
    <view
-       for=".models.Hello"
+       context=".models.Hello"
        view=".views.hello_world"
        name="hello.html"
        />
@@ -320,18 +320,18 @@ The above maps the ``.views.hello_world`` view function to
 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 ``view`` (such as those above) mean
+.. note:: Values prefixed with a period (``.``) for the ``context``
+   and ``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 ``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``;
-   likewise you could replace the relative ``.views.hello_world`` with
-   the absolute ``hello.views.hello_world``.  Either the relative or
-   absolute form is functionally equivalent.  It's often useful to use
-   the relative form, in case your package's name changes.  It's also
-   shorter to type.
+   :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``; likewise you could
+   replace the relative ``.views.hello_world`` with the absolute
+   ``hello.views.hello_world``.  Either the relative or absolute form
+   is functionally equivalent.  It's often useful to use the relative
+   form, in case your package's name changes.  It's also shorter to
+   type.
 
 You can also declare a *default view* for a model type:
 
@@ -339,7 +339,7 @@ You can also declare a *default view* for a model type:
    :linenos:
 
    <view
-       for=".models.Hello"
+       context=".models.Hello"
        view=".views.hello_world"
        />
 
@@ -348,13 +348,13 @@ found and there is no *view name* associated with the result of
 :term:`traversal`, the *default view* is the view that is used.
 
 You can also declare that a view is good for any model type by using
-the special ``*`` character in the ``for`` attribute:
+the special ``*`` character in the ``context`` attribute:
 
 .. code-block:: xml
    :linenos:
 
    <view
-       for="*"
+       context="*"
        view=".views.hello_world"
        name="hello.html"
        />
@@ -381,7 +381,7 @@ For better locality of reference, use the
 :class:`repoze.bfg.view.bfg_view` decorator to associate your view
 functions with URLs instead of using :term:`ZCML` for the same
 purpose.  :class:`repoze.bfg.view.bfg_view` can be used to associate
-``for``, ``name``, ``permission`` and ``request_method``,
+``context``, ``name``, ``permission`` and ``request_method``,
 ``containment``, ``request_param`` and ``request_type``, ``attr``,
 ``renderer``, ``wrapper``, ``xhr``, ``accept``, and ``header``
 information -- as done via the equivalent ZCML -- with a function that
@@ -449,7 +449,7 @@ An example might reside in a bfg application module ``views.py``:
    from repoze.bfg.view import bfg_view
    from repoze.bfg.chameleon_zpt import render_template_to_response
 
-   @bfg_view(name='my_view', request_method='POST', for_=MyModel,
+   @bfg_view(name='my_view', request_method='POST', context=MyModel,
              permission='read', renderer='templates/my.pt')
    def my_view(request):
        return {'a':1}
@@ -461,7 +461,7 @@ your application registry:
    :linenos:
 
    <view
-    for=".models.MyModel"
+    context=".models.MyModel"
     view=".views.my_view"
     name="my_view"
     permission="read"
@@ -474,7 +474,7 @@ Or replaces the need to add this imperative configuration stanza:
 .. ignore-next-block
 .. code-block:: python
 
-   config.add_view(name='my_view', request_method='POST', for_=MyModel,
+   config.add_view(name='my_view', request_method='POST', context=MyModel,
                    permission='read')
 
 All arguments to :class:`repoze.bfg.view.bfg_view` are optional.
@@ -496,9 +496,10 @@ If ``request_type`` is not supplied, the value ``None`` is used,
 implying any request type.  Otherwise, this should be a class or
 interface.
 
-If ``for_`` is not supplied, the interface
+If ``context`` is not supplied, the interface
 :class:`zope.interface.Interface` (which matches any model) is used.
-``for_`` can also name a class, like its ZCML brother.
+``context`` can also name a class, like its ZCML brother.  An alias for
+``context`` is ``for_`` (``for_`` is an older spelling).
 
 If ``permission`` is not supplied, no permission is registered for
 this view (it's accessible by any caller).
@@ -558,9 +559,10 @@ All arguments may be omitted.  For example:
        return Response()
 
 Such a registration as the one directly above implies that the view
-name will be ``my_view``, registered ``for_`` any model type, using no
-permission, registered against requests with any request method /
-request type / request param / route name / containment.
+name will be ``my_view``, registered with a ``context`` argument that
+matches any model type, using no permission, registered against
+requests with any request method / request type / request param /
+route name / containment.
 
 If your view callable is a class, the
 :class:`repoze.bfg.view.bfg_view` decorator can also be used as a
@@ -748,15 +750,15 @@ looked up on the view object to return a response.
 Using Model Interfaces
 ----------------------
 
-Instead of registering your views ``for`` a Python model *class*, you
-can optionally register a view for an :term:`interface`.  Since an
-interface can be attached arbitrarily to any model instance (as
-opposed to its identity being implied by only its class), associating
-a view with an interface can provide more flexibility for sharing a
-single view between two or more different implementations of a model
-type.  For example, if two model object instances of different Python
-class types share the same interface, you can use the same view
-against each of them.
+Instead of registering your views with a ``context`` that names a
+Python model *class*, you can optionally register a view for an
+:term:`interface`.  Since an interface can be attached arbitrarily to
+any model instance (as opposed to its identity being implied by only
+its class), associating a view with an interface can provide more
+flexibility for sharing a single view between two or more different
+implementations of a model type.  For example, if two model object
+instances of different Python class types share the same interface,
+you can use the same view against each of them.
 
 In order to make use of interfaces in your application during view
 dispatch, you must create an interface and mark up your model classes
@@ -812,7 +814,7 @@ this interface.
    :linenos:
 
    <view
-       for=".models.IHello"
+       context=".models.IHello"
        view=".views.hello_world"
        name="hello.html"
        />
@@ -922,7 +924,7 @@ You can configure a view to use the JSON renderer in ZCML by naming
    :linenos:
 
    <view
-       for=".models.Hello"
+       context=".models.Hello"
        view=".views.hello_world"
        name="hello"
        renderer="json"
@@ -987,7 +989,7 @@ renderer:
    :linenos:
 
    <view
-       for=".models.Hello"
+       context=".models.Hello"
        view=".views.hello_world"
        name="hello"
        renderer="templates/foo.pt"
@@ -1000,7 +1002,7 @@ renderer:
    :linenos:
 
    <view
-       for=".models.Hello"
+       context=".models.Hello"
        view=".views.hello_world"
        name="hello"
        renderer="templates/foo.txt"
@@ -1226,7 +1228,7 @@ view declaration in ZCML:
    :linenos:
 
    <view
-       for=".models.IBlog"
+       context=".models.IBlog"
        view=".views.add_entry"
        name="add.html"
        permission="add"
@@ -1461,7 +1463,7 @@ object.  For example (ZCML):
    :linenos:
 
     <view
-      for=".models.Root"
+      context=".models.Root"
       view=".static.static_view"
       name="static"
     />   
@@ -1469,11 +1471,11 @@ object.  For example (ZCML):
 In this case, ``.models.Root`` refers to the class of which your
 :mod:`repoze.bfg` application's root object is an instance.
 
-.. note:: You can also give a ``for`` of ``*`` if you want the name
-   ``static`` to be accessible as the static view against any model.
-   This will also allow ``/static/foo.js`` to work, but it will allow
-   for ``/anything/static/foo.js`` too, as long as ``anything`` itself
-   is resolvable.
+.. note:: You can also give a ``context`` of ``*`` if you want the
+   name ``static`` to be accessible as the static view against any
+   model.  This will also allow ``/static/foo.js`` to work, but it
+   will allow for ``/anything/static/foo.js`` too, as long as
+   ``anything`` itself is resolvable.
 
 .. note:: To ensure that model objects contained in the root don't
    "shadow" your static view (model objects take precedence during