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
This commit is contained in:
parent
404bf3b188
commit
f1edb8c2b3
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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::
|
||||
|
||||
|
|
|
@ -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')
|
||||
[<Poll: What's up?>]
|
||||
|
||||
# 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: What's up?>
|
||||
|
||||
>>> 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)
|
||||
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
|
||||
|
||||
# Let's delete one of the choices. Use delete() for that.
|
||||
|
|
|
@ -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`` --
|
||||
|
|
Loading…
Reference in New Issue