From f1edb8c2b304aad9e31f1488a97a28ba56b1a709 Mon Sep 17 00:00:00 2001 From: Adrian Holovaty Date: Tue, 7 Aug 2007 02:33:11 +0000 Subject: [PATCH] Fixed #5097 -- Made various updates and corrections to the documentation. Thanks, Nicola Larosa git-svn-id: http://code.djangoproject.com/svn/django/trunk@5825 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/contributing.txt | 8 +++----- docs/i18n.txt | 2 +- docs/model-api.txt | 20 ++++++++++---------- docs/overview.txt | 6 +++--- docs/tutorial01.txt | 14 +++++++------- docs/tutorial02.txt | 6 +++--- 6 files changed, 27 insertions(+), 29 deletions(-) diff --git a/docs/contributing.txt b/docs/contributing.txt index faa4c113f1..61c368d32a 100644 --- a/docs/contributing.txt +++ b/docs/contributing.txt @@ -545,11 +545,9 @@ To run the tests, ``cd`` to the ``tests/`` directory and type:: ./runtests.py --settings=path.to.django.settings Yes, the unit tests need a settings module, but only for database connection -info -- the ``DATABASE_NAME`` (required, but will be ignored), -``DATABASE_ENGINE``, ``DATABASE_USER`` and ``DATABASE_PASSWORD`` settings. You -will also need a ``ROOT_URLCONF`` setting (its value is ignored; it just needs -to be present) and a ``SITE_ID`` setting (any non-zero integer value will do) -in order for all the tests to pass. +info, with the ``DATABASE_ENGINE`` setting. You will also need a ``ROOT_URLCONF`` +setting (its value is ignored; it just needs to be present) and a ``SITE_ID`` +setting (any non-zero integer value will do) in order for all the tests to pass. The unit tests will not touch your existing databases; they create a new database, called ``django_test_db``, which is deleted when the tests are diff --git a/docs/i18n.txt b/docs/i18n.txt index 9fe02c0342..38252edeb1 100644 --- a/docs/i18n.txt +++ b/docs/i18n.txt @@ -263,7 +263,7 @@ To pluralize, specify both the singular and plural forms with the Internally, all block and inline translations use the appropriate ``ugettext`` / ``ungettext`` call. -Each ``RequestContext`` has access to two translation-specific variables: +Each ``RequestContext`` has access to three translation-specific variables: * ``LANGUAGES`` is a list of tuples in which the first element is the language code and the second is the language name (in that language). diff --git a/docs/model-api.txt b/docs/model-api.txt index 3b634de1d8..ddeb481206 100644 --- a/docs/model-api.txt +++ b/docs/model-api.txt @@ -150,7 +150,7 @@ Django veterans: Note that the argument is now called ``max_length`` to provide consistency throughout Django. There is full legacy support for the old ``maxlength`` argument, but ``max_length`` is prefered. - ``CommaSeparatedIntegerField`` +``CommaSeparatedIntegerField`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A field of integers separated by commas. As in ``CharField``, the ``max_length`` @@ -737,7 +737,7 @@ Many-to-one relationships To define a many-to-one relationship, use ``ForeignKey``. You use it just like any other ``Field`` type: by including it as a class attribute of your model. -``ForeignKey`` requires a positional argument: The class to which the model is +``ForeignKey`` requires a positional argument: the class to which the model is related. For example, if a ``Car`` model has a ``Manufacturer`` -- that is, a @@ -872,7 +872,7 @@ To define a many-to-many relationship, use ``ManyToManyField``. You use it just like any other ``Field`` type: by including it as a class attribute of your model. -``ManyToManyField`` requires a positional argument: The class to which the +``ManyToManyField`` requires a positional argument: the class to which the model is related. For example, if a ``Pizza`` has multiple ``Topping`` objects -- that is, a @@ -969,7 +969,7 @@ model. This is most useful on the primary key of an object when that object "extends" another object in some way. -``OneToOneField`` requires a positional argument: The class to which the +``OneToOneField`` requires a positional argument: the class to which the model is related. For example, if you're building a database of "places", you would build pretty @@ -1421,8 +1421,8 @@ that displays the ``__str__()`` representation of each object. A few special cases to note about ``list_display``: - * If the field is a ``ForeignKey``, Django will display the ``__str__()`` - of the related object. + * If the field is a ``ForeignKey``, Django will display the + ``__unicode__()`` of the related object. * ``ManyToManyField`` fields aren't supported, because that would entail executing a separate SQL statement for each row in the table. If you @@ -1672,7 +1672,7 @@ with an operator: AND (first_name ILIKE 'lennon' OR last_name ILIKE 'lennon') Note that the query input is split by spaces, so, following this example, - it's not currently not possible to search for all records in which + it's currently not possible to search for all records in which ``first_name`` is exactly ``'john winston'`` (containing a space). ``@`` @@ -1956,7 +1956,7 @@ Also, a couple of other bits of Django, such as the `syndication feed framework` use ``get_absolute_url()`` as a convenience to reward people who've defined the method. -.. syndication feed framework: ../syndication_feeds/ +.. _syndication feed framework: ../syndication_feeds/ It's good practice to use ``get_absolute_url()`` in templates, instead of hard-coding your objects' URLs. For example, this template code is bad:: @@ -2015,8 +2015,8 @@ Similarly, if you had a URLconf entry that looked like:: 'day': self.created.day}) get_absolute_url = permalink(get_absolute_url) -Notice that we specify an empty sequence for the second argument in this case, -because we only want to pass keyword arguments, not named arguments. +Notice that we specify an empty sequence for the second parameter in this case, +because we only want to pass keyword parameters, not positional ones. In this way, you're tying the model's absolute URL to the view that is used to display it, without repeating the URL information anywhere. You can still diff --git a/docs/overview.txt b/docs/overview.txt index b0311cee96..0fd1be5c85 100644 --- a/docs/overview.txt +++ b/docs/overview.txt @@ -54,7 +54,7 @@ Enjoy the free API ================== With that, you've got a free, and rich, Python API to access your data. The API -is created on the fly: No code generation necessary:: +is created on the fly, no code generation necessary:: >>> from mysite.models import Reporter, Article @@ -124,7 +124,7 @@ is created on the fly: No code generation necessary:: # Delete an object with delete(). >>> r.delete() -A dynamic admin interface: It's not just scaffolding -- it's the whole house +A dynamic admin interface: it's not just scaffolding -- it's the whole house ============================================================================ Once your models are defined, Django can automatically create a professional, @@ -250,7 +250,7 @@ Finally, Django uses the concept of "template inheritance": That's what the ``{% extends "base.html" %}`` does. It means "First load the template called 'base', which has defined a bunch of blocks, and fill the blocks with the following blocks." In short, that lets you dramatically cut down on redundancy -in templates: Each template has to define only what's unique to that template. +in templates: each template has to define only what's unique to that template. Here's what the "base.html" template might look like:: diff --git a/docs/tutorial01.txt b/docs/tutorial01.txt index 32480ca487..4f39fb4141 100644 --- a/docs/tutorial01.txt +++ b/docs/tutorial01.txt @@ -461,10 +461,10 @@ Once you're in the shell, explore the database API:: >>> p.question "What's up?" >>> p.pub_date - datetime.datetime(2005, 7, 15, 12, 00, 53) + datetime.datetime(2007, 7, 15, 12, 00, 53) # Change values by changing the attributes, then calling save(). - >>> p.pub_date = datetime(2005, 4, 1, 0, 0) + >>> p.pub_date = datetime(2007, 4, 1, 0, 0) >>> p.save() # objects.all() displays all the polls in the database. @@ -537,9 +537,9 @@ Let's jump back into the Python interactive shell by running >>> Poll.objects.filter(question__startswith='What') [] - # Get the poll whose year is 2005. Of course, if you're going through this + # Get the poll whose year is 2007. Of course, if you're going through this # tutorial in another year, change as appropriate. - >>> Poll.objects.get(pub_date__year=2005) + >>> Poll.objects.get(pub_date__year=2007) >>> Poll.objects.get(id=2) @@ -580,9 +580,9 @@ Let's jump back into the Python interactive shell by running # The API automatically follows relationships as far as you need. # Use double underscores to separate relationships. - # This works as many levels deep as you want. There's no limit. - # Find all Choices for any poll whose pub_date is in 2005. - >>> Choice.objects.filter(poll__pub_date__year=2005) + # This works as many levels deep as you want; there's no limit. + # Find all Choices for any poll whose pub_date is in 2007. + >>> Choice.objects.filter(poll__pub_date__year=2007) [, , ] # Let's delete one of the choices. Use delete() for that. diff --git a/docs/tutorial02.txt b/docs/tutorial02.txt index b820701d11..d96c38f2bd 100644 --- a/docs/tutorial02.txt +++ b/docs/tutorial02.txt @@ -362,8 +362,8 @@ think they should. Customize the admin look and feel ================================= -Clearly, having "Django administration" and "example.com" at the top of each -admin page is ridiculous. It's just placeholder text. +Clearly, having "Django administration" at the top of each admin page is +ridiculous. It's just placeholder text. That's easy to change, though, using Django's template system. The Django admin is powered by Django itself, and its interfaces use Django's own template @@ -389,7 +389,7 @@ as above, then copy ``django/contrib/admin/templates/admin/base_site.html`` to ``admin`` subdirectory. Then, just edit the file and replace the generic Django text with your own -site's name and URL as you see fit. +site's name as you see fit. Note that any of Django's default admin templates can be overridden. To override a template, just do the same thing you did with ``base_site.html`` --