summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorChris McDonough <chrism@plope.com>2011-04-22 13:45:13 -0400
committerChris McDonough <chrism@plope.com>2011-04-22 13:45:13 -0400
commit1440e9828fcd527ff79de0655ee65d3076f13911 (patch)
tree53637b76d148774c5a7c3b9e103373e33e6c2f9e /docs
parentfeef5257261f3c37f11571a475dbd68f603b144e (diff)
parented7ffe0e2065100f551793b3774656d8bdde0fb0 (diff)
downloadpyramid-1440e9828fcd527ff79de0655ee65d3076f13911.tar.gz
pyramid-1440e9828fcd527ff79de0655ee65d3076f13911.tar.bz2
pyramid-1440e9828fcd527ff79de0655ee65d3076f13911.zip
Merge branch 'mmerickel-disambiguate_add_route'
Diffstat (limited to 'docs')
-rw-r--r--docs/narr/advconfig.rst12
-rw-r--r--docs/narr/assets.rst7
-rw-r--r--docs/narr/hybrid.rst59
-rw-r--r--docs/narr/urldispatch.rst152
-rw-r--r--docs/narr/viewconfig.rst3
-rw-r--r--docs/tutorials/wiki2/authorization.rst12
-rw-r--r--docs/tutorials/wiki2/basiclayout.rst32
-rw-r--r--docs/tutorials/wiki2/definingviews.rst38
-rw-r--r--docs/tutorials/wiki2/src/authorization/tutorial/__init__.py39
-rw-r--r--docs/tutorials/wiki2/src/basiclayout/tutorial/__init__.py5
-rw-r--r--docs/tutorials/wiki2/src/models/tutorial/__init__.py5
-rw-r--r--docs/tutorials/wiki2/src/views/tutorial/__init__.py21
12 files changed, 213 insertions, 172 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/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/urldispatch.rst b/docs/narr/urldispatch.rst
index 219753882..4923fd19f 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 :ref:`add_route_view_related_api` for a description of view-related
+arguments to ``add_route``.
+
.. 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/tutorials/wiki2/authorization.rst b/docs/tutorials/wiki2/authorization.rst
index 64cab30db..d0354af99 100644
--- a/docs/tutorials/wiki2/authorization.rst
+++ b/docs/tutorials/wiki2/authorization.rst
@@ -97,25 +97,25 @@ We'll also change ``__init__.py``, adding a call to
:term:`view callable`. This is also known as a :term:`forbidden view`:
.. literalinclude:: src/authorization/tutorial/__init__.py
- :lines: 24-26
+ :lines: 41-43
:linenos:
:language: python
A forbidden view configures our newly created login view to show up when
:app:`Pyramid` detects that a view invocation can not be authorized.
-We'll also add ``view_permission`` arguments with the value ``edit`` to the
-``edit_page`` and ``add_page`` routes. This indicates that the view
-callables which these routes reference cannot be invoked without the
+We'll also add ``permission`` arguments with the value ``edit`` to the
+``edit_page`` and ``add_page`` views. This indicates that the view
+callables which these views reference cannot be invoked without the
authenticated user possessing the ``edit`` permission with respect to the
current context.
.. literalinclude:: src/authorization/tutorial/__init__.py
- :lines: 32-39
+ :lines: 37-40
:linenos:
:language: python
-Adding these ``view_permission`` arguments causes Pyramid to make the
+Adding these ``permission`` arguments causes Pyramid to make the
assertion that only users who possess the effective ``edit`` permission at
the time of the request may invoke those two views. We've granted the
``group:editors`` principal the ``edit`` permission at the root model via its
diff --git a/docs/tutorials/wiki2/basiclayout.rst b/docs/tutorials/wiki2/basiclayout.rst
index 0dbcf6684..82e112c64 100644
--- a/docs/tutorials/wiki2/basiclayout.rst
+++ b/docs/tutorials/wiki2/basiclayout.rst
@@ -81,28 +81,34 @@ via the :meth:`pyramid.config.Configurator.add_route` method that will be
used when the URL is ``/``:
.. literalinclude:: src/basiclayout/tutorial/__init__.py
- :lines: 13-14
+ :lines: 13
:language: py
Since this route has a ``pattern`` equalling ``/`` it is the route that will
-be called when the URL ``/`` is visted, e.g. ``http://localhost:6543/``. The
-argument named ``view`` with the value ``tutorial.views.my_view`` is the
+be matched when the URL ``/`` is visted, e.g. ``http://localhost:6543/``.
+
+Mapping the ``home`` route to code is done by registering a view. You will
+use :meth:`pyramid.config.Configurator.add_view` in :term:`URL dispatch` to
+register views for the routes, mapping your patterns to code:
+
+ .. literalinclude:: src/basiclayout/tutorial/__init__.py
+ :lines: 14
+ :language: py
+
+The first positional ``add_view`` argument ``tutorial.views.my_view`` is the
dotted name to a *function* we write (generated by the
``pyramid_routesalchemy`` scaffold) that is given a ``request`` object and
-which returns a response or a dictionary.
-
-You will use :meth:`pyramid.config.Configurator.add_route` statements in a
-:term:`URL dispatch` based application to map URLs to code. This route also
-names a ``view_renderer``, which is a template which lives in the
-``templates`` subdirectory of the package. When the
-``tutorial.views.my_view`` view returns a dictionary, a :term:`renderer` will
-use this template to create a response.
+which returns a response or a dictionary. This view also names a
+``renderer``, which is a template which lives in the ``templates``
+subdirectory of the package. When the ``tutorial.views.my_view`` view
+returns a dictionary, a :term:`renderer` will use this template to create a
+response. This
-Fimnally, we use the :meth:`pyramid.config.Configurator.make_wsgi_app`
+Finally, we use the :meth:`pyramid.config.Configurator.make_wsgi_app`
method to return a :term:`WSGI` application:
.. literalinclude:: src/basiclayout/tutorial/__init__.py
- :lines: 15
+ :lines: 16
:language: py
Our final ``__init__.py`` file will look like this:
diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst
index c5a452d11..832f90b92 100644
--- a/docs/tutorials/wiki2/definingviews.rst
+++ b/docs/tutorials/wiki2/definingviews.rst
@@ -272,8 +272,8 @@ Mapping Views to URLs in ``__init__.py``
========================================
The ``__init__.py`` file contains
-:meth:`pyramid.config.Configurator.add_route` calls which serve to map
-URLs via :term:`url dispatch` to view functions. First, we’ll get rid of the
+:meth:`pyramid.config.Configurator.add_view` calls which serve to map
+routes via :term:`url dispatch` to views. First, we’ll get rid of the
existing route created by the template using the name ``home``. It’s only an
example and isn’t relevant to our application.
@@ -282,21 +282,33 @@ these declarations is very important. ``route`` declarations are matched in
the order they're found in the ``__init__.py`` file.
#. Add a declaration which maps the pattern ``/`` (signifying the root URL)
- to the view named ``view_wiki`` in our ``views.py`` file with the name
- ``view_wiki``. This is the :term:`default view` for the wiki.
+ to the route named ``view_wiki``.
-#. Add a declaration which maps the pattern ``/{pagename}`` to the view named
- ``view_page`` in our ``views.py`` file with the view name ``view_page``.
- This is the regular view for a page.
+#. Add a declaration which maps the pattern ``/{pagename}`` to the route named
+ ``view_page``. This is the regular view for a page.
-#. Add a declaration which maps the pattern
- ``/add_page/{pagename}`` to the view named ``add_page`` in our
- ``views.py`` file with the name ``add_page``. This is the add view
- for a new page.
+#. Add a declaration which maps the pattern ``/add_page/{pagename}`` to the
+ route named ``add_page``. This is the add view for a new page.
#. Add a declaration which maps the pattern ``/{pagename}/edit_page`` to the
- view named ``edit_page`` in our ``views.py`` file with the name
- ``edit_page``. This is the edit view for a page.
+ route named ``edit_page``. This is the edit view for a page.
+
+After we've defined the routes for our application, we can register views
+to handle the processing and rendering that needs to happen when each route is
+requested.
+
+#. Add a declaration which maps the ``view_wiki`` route to the view named
+ ``view_wiki`` in our ``views.py`` file. This is the :term:`default view`
+ for the wiki.
+
+#. Add a declaration which maps the ``view_page`` route to the view named
+ ``view_page`` in our ``views.py`` file.
+
+#. Add a declaration which maps the ``add_page`` route to the view named
+ ``add_page`` in our ``views.py`` file.
+
+#. Add a declaration which maps the ``edit_page`` route to the view named
+ ``edit_page`` in our ``views.py`` file.
As a result of our edits, the ``__init__.py`` file should look
something like so:
diff --git a/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py b/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py
index 025b94927..e8baa568c 100644
--- a/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py
+++ b/docs/tutorials/wiki2/src/authorization/tutorial/__init__.py
@@ -20,25 +20,26 @@ def main(global_config, **settings):
authentication_policy=authn_policy,
authorization_policy=authz_policy)
config.add_static_view('static', 'tutorial:static')
- config.add_route('view_wiki', '/', view='tutorial.views.view_wiki')
- config.add_route('login', '/login',
- view='tutorial.login.login',
- view_renderer='tutorial:templates/login.pt')
- config.add_route('logout', '/logout',
- view='tutorial.login.logout')
- config.add_route('view_page', '/{pagename}',
- view='tutorial.views.view_page',
- view_renderer='tutorial:templates/view.pt')
- config.add_route('add_page', '/add_page/{pagename}',
- view='tutorial.views.add_page',
- view_renderer='tutorial:templates/edit.pt',
- view_permission='edit')
- config.add_route('edit_page', '/{pagename}/edit_page',
- view='tutorial.views.edit_page',
- view_renderer='tutorial:templates/edit.pt',
- view_permission='edit')
+
+ config.add_route('view_wiki', '/')
+ config.add_route('login', '/login')
+ config.add_route('logout', '/logout')
+ config.add_route('view_page', '/{pagename}')
+ config.add_route('add_page', '/add_page/{pagename}')
+ config.add_route('edit_page', '/{pagename}/edit_page')
+ config.add_route('view_wiki', '/')
+
+ config.add_view('tutorial.login.login', route_name='login',
+ renderer='tutorial:templates/login.pt')
+ config.add_view('tutorial.login.logout', route_name='logout')
+ config.add_view('tutorial.views.view_page', route_name='view_page',
+ renderer='tutorial:templates/view.pt')
+ config.add_view('tutorial.views.add_page', route_name='add_page',
+ renderer='tutorial:templates/edit.pt', permission='edit')
+ config.add_view('tutorial.views.edit_page', route_name='edit_page',
+ renderer='tutorial:templates/edit.pt', permission='edit')
config.add_view('tutorial.login.login',
- renderer='tutorial:templates/login.pt',
- context='pyramid.exceptions.Forbidden')
+ context='pyramid.exceptions.Forbidden',
+ renderer='tutorial:templates/login.pt')
return config.make_wsgi_app()
diff --git a/docs/tutorials/wiki2/src/basiclayout/tutorial/__init__.py b/docs/tutorials/wiki2/src/basiclayout/tutorial/__init__.py
index d27b891c0..c74f07652 100644
--- a/docs/tutorials/wiki2/src/basiclayout/tutorial/__init__.py
+++ b/docs/tutorials/wiki2/src/basiclayout/tutorial/__init__.py
@@ -10,8 +10,9 @@ def main(global_config, **settings):
initialize_sql(engine)
config = Configurator(settings=settings)
config.add_static_view('static', 'tutorial:static')
- config.add_route('home', '/', view='tutorial.views.my_view',
- view_renderer='templates/mytemplate.pt')
+ config.add_route('home', '/')
+ config.add_view('tutorial.views.my_view', route_name='home',
+ renderer='templates/mytemplate.pt')
return config.make_wsgi_app()
diff --git a/docs/tutorials/wiki2/src/models/tutorial/__init__.py b/docs/tutorials/wiki2/src/models/tutorial/__init__.py
index c912a015b..ecc41ca9f 100644
--- a/docs/tutorials/wiki2/src/models/tutorial/__init__.py
+++ b/docs/tutorials/wiki2/src/models/tutorial/__init__.py
@@ -10,6 +10,7 @@ def main(global_config, **settings):
initialize_sql(engine)
config = Configurator(settings=settings)
config.add_static_view('static', 'tutorial:static')
- config.add_route('home', '/', view='tutorial.views.my_view',
- view_renderer='templates/mytemplate.pt')
+ config.add_route('home', '/')
+ config.add_view('tutorial.views.my_view', route_name='home',
+ renderer='templates/mytemplate.pt')
return config.make_wsgi_app()
diff --git a/docs/tutorials/wiki2/src/views/tutorial/__init__.py b/docs/tutorials/wiki2/src/views/tutorial/__init__.py
index 1a8d24499..ad89c124e 100644
--- a/docs/tutorials/wiki2/src/views/tutorial/__init__.py
+++ b/docs/tutorials/wiki2/src/views/tutorial/__init__.py
@@ -10,15 +10,16 @@ def main(global_config, **settings):
initialize_sql(engine)
config = Configurator(settings=settings)
config.add_static_view('static', 'tutorial:static')
- config.add_route('view_wiki', '/', view='tutorial.views.view_wiki')
- config.add_route('view_page', '/{pagename}',
- view='tutorial.views.view_page',
- view_renderer='tutorial:templates/view.pt')
- config.add_route('add_page', '/add_page/{pagename}',
- view='tutorial.views.add_page',
- view_renderer='tutorial:templates/edit.pt')
- config.add_route('edit_page', '/{pagename}/edit_page',
- view='tutorial.views.edit_page',
- view_renderer='tutorial:templates/edit.pt')
+ config.add_route('view_wiki', '/')
+ config.add_route('view_page', '/{pagename}')
+ config.add_route('add_page', '/add_page/{pagename}')
+ config.add_route('edit_page', '/{pagename}/edit_page')
+ config.add_view('tutorial.views.view_wiki', route_name='view_wiki')
+ config.add_view('tutorial.views.view_page', route_name='view_page',
+ renderer='tutorial:templates/view.pt')
+ config.add_view('tutorial.views.add_page', route_name='add_page',
+ renderer='tutorial:templates/edit.pt')
+ config.add_view('tutorial.views.edit_page', route_name='edit_page',
+ renderer='tutorial:templates/edit.pt')
return config.make_wsgi_app()