Merge branch 'master' of https://github.com/Pylons/pyramid

9 files changed, 254 insertions, 152 deletions

diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst
index 099bce35f..5ee554284 100644
--- a/docs/narr/advconfig.rst
+++ b/docs/narr/advconfig.rst
@@ -295,15 +295,9 @@ These are the methods of the configurator which provide conflict detection:
 :meth:`~pyramid.config.Configurator.set_locale_negotiator` and
 :meth:`~pyramid.config.Configurator.set_default_permission`.
 
-Some other methods of the configurator also indirectly provide conflict
-detection, because they're implemented in terms of conflict-aware methods:
-
-- :meth:`~pyramid.config.Configurator.add_route` does a second type of
-  conflict detection when a ``view`` parameter is passed (it calls
-  ``add_view``).
-
-- :meth:`~pyramid.config.Configurator.static_view`, a frontend for
-  ``add_route`` and ``add_view``.
+:meth:`~pyramid.config.Configurator.add_static_view` also indirectly
+provides conflict detection, because it's implemented in terms of the
+conflict-aware ``add_route`` and ``add_view`` methods.
 
 .. _including_configuration:
 
diff --git a/docs/narr/assets.rst b/docs/narr/assets.rst
index bbb673ecc..8d0e7058c 100644
--- a/docs/narr/assets.rst
+++ b/docs/narr/assets.rst
@@ -341,7 +341,8 @@ application's startup code.
    # .. every other add_route declaration should come
    # before this one, as it will, by default, catch all requests
 
-   config.add_route('catchall_static', '/*subpath', 'myapp.static.static_view')
+   config.add_route('catchall_static', '/*subpath')
+   config.add_view('myapp.static.static_view', route_name='catchall_static')
 
 The special name ``*subpath`` above is used by the
 :class:`~pyramid.view.static` view callable to signify the path of the file
@@ -384,8 +385,8 @@ Or you might register it to be the view callable for a particular route:
 .. code-block:: python
    :linenos:
 
-   config.add_route('favicon', '/favicon.ico', 
-                    view='myapp.views.favicon_view')
+   config.add_route('favicon', '/favicon.ico')
+   config.add_view('myapp.views.favicon_view', route_name='favicon')
 
 Because this is a simple view callable, it can be protected with a
 :term:`permission` or can be configured to respond under different
diff --git a/docs/narr/environment.rst b/docs/narr/environment.rst
index 7b7946aae..8c299f3a3 100644
--- a/docs/narr/environment.rst
+++ b/docs/narr/environment.rst
@@ -381,3 +381,66 @@ around in overridden asset directories. ``reload_assets`` makes the system
 *very slow* when templates are in use.  Never set ``reload_assets`` to
 ``True`` on a production system.
 
+Adding A Custom Setting
+-----------------------
+
+From time to time, you may need to add a custom setting to your application.
+Here's how:
+
+- If you're using an ``.ini`` file, change the ``.ini`` file, adding the
+  setting to the ``[app:foo]`` section representing your Pyramid application.
+  For example:
+
+  .. code-block:: ini
+
+    [app:myapp]
+    # .. other settings
+    debug_frobnosticator = True
+
+- In the ``main()`` function that represents the place that your Pyramid WSGI
+  application is created, anticipate that you'll be getting this key/value
+  pair as a setting and do any type conversion necessary.
+
+  If you've done any type conversion of your custom value, reset the
+  converted values into the ``settings`` dictionary *before* you pass the
+  dictionary as ``settings`` to the :term:`Configurator`.  For example:
+
+  .. code-block:: python
+
+     def main(global_config, **settings):
+         # ...
+         from pyramid.settings import asbool
+         debug_frobnosticator = asbool(settings.get(
+                    'debug_frobnosticator', 'false'))
+         settings['debug_frobnosticator'] = debug_frobnosticator
+         config = Configurator(settings=settings)
+
+  .. note:: It's especially important that you mutate the ``settings``
+     dictionary with the converted version of the variable *before* passing
+     it to the Configurator: the configurator makes a *copy* of ``settings``,
+     it doesn't use the one you pass directly.
+
+- In the runtime code that you need to access the new settings value, find
+  the value in the ``registry.settings`` dictionary and use it.  In
+  :term:`view` code (or any other code that has access to the request), the
+  easiest way to do this is via ``request.registry.settings``.  For example:
+
+  .. code-block:: python
+
+     registry = request.registry.settings
+     debug_frobnosticator = settings['debug_frobnosticator']
+
+  If you wish to use the value in code that does not have access to the
+  request and you wish to use the value, you'll need to use the
+  :func:`pyramid.threadlocal.get_current_registry` API to obtain the current
+  registry, then ask for its ``settings`` attribute.  For example:
+
+  .. code-block:: python
+
+     registry = pyramid.threadlocal.get_current_registry()
+     settings = registry.settings
+     debug_frobnosticator = settings['debug_frobnosticator']
+   
+
+  
+
diff --git a/docs/narr/hybrid.rst b/docs/narr/hybrid.rst
index 780cb0975..f8ed743fb 100644
--- a/docs/narr/hybrid.rst
+++ b/docs/narr/hybrid.rst
@@ -33,7 +33,7 @@ URL Dispatch Only
 ~~~~~~~~~~~~~~~~~
 
 An application that uses :term:`url dispatch` exclusively to map URLs to code
-will often have statements like this within your application startup
+will often have statements like this within application startup
 configuration:
 
 .. code-block:: python
@@ -41,15 +41,20 @@ configuration:
 
    # config is an instance of pyramid.config.Configurator
 
-   config.add_route('foobar', '{foo}/{bar}', view='myproject.views.foobar')
-   config.add_route('bazbuz', '{baz}/{buz}', view='myproject.views.bazbuz')
+   config.add_route('foobar', '{foo}/{bar}')
+   config.add_route('bazbuz', '{baz}/{buz}')
 
-Each :term:`route` typically corresponds to a single view callable,
-and when that route is matched during a request, the view callable
-named by the ``view`` attribute is invoked.
+   config.add_view('myproject.views.foobar', route_name='foobar')
+   config.add_view('myproject.views.bazbuz', route_name='bazbuz')
 
-Typically, an application that uses only URL dispatch won't perform any calls
-to :meth:`pyramid.config.Configurator.add_view` in its startup code.
+Each :term:`route` corresponds to one or more view callables.  Each view
+callable is associated with a route by passing a ``route_name`` parameter
+that matches its name during a call to
+:meth:`~pyramid.config.Configurator.add_view`.  When a route is matched
+during a request, :term:`view lookup` is used to match the request to its
+associated view callable.  The presence of calls to
+:meth:`~pyramid.config.Configurator.add_route` signify that an application is
+using URL dispatch.
 
 Traversal Only
 ~~~~~~~~~~~~~~
@@ -196,12 +201,9 @@ remainder becomes the path used to perform traversal.
    The ``*remainder`` route pattern syntax is explained in more
    detail within :ref:`route_pattern_syntax`.
 
-Note that unlike the examples provided within :ref:`urldispatch_chapter`, the
-``add_route`` configuration statement named previously does not pass a
-``view`` argument.  This is because a hybrid mode application relies on
-:term:`traversal` to do :term:`resource location` and :term:`view lookup`
-instead of invariably invoking a specific view callable named directly within
-the matched route's configuration.
+A hybrid mode application relies more heavily on :term:`traversal` to do
+:term:`resource location` and :term:`view lookup` than most examples indicate
+within :ref:`urldispatch_chapter`.
 
 Because the pattern of the above route ends with ``*traverse``, when this
 route configuration is matched during a request, :app:`Pyramid` will attempt
@@ -426,13 +428,11 @@ attribute.
 Using ``*subpath`` in a Route Pattern
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-There are certain extremely rare cases when you'd like to influence
-the traversal :term:`subpath` when a route matches without actually
-performing traversal.  For instance, the
-:func:`pyramid.wsgi.wsgiapp2` decorator and the
-:class:`pyramid.view.static` helper attempt to compute
-``PATH_INFO`` from the request's subpath, so it's useful to be able to
-influence this value.
+There are certain extremely rare cases when you'd like to influence the
+traversal :term:`subpath` when a route matches without actually performing
+traversal.  For instance, the :func:`pyramid.wsgi.wsgiapp2` decorator and the
+:class:`pyramid.view.static` helper attempt to compute ``PATH_INFO`` from the
+request's subpath, so it's useful to be able to influence this value.
 
 When ``*subpath`` exists in a pattern, no path is actually traversed,
 but the traversal algorithm will return a :term:`subpath` list implied
@@ -442,8 +442,8 @@ commonly in route declarations that look like this:
 .. code-block:: python
    :linenos:
 
-   config.add_route('static', '/static/*subpath',
-                    view='mypackage.views.static_view')
+   config.add_route('static', '/static/*subpath')
+   config.add_view('mypackage.views.static_view', route_name='static')
 
 Where ``mypackage.views.static_view`` is an instance of
 :class:`pyramid.view.static`.  This effectively tells the static helper to
@@ -458,11 +458,16 @@ application.  We'll detail them here.
 Registering a Default View for a Route That Has a ``view`` Attribute
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. warning:: As of :app:`Pyramid` 1.1 this section is slated to be removed in
+   a later documentation release because the the ability to add views
+   directly to the :term:`route configuration` by passing a ``view`` argument
+   to ``add_route`` has been deprecated.
+
 It is an error to provide *both* a ``view`` argument to a :term:`route
 configuration` *and* a :term:`view configuration` which names a
 ``route_name`` that has no ``name`` value or the empty ``name`` value.  For
-example, this pair of declarations will generate a "conflict" error at
-startup time.
+example, this pair of declarations will generate a conflict error at startup
+time.
 
 .. code-block:: python
    :linenos:
@@ -490,8 +495,8 @@ Can also be spelled like so:
    config.add_route('home', '{foo}/{bar}/*traverse')
    config.add_view('myproject.views.home', route_name='home')
 
-The two spellings are logically equivalent.  In fact, the former is
-just a syntactical shortcut for the latter.
+The two spellings are logically equivalent.  In fact, the former is just a
+syntactical shortcut for the latter.
 
 Binding Extra Views Against a Route Configuration that Doesn't Have a ``*traverse`` Element In Its Pattern
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 0b7cdb834..c3533648b 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -92,8 +92,8 @@ will be employed.
        return HTTPFound(location='http://example.com') # any renderer avoided
 
 Views which use a renderer can vary non-body response attributes (such as
-headers and the HTTP status code) by attaching properties to the request.
-See :ref:`response_request_attrs`.
+headers and the HTTP status code) by attaching a property to the
+``request.response`` attribute See :ref:`request_response_attr`.
 
 Additional renderers can be added by developers to the system as necessary
 (see :ref:`adding_and_overriding_renderers`).
@@ -147,7 +147,8 @@ representing the ``str()`` serialization of the return value:
    {'content': 'Hello!'}
 
 Views which use the string renderer can vary non-body response attributes by
-attaching properties to the request.  See :ref:`response_request_attrs`.
+using the API of the ``request.response`` attribute.  See
+:ref:`request_response_attr`.
 
 .. index::
    pair: renderer; JSON
@@ -199,7 +200,8 @@ You can configure a view to use the JSON renderer by naming ``json`` as the
     
 
 Views which use the JSON renderer can vary non-body response attributes by
-attaching properties to the request.  See :ref:`response_request_attrs`.
+using the api of the ``request.response`` attribute.  See
+:ref:`request_response_attr`.
 
 .. index::
    pair: renderer; chameleon
@@ -269,8 +271,9 @@ Here's an example view configuration which uses a Chameleon text renderer:
                     context='myproject.resources.Hello',
                     renderer='myproject:templates/foo.txt')
 
-Views which use a Chameleon renderer can vary response attributes by
-attaching properties to the request.  See :ref:`response_request_attrs`.
+Views which use a Chameleon renderer can vary response attributes by using
+the API of the ``request.response`` attribute.  See
+:ref:`request_response_attr`.
 
 .. index::
    pair: renderer; mako
@@ -333,7 +336,7 @@ additional :ref:`mako_template_renderer_settings`.
    single: response headers (from a renderer)
    single: renderer response headers
 
-.. _response_request_attrs:
+.. _request_response_attr:
 
 Varying Attributes of Rendered Responses
 ----------------------------------------
@@ -342,9 +345,43 @@ Before a response constructed by a :term:`renderer` is returned to
 :app:`Pyramid`, several attributes of the request are examined which have the
 potential to influence response behavior.
 
-View callables that don't directly return a response should set these
-attributes on the ``request`` object via ``setattr`` during their execution,
-to influence associated response attributes.
+View callables that don't directly return a response should use the API of
+the :class:`pyramid.response.Response` attribute available as
+``request.response`` during their execution, to influence associated response
+behavior.
+
+For example, if you need to change the response status from within a view
+callable that uses a renderer, assign the ``status`` attribute to the
+``response`` attribute of the request before returning a result:
+
+.. code-block:: python
+   :linenos:
+
+   from pyramid.view import view_config
+
+   @view_config(name='gone', renderer='templates/gone.pt')
+   def myview(request):
+       request.response.status = '404 Not Found'
+       return {'URL':request.URL}
+
+For more information on attributes of the request, see the API documentation
+in :ref:`request_module`.  For more information on the API of
+``request.response``, see :class:`pyramid.response.Response`.
+
+.. _response_prefixed_attrs:
+
+Deprecated Mechanism to Vary Attributes of Rendered Responses
+-------------------------------------------------------------
+
+.. warning:: This section describes behavior deprecated in Pyramid 1.1.
+
+In previous releases of Pyramid (1.0 and before), the ``request.response``
+attribute did not exist.  Instead, Pyramid required users to set special
+``response_`` -prefixed attributes of the request to influence response
+behavior.  As of Pyramid 1.1, those request attributes are deprecated and
+their use will cause a deprecation warning to be issued when used.  Until
+their existence is removed completely, we document them below, for benefit of
+people with older code bases.
 
 ``response_content_type``
   Defines the content-type of the resulting response,
@@ -367,23 +404,6 @@ to influence associated response attributes.
   returning various values in the ``response_headerlist``, this is purely a
   convenience.
 
-For example, if you need to change the response status from within a view
-callable that uses a renderer, assign the ``response_status`` attribute to
-the request before returning a result:
-
-.. code-block:: python
-   :linenos:
-
-   from pyramid.view import view_config
-
-   @view_config(name='gone', renderer='templates/gone.pt')
-   def myview(request):
-       request.response_status = '404 Not Found'
-       return {'URL':request.URL}
-
-For more information on attributes of the request, see the API
-documentation in :ref:`request_module`.
-
 .. index::
    single: renderer (adding)
 
diff --git a/docs/narr/templates.rst b/docs/narr/templates.rst
index 426ec229b..150b173e3 100644
--- a/docs/narr/templates.rst
+++ b/docs/narr/templates.rst
@@ -367,13 +367,13 @@ templates as renderers.  See :ref:`available_template_system_bindings`.
    render a view without needing to fork your code to do so.  See
    :ref:`extending_chapter` for more information.
 
-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 ``text/html``.  To vary attributes of the response
-of a view that uses a renderer, such as the content-type, headers, or
-status attributes, you must set attributes on the *request* object
-within the view before returning the dictionary.  See
-:ref:`response_request_attrs` for more information.
+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
+``text/html``.  To vary attributes of the response of a view that uses a
+renderer, such as the content-type, headers, or status attributes, you must
+use the API of the :class:`pyramid.response.Response` object exposed as
+``request.response`` within the view before returning the dictionary.  See
+:ref:`request_response_attr` for more information.
 
 The same set of system values are provided to templates rendered via a
 renderer view configuration as those provided to templates rendered
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index 219753882..1024dd188 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -54,17 +54,19 @@ Route Configuration
 -------------------
 
 :term:`Route configuration` is the act of adding a new :term:`route` to an
-application.  A route has a *pattern*, representing a pattern meant to match
+application.  A route has a *name*, which acts as an identifier to be used
+for URL generation.  The name also allows developers to associate a view
+configuration with the route.  A route also has a *pattern*, meant to match
 against the ``PATH_INFO`` portion of a URL (the portion following the scheme
-and port, e.g. ``/foo/bar`` in the URL ``http://localhost:8080/foo/bar``),
-and a *route name*, which is used by developers within a :app:`Pyramid`
-application to uniquely identify a particular route when generating a URL.
-It also optionally has a ``factory``, a set of :term:`route predicate`
-parameters, and a set of :term:`view` parameters.
+and port, e.g. ``/foo/bar`` in the URL ``http://localhost:8080/foo/bar``). It
+also optionally has a ``factory`` and a set of :term:`route predicate`
+attributes.
 
 .. index::
    single: add_route
 
+.. _config-add-route:
+
 Configuring a Route via The ``add_route`` Configurator Method
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -79,7 +81,8 @@ example:
    # pyramid.config.Configurator class; "myview" is assumed
    # to be a "view callable" function
    from views import myview
-   config.add_route('myroute', '/prefix/{one}/{two}', view=myview)
+   config.add_route('myroute', '/prefix/{one}/{two}')
+   config.add_view(myview, route_name='myroute')
 
 .. versionchanged:: 1.0a4
     Prior to 1.0a4, routes allow for a marker starting with a ``:``, for
@@ -89,9 +92,47 @@ example:
 .. index::
    single: route configuration; view callable
 
+.. _add_route_view_config:
+
 Route Configuration That Names a View Callable
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. warning:: This section describes a feature which has been deprecated in
+   Pyramid 1.1 and higher.  In order to reduce confusion and documentation
+   burden, passing view-related parameters to
+   :meth:`~pyramid.config.Configurator.add_route` is deprecated.
+
+   In versions earlier than 1.1, a view was permitted to be connected to a
+   route using a set of ``view*`` parameters passed to the
+   :meth:`~pyramid.config.Configurator.add_route`.  This was a shorthand
+   which replaced the need to perform a subsequent call to
+   :meth:`~pyramid.config.Configurator.add_view` as described in
+   :ref:`config-add-route`. For example, it was valid (and often recommended)
+   to do:
+
+   .. code-block:: python
+
+      config.add_route('home', '/', view='mypackage.views.myview',
+                        view_renderer='some/renderer.pt')
+
+   Instead of the equivalent:
+
+   .. code-block:: python
+
+     config.add_route('home', '/')
+     config.add_view('mypackage.views.myview', route_name='home')
+                     renderer='some/renderer.pt')
+
+   Passing ``view*`` arguments to ``add_route`` as shown in the first
+   example above is now deprecated in favor of connecting a view to a
+   predefined route via :meth:`~pyramid.config.Configurator.add_view` using
+   the route's ``route_name`` parameter, as shown in the second example
+   above.
+
+   A deprecation warning is now issued when any view-related parameter is
+   passed to ``Configurator.add_route``.  The recommended way to associate a
+   view with a route is documented in :ref:`config-add-route`.
+
 When a route configuration declaration names a ``view`` attribute, the value
 of the attribute will reference a :term:`view callable`.  This view callable
 will be invoked when the route matches.  A view callable, as described in
@@ -125,6 +166,9 @@ When a route configuration names a ``view`` attribute, the :term:`view
 callable` named as that ``view`` attribute will always be found and invoked
 when the associated route pattern matches during a request.
 
+See :meth:`pyramid.config.Configurator.add_route` for a description of
+view-related arguments.
+
 .. index::
    single: route path pattern syntax
 
@@ -363,8 +407,9 @@ resource of the view callable ultimately found via :term:`view lookup`.
 .. code-block:: python
    :linenos:
 
-   config.add_route('abc', '/abc', view='myproject.views.theview', 
+   config.add_route('abc', '/abc', 
                     factory='myproject.resources.root_factory')
+   config.add_view('myproject.views.theview', route_name='abc')
 
 The factory can either be a Python object or a :term:`dotted Python name` (a
 string) which points to such a Python object, as it is above.
@@ -395,7 +440,8 @@ process.  Examples of route predicate arguments are ``pattern``, ``xhr``, and
 ``request_method``.
 
 Other arguments are view configuration related arguments.  These only have an
-effect when the route configuration names a ``view``.
+effect when the route configuration names a ``view``. These arguments have
+been deprecated as of :app:`Pyramid` 1.1 (see :ref:`add_route_view_config`).
 
 Other arguments are ``name`` and ``factory``.  These arguments represent
 neither predicates nor view configuration information.
@@ -547,8 +593,8 @@ If any route matches, the route matching process stops.  The :term:`request`
 is decorated with a special :term:`interface` which describes it as a "route
 request", the :term:`context` resource is generated, and the context and the
 resulting request are handed off to :term:`view lookup`.  During view lookup,
-if any ``view`` argument was provided within the matched route configuration,
-the :term:`view callable` it points to is called.
+if a :term:`view callable` associated with the matched route is found, that
+view is called.
 
 When a route configuration is declared, it may contain :term:`route
 predicate` arguments.  All route predicates associated with a route
@@ -621,7 +667,8 @@ result in a particular view callable being invoked:
 .. code-block:: python
    :linenos:
 
-    config.add_route('idea', 'site/{id}', view='mypackage.views.site_view')
+    config.add_route('idea', 'site/{id}')
+    config.add_view('mypackage.views.site_view', route_name='idea')
 
 When a route configuration with a ``view`` attribute is added to the system,
 and an incoming request matches the *pattern* of the route configuration, the
@@ -665,9 +712,13 @@ add to your application:
 .. code-block:: python
    :linenos:
 
-   config.add_route('idea', 'ideas/{idea}', view='mypackage.views.idea_view')
-   config.add_route('user', 'users/{user}', view='mypackage.views.user_view')
-   config.add_route('tag', 'tags/{tags}', view='mypackage.views.tag_view')
+   config.add_route('idea', 'ideas/{idea}')
+   config.add_route('user', 'users/{user}')
+   config.add_route('tag', 'tags/{tags}')
+
+   config.add_view('mypackage.views.idea_view', route_name='idea')
+   config.add_view('mypackage.views.user_view', route_name='user')
+   config.add_view('mypackage.views.tag_view', route_name='tag')
 
 The above configuration will allow :app:`Pyramid` to service URLs in these
 forms:
@@ -717,9 +768,8 @@ An example of using a route with a factory:
 .. code-block:: python
    :linenos:
 
-   config.add_route('idea', 'ideas/{idea}', 
-                    view='myproject.views.idea_view',
-                    factory='myproject.resources.Idea')
+   config.add_route('idea', 'ideas/{idea}', factory='myproject.resources.Idea')
+   config.add_view('myproject.views.idea_view', route_name='idea')
 
 The above route will manufacture an ``Idea`` resource as a :term:`context`,
 assuming that ``mypackage.resources.Idea`` resolves to a class that accepts a
@@ -735,34 +785,6 @@ request in its ``__init__``.  For example:
 In a more complicated application, this root factory might be a class
 representing a :term:`SQLAlchemy` model.
 
-Example 4
-~~~~~~~~~
-
-It is possible to create a route declaration without a ``view`` attribute,
-but associate the route with a :term:`view callable` using a ``view``
-declaration.
-
-.. code-block:: python
-   :linenos:
-
-   config.add_route('idea', 'site/{id}')
-   config.add_view(route_name='idea', view='mypackage.views.site_view')
-
-This set of configuration parameters creates a configuration completely
-equivalent to this example provided in :ref:`urldispatch_example1`:
-
-.. code-block:: python
-   :linenos:
-
-   config.add_route('idea', 'site/{id}', view='mypackage.views.site_view')
-
-In fact, the spelling which names a ``view`` attribute is just syntactic
-sugar for the more verbose spelling which contains separate view and route
-registrations.
-
-More uses for this style of associating views with routes are explored in
-:ref:`hybrid_chapter`.
-
 .. index::
    single: matching the root URL
    single: root url (matching)
@@ -777,14 +799,14 @@ It's not entirely obvious how to use a route pattern to match the root URL
 .. code-block:: python
    :linenos:
 
-   config.add_route('root', '', view='mypackage.views.root_view')
+   config.add_route('root', '')
 
 Or provide the literal string ``/`` as the pattern:
 
 .. code-block:: python
    :linenos:
 
-   config.add_route('root', '/', view='mypackage.views.root_view')
+   config.add_route('root', '/')
 
 .. index::
    single: generating route URLs
@@ -834,10 +856,11 @@ route configuration looks like so:
 .. code-block:: python
    :linenos:
 
-   config.add_route('noslash', 'no_slash',
-                    view='myproject.views.no_slash')
-   config.add_route('hasslash', 'has_slash/', 
-                    view='myproject.views.has_slash')
+   config.add_route('noslash', 'no_slash')
+   config.add_route('hasslash', 'has_slash/')
+
+   config.add_view('myproject.views.no_slash', route_name='noslash')
+   config.add_view('myproject.views.has_slash', route_name='hasslash')
 
 If a request enters the application with the ``PATH_INFO`` value of
 ``/has_slash/``, the second route will match.  If a request enters the
@@ -864,8 +887,8 @@ the application's startup configuration, adding the following stanza:
 .. code-block:: python
    :linenos:
 
-   config.add_view(context='pyramid.exceptions.NotFound',
-                   view='pyramid.view.append_slash_notfound_view')
+   config.add_view('pyramid.view.append_slash_notfound_view', 
+                   context='pyramid.exceptions.NotFound')
 
 See :ref:`view_module` and :ref:`changing_the_notfound_view` for more
 information about the slash-appending not found view and for a more general
@@ -1063,30 +1086,25 @@ is executed.
 Route View Callable Registration and Lookup Details
 ---------------------------------------------------
 
-The purpose of making it possible to specify a view callable within a route
-configuration is to prevent developers from needing to deeply understand the
-details of :term:`resource location` and :term:`view lookup`.  When a route
-names a view callable as a ``view`` argument, and a request enters the system
-which matches the pattern of the route, the result is simple: the view
-callable associated with the route is invoked with the request that caused
-the invocation.
+When a request enters the system which matches the pattern of the route, the
+usual result is simple: the view callable associated with the route is
+invoked with the request that caused the invocation.
 
 For most usage, you needn't understand more than this; how it works is an
 implementation detail.  In the interest of completeness, however, we'll
 explain how it *does* work in the this section.  You can skip it if you're
 uninterested.
 
-When a ``view`` attribute is attached to a route configuration,
-:app:`Pyramid` ensures that a :term:`view configuration` is registered that
-will always be found when the route pattern is matched during a request.  To
-do so:
+When a view is associated with a route configuration, :app:`Pyramid` ensures
+that a :term:`view configuration` is registered that will always be found
+when the route pattern is matched during a request.  To do so:
 
 - A special route-specific :term:`interface` is created at startup time for
   each route configuration declaration.
 
-- When a route configuration declaration mentions a ``view`` attribute, a
+- When an ``add_view`` statement mentions a ``route name`` attribute, a
   :term:`view configuration` is registered at startup time.  This view
-  configuration uses the route-specific interface as a :term:`request` type.
+  configuration uses a route-specific interface as a :term:`request` type.
 
 - At runtime, when a request causes any route to match, the :term:`request`
   object is decorated with the route-specific interface.
diff --git a/docs/narr/viewconfig.rst b/docs/narr/viewconfig.rst
index 9b2500a2b..743cc016e 100644
--- a/docs/narr/viewconfig.rst
+++ b/docs/narr/viewconfig.rst
@@ -59,7 +59,8 @@ View configuration is performed in one of these ways:
 - By specifying a view within a :term:`route configuration`.  View
   configuration via a route configuration is performed by using the
   :meth:`pyramid.config.Configurator.add_route` method, passing a ``view``
-  argument specifying a view callable.
+  argument specifying a view callable. This pattern of view configuration is
+  deprecated as of :app:`Pyramid` 1.1.
 
 .. note:: A package named ``pyramid_handlers`` (available from PyPI) provides
    an analogue of :term:`Pylons` -style "controllers", which are a special
diff --git a/docs/narr/zca.rst b/docs/narr/zca.rst
index fcab0653e..19c52d0c9 100644
--- a/docs/narr/zca.rst
+++ b/docs/narr/zca.rst
@@ -66,15 +66,15 @@ more than a single application per process.  For example, use of a
 :term:`Paste` "composite" allows you to run separate individual WSGI
 applications in the same process, each answering requests for some URL
 prefix.  This makes it possible to run, for example, a TurboGears
-application at ``/turbogears`` and a BFG application at ``/bfg``, both
-served up using the same :term:`WSGI` server within a single Python
-process.
+application at ``/turbogears`` and a :app:`Pyramid` application at
+``/pyramid``, both served up using the same :term:`WSGI` server
+within a single Python 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 :app:`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
+application per Python process.  However, a :app:`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 :app:`Pyramid` application per
 process.
 
 In order to make it possible to run more than one :app:`Pyramid`
@@ -182,10 +182,10 @@ global ZCA API.  Without special treatment, the ZCA global APIs will
 always return the global ZCA registry (the one in
 ``zope.component.globalregistry.base``).
 
-To "fix" this and make the ZCA global APIs use the "current" BFG
-registry, you need to call
-:meth:`~pyramid.config.Configurator.hook_zca` within your
-setup code.  For example:
+To "fix" this and make the ZCA global APIs use the "current"
+:app:`Pyramid` registry, you need to call
+:meth:`~pyramid.config.Configurator.hook_zca` within your setup code.
+For example:
 
 .. code-block:: python
    :linenos:
@@ -253,7 +253,7 @@ Lines 5, 6, and 7 above are the interesting ones.  Line 5 retrieves
 the global ZCA component registry.  Line 6 creates a
 :term:`Configurator`, passing the global ZCA registry into its
 constructor as the ``registry`` argument.  Line 7 "sets up" the global
-registry with BFG-specific registrations; this is code that is
+registry with Pyramid-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.