diff --git a/docs/intro/_images/admin10.png b/docs/intro/_images/admin10.png index d720bafc6a..fc30df9fb8 100644 Binary files a/docs/intro/_images/admin10.png and b/docs/intro/_images/admin10.png differ diff --git a/docs/intro/_images/admin11.png b/docs/intro/_images/admin11.png index 54412836f8..8576fcb883 100644 Binary files a/docs/intro/_images/admin11.png and b/docs/intro/_images/admin11.png differ diff --git a/docs/intro/_images/admin11t.png b/docs/intro/_images/admin11t.png index 7140265172..81accc9d49 100644 Binary files a/docs/intro/_images/admin11t.png and b/docs/intro/_images/admin11t.png differ diff --git a/docs/intro/_images/admin12.png b/docs/intro/_images/admin12.png index 622123da4a..2b4b1abc71 100644 Binary files a/docs/intro/_images/admin12.png and b/docs/intro/_images/admin12.png differ diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt index b42806a484..250c0f1f41 100644 --- a/docs/intro/tutorial01.txt +++ b/docs/intro/tutorial01.txt @@ -349,9 +349,10 @@ The first step in writing a database Web app in Django is to define your models the :ref:`DRY Principle `. 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) - >>> p.choice_set.create(choice='The sky', votes=0) + >>> p.choice_set.create(choice_text='The sky', votes=0) - >>> 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 [, , ] # 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 diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt index ee9e3d0d12..0d95f6ff37 100644 --- a/docs/intro/tutorial02.txt +++ b/docs/intro/tutorial02.txt @@ -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' diff --git a/docs/intro/tutorial03.txt b/docs/intro/tutorial03.txt index c45c944acb..fd3a04ba93 100644 --- a/docs/intro/tutorial03.txt +++ b/docs/intro/tutorial03.txt @@ -400,7 +400,7 @@ like:

{{ poll.question }}

    {% for choice in poll.choice_set.all %} -
  • {{ choice.choice }}
    • +
  • {{ choice.choice_text }}
    • {% endfor %}
@@ -412,7 +412,7 @@ list-index lookup. Method-calling happens in the :ttag:`{% 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 %}` tag. See the :doc:`template guide ` for more about templates. diff --git a/docs/intro/tutorial04.txt b/docs/intro/tutorial04.txt index 8a9f4ee380..fac1433a8d 100644 --- a/docs/intro/tutorial04.txt +++ b/docs/intro/tutorial04.txt @@ -22,7 +22,7 @@ tutorial, so that the template contains an HTML ``
`` element: {% csrf_token %} {% for choice in poll.choice_set.all %} -
+
{% endfor %}
@@ -168,7 +168,7 @@ Now, create a ``results.html`` template:
    {% for choice in poll.choice_set.all %} -
  • {{ choice.choice }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}
    • +
  • {{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}
    • {% endfor %}