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
|
the :ref:`DRY Principle <dry>`. The goal is to define your data model in one
|
||||||
place and automatically derive things from it.
|
place and automatically derive things from it.
|
||||||
|
|
||||||
In our simple poll app, we'll create two models: polls and choices. A poll has
|
In our simple poll app, we'll create two models: ``Poll`` and ``Choice``.
|
||||||
a question and a publication date. A choice has two fields: the text of the
|
A ``Poll`` has a question and a publication date. A ``Choice`` has two fields:
|
||||||
choice and a vote tally. Each choice is associated with a poll.
|
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
|
These concepts are represented by simple Python classes. Edit the
|
||||||
:file:`polls/models.py` file so it looks like this::
|
: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):
|
class Choice(models.Model):
|
||||||
poll = models.ForeignKey(Poll)
|
poll = models.ForeignKey(Poll)
|
||||||
choice = models.CharField(max_length=200)
|
choice_text = models.CharField(max_length=200)
|
||||||
votes = models.IntegerField()
|
votes = models.IntegerField()
|
||||||
|
|
||||||
The code is straightforward. Each model is represented by a class that
|
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.
|
schema, but in validation, as we'll soon see.
|
||||||
|
|
||||||
Finally, note a relationship is defined, using
|
Finally, note a relationship is defined, using
|
||||||
:class:`~django.db.models.ForeignKey`. That tells Django each Choice is related
|
:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
|
||||||
to a single Poll. Django supports all the common database relationships:
|
to a single ``Poll``. Django supports all the common database relationships:
|
||||||
many-to-ones, many-to-manys and one-to-ones.
|
many-to-ones, many-to-manys and one-to-ones.
|
||||||
|
|
||||||
.. _`Python path`: http://docs.python.org/tutorial/modules.html#the-module-search-path
|
.. _`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:
|
is able to:
|
||||||
|
|
||||||
* Create a database schema (``CREATE TABLE`` statements) for this app.
|
* 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.
|
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" (
|
CREATE TABLE "polls_choice" (
|
||||||
"id" serial NOT NULL PRIMARY KEY,
|
"id" serial NOT NULL PRIMARY KEY,
|
||||||
"poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED,
|
"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
|
"votes" integer NOT NULL
|
||||||
);
|
);
|
||||||
COMMIT;
|
COMMIT;
|
||||||
@ -607,7 +608,7 @@ of this object. Let's fix that by editing the polls model (in the
|
|||||||
class Choice(models.Model):
|
class Choice(models.Model):
|
||||||
# ...
|
# ...
|
||||||
def __unicode__(self):
|
def __unicode__(self):
|
||||||
return self.choice
|
return self.choice_text
|
||||||
|
|
||||||
It's important to add :meth:`~django.db.models.Model.__unicode__` methods to
|
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
|
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
|
True
|
||||||
|
|
||||||
# Give the Poll a couple of Choices. The create call constructs a new
|
# 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
|
# of available choices and returns the new Choice object. Django creates
|
||||||
# a set to hold the "other side" of a ForeignKey relation
|
# a set to hold the "other side" of a ForeignKey relation
|
||||||
# (e.g. a poll's choices) which can be accessed via the API.
|
# (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.
|
# 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>
|
<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>
|
<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.
|
# Choice objects have API access to their related Poll objects.
|
||||||
>>> c.poll
|
>>> 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>]
|
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
|
||||||
|
|
||||||
# Let's delete one of the choices. Use delete() for that.
|
# 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()
|
>>> c.delete()
|
||||||
|
|
||||||
For more information on model relations, see :doc:`Accessing related objects
|
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
|
dynamically add it as the selected choice on the "Add choice" form you're
|
||||||
looking at.
|
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
|
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::
|
registration code to read::
|
||||||
|
|
||||||
class ChoiceInline(admin.StackedInline):
|
class ChoiceInline(admin.StackedInline):
|
||||||
@ -296,7 +296,7 @@ registration code to read::
|
|||||||
|
|
||||||
admin.site.register(Poll, PollAdmin)
|
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."
|
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:
|
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.
|
already-created object, you get another three extra slots.
|
||||||
|
|
||||||
One small problem, though. It takes a lot of screen space to display all the
|
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
|
tabular way of displaying inline related objects; you just need to change
|
||||||
the ``ChoiceInline`` declaration to read::
|
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
|
fields as you'd like -- although because it uses a ``LIKE`` query behind the
|
||||||
scenes, keep it reasonable, to keep your database happy.
|
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::
|
drill down by date. Add this line::
|
||||||
|
|
||||||
date_hierarchy = 'pub_date'
|
date_hierarchy = 'pub_date'
|
||||||
|
@ -400,7 +400,7 @@ like:
|
|||||||
<h1>{{ poll.question }}</h1>
|
<h1>{{ poll.question }}</h1>
|
||||||
<ul>
|
<ul>
|
||||||
{% for choice in poll.choice_set.all %}
|
{% for choice in poll.choice_set.all %}
|
||||||
<li>{{ choice.choice }}</li>
|
<li>{{ choice.choice_text }}</li>
|
||||||
{% endfor %}
|
{% endfor %}
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
@ -412,7 +412,7 @@ list-index lookup.
|
|||||||
|
|
||||||
Method-calling happens in the :ttag:`{% for %}<for>` loop:
|
Method-calling happens in the :ttag:`{% for %}<for>` loop:
|
||||||
``poll.choice_set.all`` is interpreted as the Python code
|
``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.
|
suitable for use in the :ttag:`{% for %}<for>` tag.
|
||||||
|
|
||||||
See the :doc:`template guide </topics/templates>` for more about templates.
|
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 %}
|
{% csrf_token %}
|
||||||
{% for choice in poll.choice_set.all %}
|
{% for choice in poll.choice_set.all %}
|
||||||
<input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}" />
|
<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 %}
|
{% endfor %}
|
||||||
<input type="submit" value="Vote" />
|
<input type="submit" value="Vote" />
|
||||||
</form>
|
</form>
|
||||||
@ -168,7 +168,7 @@ Now, create a ``results.html`` template:
|
|||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
{% for choice in poll.choice_set.all %}
|
{% 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 %}
|
{% endfor %}
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
|