From 9b5f64cc6ed5f1e904093fe4e6ff0f681b8e545f Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Tue, 1 Jan 2013 08:12:42 -0500 Subject: Fixed #19516 - Fixed remaining broken links. Added -n to sphinx builds to catch issues going forward. --- docs/intro/tutorial01.txt | 4 ++-- docs/intro/tutorial04.txt | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) (limited to 'docs/intro') 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 ``/_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 ``/_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 -- cgit v1.3