Reorganized tutorial's part 4 to better understand changes needed in URLConf.

1 files changed, 16 insertions, 16 deletions

diff --git a/docs/intro/tutorial04.txt b/docs/intro/tutorial04.txt
index 726808a93d..13a76188bb 100644
--- a/docs/intro/tutorial04.txt
+++ b/docs/intro/tutorial04.txt
@@ -215,8 +215,12 @@ the database according to a parameter passed in the URL, loading a template and
 returning the rendered template. Because this is so common, Django provides a
 shortcut, called the "generic views" system.
 
-Generic views abstract common patterns to the point where you don't even need
-to write Python code to write an app.
+Generic views abstract common patterns to the point where you don't even need to
+write Python code to write an app. For example, the
+:class:`~django.views.generic.list.ListView` and
+:class:`~django.views.generic.detail.DetailView` generic views
+abstract the concepts of "display a list of objects" and
+"display a detail page for a particular type of object" respectively.
 
 Let's convert our poll app to use the generic views system, so we can delete a
 bunch of our own code. We'll have to take a few steps to make the conversion.
@@ -261,7 +265,11 @@ First, open the ``polls/urls.py`` URLconf and change it like so:
     ]
 
 Note that the name of the matched pattern in the path strings of the second and
-third patterns has changed from ``<question_id>`` to ``<pk>``.
+third patterns has changed from ``<question_id>`` to ``<pk>``. This is
+necessary because we'll use the
+:class:`~django.views.generic.detail.DetailView` generic view to replace our
+``detail()`` and ``results()`` views, and it expects the primary key value
+captured from the URL to be called ``"pk"``.
 
 Amend views
 -----------
@@ -303,19 +311,11 @@ views and use Django's generic views instead. To do so, open the
     def vote(request, question_id):
         ...  # same as above, no changes needed.
 
-We're using two generic views here:
-:class:`~django.views.generic.list.ListView` and
-:class:`~django.views.generic.detail.DetailView`. Respectively, those
-two views abstract the concepts of "display a list of objects" and
-"display a detail page for a particular type of object."
-
-* Each generic view needs to know what model it will be acting
-  upon. This is provided using the ``model`` attribute.
-
-* The :class:`~django.views.generic.detail.DetailView` generic view
-  expects the primary key value captured from the URL to be called
-  ``"pk"``, so we've changed ``question_id`` to ``pk`` for the generic
-  views.
+Each generic view needs to know what model it will be acting upon. This is
+provided using either the ``model`` attribute (in this example, ``model =
+Question`` for  ``DetailView`` and ``ResultsView``) or by defining the
+:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` method (as
+shown in ``IndexView``).
 
 By default, the :class:`~django.views.generic.detail.DetailView` generic
 view uses a template called ``<app name>/<model name>_detail.html``.