Fixed #17929 -- Improved tutorial wording and capitalization.
Thanks rmattb for the report and the patch.
| Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 11 KiB | 
| Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 32 KiB | 
| Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 19 KiB | 
| Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 11 KiB | 
| @@ -349,9 +349,10 @@ The first step in writing a database Web app in Django is to define your models | ||||
|    the :ref:`DRY Principle <dry>`. The goal is to define your data model in one | ||||
|    place and automatically derive things from it. | ||||
|  | ||||
| In our simple poll app, we'll create two models: polls and choices. A poll has | ||||
| a question and a publication date. A choice has two fields: the text of the | ||||
| choice and a vote tally. Each choice is associated with a poll. | ||||
| In our simple poll app, we'll create two models: ``Poll`` and ``Choice``. | ||||
| A ``Poll`` has a question and a publication date. A ``Choice`` has two fields: | ||||
| the text of the choice and a vote tally. Each ``Choice`` is associated with a | ||||
| ``Poll``. | ||||
|  | ||||
| These concepts are represented by simple Python classes. Edit the | ||||
| :file:`polls/models.py` file so it looks like this:: | ||||
| @@ -364,7 +365,7 @@ These concepts are represented by simple Python classes. Edit the | ||||
|  | ||||
|     class Choice(models.Model): | ||||
|         poll = models.ForeignKey(Poll) | ||||
|         choice = models.CharField(max_length=200) | ||||
|         choice_text = models.CharField(max_length=200) | ||||
|         votes = models.IntegerField() | ||||
|  | ||||
| The code is straightforward. Each model is represented by a class that | ||||
| @@ -394,8 +395,8 @@ Some :class:`~django.db.models.Field` classes have required elements. | ||||
| 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 | ||||
| to a single Poll. Django supports all the common database relationships: | ||||
| :class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related | ||||
| to a single ``Poll``. Django supports all the common database relationships: | ||||
| many-to-ones, many-to-manys and one-to-ones. | ||||
|  | ||||
| .. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path | ||||
| @@ -407,7 +408,7 @@ That small bit of model code gives Django a lot of information. With it, Django | ||||
| is able to: | ||||
|  | ||||
| * Create a database schema (``CREATE TABLE`` statements) for this app. | ||||
| * Create a Python database-access API for accessing Poll and Choice objects. | ||||
| * Create a Python database-access API for accessing ``Poll`` and ``Choice`` objects. | ||||
|  | ||||
| But first we need to tell our project that the ``polls`` app is installed. | ||||
|  | ||||
| @@ -456,7 +457,7 @@ statements for the polls app): | ||||
|     CREATE TABLE "polls_choice" ( | ||||
|         "id" serial NOT NULL PRIMARY KEY, | ||||
|         "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED, | ||||
|         "choice" varchar(200) NOT NULL, | ||||
|         "choice_text" varchar(200) NOT NULL, | ||||
|         "votes" integer NOT NULL | ||||
|     ); | ||||
|     COMMIT; | ||||
| @@ -607,7 +608,7 @@ of this object. Let's fix that by editing the polls model (in the | ||||
|     class Choice(models.Model): | ||||
|         # ... | ||||
|         def __unicode__(self): | ||||
|             return self.choice | ||||
|             return self.choice_text | ||||
|  | ||||
| It's important to add :meth:`~django.db.models.Model.__unicode__` methods to | ||||
| your models, not only for your own sanity when dealing with the interactive | ||||
| @@ -688,7 +689,7 @@ Save these changes and start a new Python interactive shell by running | ||||
|     True | ||||
|  | ||||
|     # Give the Poll a couple of Choices. The create call constructs a new | ||||
|     # choice object, does the INSERT statement, adds the choice to the set | ||||
|     # Choice object, does the INSERT statement, adds the choice to the set | ||||
|     # of available choices and returns the new Choice object. Django creates | ||||
|     # a set to hold the "other side" of a ForeignKey relation | ||||
|     # (e.g. a poll's choices) which can be accessed via the API. | ||||
| @@ -699,11 +700,11 @@ Save these changes and start a new Python interactive shell by running | ||||
|     [] | ||||
|  | ||||
|     # Create three choices. | ||||
|     >>> p.choice_set.create(choice='Not much', votes=0) | ||||
|     >>> p.choice_set.create(choice_text='Not much', votes=0) | ||||
|     <Choice: Not much> | ||||
|     >>> p.choice_set.create(choice='The sky', votes=0) | ||||
|     >>> p.choice_set.create(choice_text='The sky', votes=0) | ||||
|     <Choice: The sky> | ||||
|     >>> c = p.choice_set.create(choice='Just hacking again', votes=0) | ||||
|     >>> c = p.choice_set.create(choice_text='Just hacking again', votes=0) | ||||
|  | ||||
|     # Choice objects have API access to their related Poll objects. | ||||
|     >>> c.poll | ||||
| @@ -723,7 +724,7 @@ Save these changes and start a new Python interactive shell by running | ||||
|     [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>] | ||||
|  | ||||
|     # Let's delete one of the choices. Use delete() for that. | ||||
|     >>> c = p.choice_set.filter(choice__startswith='Just hacking') | ||||
|     >>> c = p.choice_set.filter(choice_text__startswith='Just hacking') | ||||
|     >>> c.delete() | ||||
|  | ||||
| For more information on model relations, see :doc:`Accessing related objects | ||||
|   | ||||
| @@ -276,11 +276,11 @@ in that window and click "Save," Django will save the poll to the database and | ||||
| dynamically add it as the selected choice on the "Add choice" form you're | ||||
| looking at. | ||||
|  | ||||
| But, really, this is an inefficient way of adding Choice objects to the system. | ||||
| But, really, this is an inefficient way of adding ``Choice`` objects to the system. | ||||
| It'd be better if you could add a bunch of Choices directly when you create the | ||||
| Poll object. Let's make that happen. | ||||
| ``Poll`` object. Let's make that happen. | ||||
|  | ||||
| Remove the ``register()`` call for the Choice model. Then, edit the ``Poll`` | ||||
| Remove the ``register()`` call for the ``Choice`` model. Then, edit the ``Poll`` | ||||
| registration code to read:: | ||||
|  | ||||
|     class ChoiceInline(admin.StackedInline): | ||||
| @@ -296,7 +296,7 @@ registration code to read:: | ||||
|  | ||||
|     admin.site.register(Poll, PollAdmin) | ||||
|  | ||||
| This tells Django: "Choice objects are edited on the Poll admin page. By | ||||
| This tells Django: "``Choice`` objects are edited on the ``Poll`` admin page. By | ||||
| default, provide enough fields for 3 choices." | ||||
|  | ||||
| Load the "Add poll" page to see how that looks, you may need to restart your development server: | ||||
| @@ -309,7 +309,7 @@ by ``extra`` -- and each time you come back to the "Change" page for an | ||||
| already-created object, you get another three extra slots. | ||||
|  | ||||
| One small problem, though. It takes a lot of screen space to display all the | ||||
| fields for entering related Choice objects. For that reason, Django offers a | ||||
| fields for entering related ``Choice`` objects. For that reason, Django offers a | ||||
| tabular way of displaying inline related objects; you just need to change | ||||
| the ``ChoiceInline`` declaration to read:: | ||||
|  | ||||
| @@ -397,7 +397,7 @@ search terms, Django will search the ``question`` field. You can use as many | ||||
| fields as you'd like -- although because it uses a ``LIKE`` query behind the | ||||
| scenes, keep it reasonable, to keep your database happy. | ||||
|  | ||||
| Finally, because Poll objects have dates, it'd be convenient to be able to | ||||
| Finally, because ``Poll`` objects have dates, it'd be convenient to be able to | ||||
| drill down by date. Add this line:: | ||||
|  | ||||
|     date_hierarchy = 'pub_date' | ||||
|   | ||||
| @@ -400,7 +400,7 @@ like: | ||||
|     <h1>{{ poll.question }}</h1> | ||||
|     <ul> | ||||
|     {% for choice in poll.choice_set.all %} | ||||
|         <li>{{ choice.choice }}</li> | ||||
|         <li>{{ choice.choice_text }}</li> | ||||
|     {% endfor %} | ||||
|     </ul> | ||||
|  | ||||
| @@ -412,7 +412,7 @@ list-index lookup. | ||||
|  | ||||
| Method-calling happens in the :ttag:`{% for %}<for>` loop: | ||||
| ``poll.choice_set.all`` is interpreted as the Python code | ||||
| ``poll.choice_set.all()``, which returns an iterable of Choice objects and is | ||||
| ``poll.choice_set.all()``, which returns an iterable of ``Choice`` objects and is | ||||
| suitable for use in the :ttag:`{% for %}<for>` tag. | ||||
|  | ||||
| See the :doc:`template guide </topics/templates>` for more about templates. | ||||
|   | ||||
| @@ -22,7 +22,7 @@ tutorial, so that the template contains an HTML ``<form>`` element: | ||||
|     {% csrf_token %} | ||||
|     {% for choice in poll.choice_set.all %} | ||||
|         <input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}" /> | ||||
|         <label for="choice{{ forloop.counter }}">{{ choice.choice }}</label><br /> | ||||
|         <label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br /> | ||||
|     {% endfor %} | ||||
|     <input type="submit" value="Vote" /> | ||||
|     </form> | ||||
| @@ -168,7 +168,7 @@ Now, create a ``results.html`` template: | ||||
|  | ||||
|     <ul> | ||||
|     {% for choice in poll.choice_set.all %} | ||||
|         <li>{{ choice.choice }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li> | ||||
|         <li>{{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li> | ||||
|     {% endfor %} | ||||
|     </ul> | ||||
|  | ||||
|   | ||||