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
|
./runtests.py --settings=path.to.django.settings
|
||||||
|
|
||||||
Yes, the unit tests need a settings module, but only for database connection
|
Yes, the unit tests need a settings module, but only for database connection
|
||||||
info -- the ``DATABASE_NAME`` (required, but will be ignored),
|
info, with the ``DATABASE_ENGINE`` setting. You will also need a ``ROOT_URLCONF``
|
||||||
``DATABASE_ENGINE``, ``DATABASE_USER`` and ``DATABASE_PASSWORD`` settings. You
|
setting (its value is ignored; it just needs to be present) and a ``SITE_ID``
|
||||||
will also need a ``ROOT_URLCONF`` setting (its value is ignored; it just needs
|
setting (any non-zero integer value will do) in order for all the tests to pass.
|
||||||
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
|
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
|
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
|
Internally, all block and inline translations use the appropriate
|
||||||
``ugettext`` / ``ungettext`` call.
|
``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
|
* ``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).
|
language code and the second is the language name (in that language).
|
||||||
|
|
|
@ -737,7 +737,7 @@ Many-to-one relationships
|
||||||
To define a many-to-one relationship, use ``ForeignKey``. You use it just like
|
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.
|
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.
|
related.
|
||||||
|
|
||||||
For example, if a ``Car`` model has a ``Manufacturer`` -- that is, a
|
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
|
like any other ``Field`` type: by including it as a class attribute of your
|
||||||
model.
|
model.
|
||||||
|
|
||||||
``ManyToManyField`` requires a positional argument: The class to which the
|
``ManyToManyField`` requires a positional argument: the class to which the
|
||||||
model is related.
|
model is related.
|
||||||
|
|
||||||
For example, if a ``Pizza`` has multiple ``Topping`` objects -- that is, a
|
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"
|
This is most useful on the primary key of an object when that object "extends"
|
||||||
another object in some way.
|
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.
|
model is related.
|
||||||
|
|
||||||
For example, if you're building a database of "places", you would build pretty
|
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``:
|
A few special cases to note about ``list_display``:
|
||||||
|
|
||||||
* If the field is a ``ForeignKey``, Django will display the ``__str__()``
|
* If the field is a ``ForeignKey``, Django will display the
|
||||||
of the related object.
|
``__unicode__()`` of the related object.
|
||||||
|
|
||||||
* ``ManyToManyField`` fields aren't supported, because that would entail
|
* ``ManyToManyField`` fields aren't supported, because that would entail
|
||||||
executing a separate SQL statement for each row in the table. If you
|
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')
|
AND (first_name ILIKE 'lennon' OR last_name ILIKE 'lennon')
|
||||||
|
|
||||||
Note that the query input is split by spaces, so, following this example,
|
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).
|
``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
|
use ``get_absolute_url()`` as a convenience to reward people who've defined the
|
||||||
method.
|
method.
|
||||||
|
|
||||||
.. syndication feed framework: ../syndication_feeds/
|
.. _syndication feed framework: ../syndication_feeds/
|
||||||
|
|
||||||
It's good practice to use ``get_absolute_url()`` in templates, instead of
|
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::
|
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})
|
'day': self.created.day})
|
||||||
get_absolute_url = permalink(get_absolute_url)
|
get_absolute_url = permalink(get_absolute_url)
|
||||||
|
|
||||||
Notice that we specify an empty sequence for the second argument in this case,
|
Notice that we specify an empty sequence for the second parameter in this case,
|
||||||
because we only want to pass keyword arguments, not named arguments.
|
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
|
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
|
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
|
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
|
>>> from mysite.models import Reporter, Article
|
||||||
|
|
||||||
|
@ -124,7 +124,7 @@ is created on the fly: No code generation necessary::
|
||||||
# Delete an object with delete().
|
# Delete an object with delete().
|
||||||
>>> r.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,
|
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
|
``{% 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
|
'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
|
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::
|
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
|
>>> p.question
|
||||||
"What's up?"
|
"What's up?"
|
||||||
>>> p.pub_date
|
>>> 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().
|
# 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()
|
>>> p.save()
|
||||||
|
|
||||||
# objects.all() displays all the polls in the database.
|
# 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.objects.filter(question__startswith='What')
|
||||||
[<Poll: What's up?>]
|
[<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.
|
# 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: What's up?>
|
||||||
|
|
||||||
>>> Poll.objects.get(id=2)
|
>>> 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.
|
# The API automatically follows relationships as far as you need.
|
||||||
# Use double underscores to separate relationships.
|
# Use double underscores to separate relationships.
|
||||||
# This works as many levels deep as you want. There's no limit.
|
# 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.
|
# Find all Choices for any poll whose pub_date is in 2007.
|
||||||
>>> Choice.objects.filter(poll__pub_date__year=2005)
|
>>> Choice.objects.filter(poll__pub_date__year=2007)
|
||||||
[<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.
|
||||||
|
|
|
@ -362,8 +362,8 @@ think they should.
|
||||||
Customize the admin look and feel
|
Customize the admin look and feel
|
||||||
=================================
|
=================================
|
||||||
|
|
||||||
Clearly, having "Django administration" and "example.com" at the top of each
|
Clearly, having "Django administration" at the top of each admin page is
|
||||||
admin page is ridiculous. It's just placeholder text.
|
ridiculous. It's just placeholder text.
|
||||||
|
|
||||||
That's easy to change, though, using Django's template system. The Django admin
|
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
|
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.
|
``admin`` subdirectory.
|
||||||
|
|
||||||
Then, just edit the file and replace the generic Django text with your own
|
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
|
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`` --
|
override a template, just do the same thing you did with ``base_site.html`` --
|
||||||
|
|
Loading…
Reference in New Issue