summaryrefslogtreecommitdiff
path: root/docs/intro
diff options
context:
space:
mode:
authorTim Graham <timograham@gmail.com>2013-01-01 08:12:42 -0500
committerTim Graham <timograham@gmail.com>2013-01-02 18:32:57 -0500
commit9b5f64cc6ed5f1e904093fe4e6ff0f681b8e545f (patch)
tree72ad5a2f583f54b1be591dd727905c3e97b06a70 /docs/intro
parent3f890f8dc707eac30a72b7f79981d79e17ba0ff4 (diff)
downloaddjango-9b5f64cc6ed5f1e904093fe4e6ff0f681b8e545f.tar.gz
Fixed #19516 - Fixed remaining broken links.
Added -n to sphinx builds to catch issues going forward.
Diffstat (limited to 'docs/intro')
-rw-r--r--docs/intro/tutorial01.txt4
-rw-r--r--docs/intro/tutorial04.txt8
2 files changed, 6 insertions, 6 deletions
diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index ab6c8b999f..632f27f2d2 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -369,8 +369,8 @@ its human-readable name.
Some :class:`~django.db.models.Field` classes have required elements.
:class:`~django.db.models.CharField`, for example, requires that you give it a
-:attr:`~django.db.models.Field.max_length`. That's used not only in the database
-schema, but in validation, as we'll soon see.
+:attr:`~django.db.models.CharField.max_length`. That's used not only in the
+database schema, but in validation, as we'll soon see.
Finally, note a relationship is defined, using
:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
diff --git a/docs/intro/tutorial04.txt b/docs/intro/tutorial04.txt
index 333ef9fbc3..f047067aa7 100644
--- a/docs/intro/tutorial04.txt
+++ b/docs/intro/tutorial04.txt
@@ -234,12 +234,12 @@ two views abstract the concepts of "display a list of objects" and
* Each generic view needs to know what model it will be acting
upon. This is provided using the ``model`` parameter.
-* The :class:`~django.views.generic.list.DetailView` generic view
+* 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 ``poll_id`` to ``pk`` for the generic
views.
-By default, the :class:`~django.views.generic.list.DetailView` generic
+By default, the :class:`~django.views.generic.detail.DetailView` generic
view uses a template called ``<app name>/<model name>_detail.html``.
In our case, it'll use the template ``"polls/poll_detail.html"``. The
``template_name`` argument is used to tell Django to use a specific
@@ -247,7 +247,7 @@ template name instead of the autogenerated default template name. We
also specify the ``template_name`` for the ``results`` list view --
this ensures that the results view and the detail view have a
different appearance when rendered, even though they're both a
-:class:`~django.views.generic.list.DetailView` behind the scenes.
+:class:`~django.views.generic.detail.DetailView` behind the scenes.
Similarly, the :class:`~django.views.generic.list.ListView` generic
view uses a default template called ``<app name>/<model
@@ -257,7 +257,7 @@ name>_list.html``; we use ``template_name`` to tell
In previous parts of the tutorial, the templates have been provided
with a context that contains the ``poll`` and ``latest_poll_list``
-context variables. For DetailView the ``poll`` variable is provided
+context variables. For ``DetailView`` the ``poll`` variable is provided
automatically -- since we're using a Django model (``Poll``), Django
is able to determine an appropriate name for the context variable.
However, for ListView, the automatically generated context variable is