diff options
author | Tim Graham <timograham@gmail.com> | 2013-01-01 08:12:42 -0500 |
---|---|---|
committer | Tim Graham <timograham@gmail.com> | 2013-01-02 18:32:57 -0500 |
commit | 9b5f64cc6ed5f1e904093fe4e6ff0f681b8e545f (patch) | |
tree | 72ad5a2f583f54b1be591dd727905c3e97b06a70 /docs/intro | |
parent | 3f890f8dc707eac30a72b7f79981d79e17ba0ff4 (diff) | |
download | django-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.txt | 4 | ||||
-rw-r--r-- | docs/intro/tutorial04.txt | 8 |
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 |