Browse files

Fixed a bunch of reST markup errors.

The old book site had a custom reST builder that would ignore extra
leading intendation when the element only contained a list or a table.
But in vanilla reST, that markup results in <blockquote><ul>... etc.
Rather than port over the hacked-up builder, I just fixed the markup.
  • Loading branch information...
1 parent 49957a9 commit fdc4800cfd53ea09d4df5709d4a3ff3e309ae8d2 @jacobian jacobian committed Sep 25, 2012
Showing with 3,255 additions and 3,280 deletions.
  1. +62 −82 appendixA.rst
  2. +127 −127 appendixB.rst
  3. +308 −308 appendixC.rst
  4. +28 −28 appendixD.rst
  5. +22 −22 appendixE.rst
  6. +30 −30 appendixF.rst
  7. +98 −98 appendixG.rst
  8. +48 −50 chapter01.rst
  9. +52 −54 chapter02.rst
  10. +235 −237 chapter03.rst
  11. +365 −366 chapter04.rst
  12. +197 −197 chapter05.rst
  13. +67 −67 chapter06.rst
  14. +115 −115 chapter07.rst
  15. +72 −72 chapter08.rst
  16. +221 −219 chapter09.rst
  17. +60 −60 chapter10.rst
  18. +24 −24 chapter11.rst
  19. +57 −57 chapter12.rst
  20. +238 −238 chapter13.rst
  21. +220 −220 chapter14.rst
  22. +63 −63 chapter15.rst
  23. +149 −149 chapter16.rst
  24. +75 −75 chapter17.rst
  25. +86 −86 chapter18.rst
  26. +174 −174 chapter19.rst
  27. +62 −62 chapter20.rst
View
144 appendixA.rst
@@ -22,17 +22,17 @@ is the list of database fields it defines.
Django places only two restrictions on model field names:
- 1. A field name cannot be a Python reserved word, because that would result
- in a Python syntax error. For example::
+ 1. A field name cannot be a Python reserved word, because that would result
+ in a Python syntax error. For example::
- class Example(models.Model):
- pass = models.IntegerField() # 'pass' is a reserved word!
+ class Example(models.Model):
+ pass = models.IntegerField() # 'pass' is a reserved word!
- 2. A field name cannot contain more than one underscore in a row, due to
- the way Django's query lookup syntax works. For example::
+ 2. A field name cannot contain more than one underscore in a row, due to
+ the way Django's query lookup syntax works. For example::
- class Example(models.Model):
- foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
+ class Example(models.Model):
+ foo__bar = models.IntegerField() # 'foo__bar' has two underscores!
These limitations can be worked around, though, because your field name
doesn't necessarily have to match your database column name. See
@@ -46,14 +46,14 @@ is the list of database fields it defines.
Each field in your model should be an instance of the appropriate ``Field``
class. Django uses the field class types to determine a few things:
- * The database column type (e.g., ``INTEGER``, ``VARCHAR``).
-
- * The widget to use in Django's forms and admin site, if you care to use it
- (e.g., ``<input type="text">``, ``<select>``).
+* The database column type (e.g., ``INTEGER``, ``VARCHAR``).
+
+* The widget to use in Django's forms and admin site, if you care to use it
+ (e.g., ``<input type="text">``, ``<select>``).
+
+* The minimal validation requirements, which are used in Django's admin
+ interface and by forms.
- * The minimal validation requirements, which are used in Django's admin
- interface and by forms.
-
A complete list of field classes follows, sorted alphabetically. Note that
relationship fields (``ForeignKey``, etc.) are handled in the next section.
@@ -116,11 +116,9 @@ A fixed-precision decimal number, represented in Python by a
``decimal.Decimal`` instance. Has two **required** arguments:
``max_digits``
-
The maximum number of digits allowed in the number
``decimal_places``
-
The number of decimal places to store with the number
For example, to store numbers up to 999 with a resolution of 2 decimal places,
@@ -153,7 +151,6 @@ A file-upload field.
Has one **required** argument:
``upload_to``
-
A local filesystem path that will be appended to your ``MEDIA_ROOT``
setting to determine the value of the ``django.core.files.File.url``
attribute.
@@ -169,50 +166,49 @@ Has one **required** argument:
to be passed along to the storage system. The two arguments that will be
passed are:
- ====================== ===============================================
- Argument Description
- ====================== ===============================================
- ``instance`` An instance of the model where the
- ``FileField`` is defined. More specifically,
- this is the particular instance where the
- current file is being attached.
+ ====================== ===============================================
+ Argument Description
+ ====================== ===============================================
+ ``instance`` An instance of the model where the
+ ``FileField`` is defined. More specifically,
+ this is the particular instance where the
+ current file is being attached.
- In most cases, this object will not have been
- saved to the database yet, so if it uses the
- default ``AutoField``, *it might not yet have a
- value for its primary key field*.
+ In most cases, this object will not have been
+ saved to the database yet, so if it uses the
+ default ``AutoField``, *it might not yet have a
+ value for its primary key field*.
- ``filename`` The filename that was originally given to the
- file. This may or may not be taken into account
- when determining the final destination path.
- ====================== ===============================================
+ ``filename`` The filename that was originally given to the
+ file. This may or may not be taken into account
+ when determining the final destination path.
+ ====================== ===============================================
Also has one optional argument:
``storage``
-
Optional. A storage object, which handles the storage and retrieval of your
files.
Using a ``FileField`` or an ``ImageField`` (see below) in a model
takes a few steps:
- 1. In your settings file, you'll need to define ``MEDIA_ROOT`` as the
- full path to a directory where you'd like Django to store uploaded files.
- (For performance, these files are not stored in the database.) Define
- ``MEDIA_URL`` as the base public URL of that directory. Make sure
- that this directory is writable by the Web server's user account.
+1. In your settings file, you'll need to define ``MEDIA_ROOT`` as the
+ full path to a directory where you'd like Django to store uploaded files.
+ (For performance, these files are not stored in the database.) Define
+ ``MEDIA_URL`` as the base public URL of that directory. Make sure
+ that this directory is writable by the Web server's user account.
- 2. Add the ``FileField`` or ``ImageField`` to your model, making
- sure to define the ``upload_to`` option to tell Django
- to which subdirectory of ``MEDIA_ROOT`` it should upload files.
+2. Add the ``FileField`` or ``ImageField`` to your model, making
+ sure to define the ``upload_to`` option to tell Django
+ to which subdirectory of ``MEDIA_ROOT`` it should upload files.
- 3. All that will be stored in your database is a path to the file
- (relative to ``MEDIA_ROOT``). You'll most likely want to use the
- convenience ``url`` function provided by
- Django. For example, if your ``ImageField`` is called ``mug_shot``,
- you can get the absolute URL to your image in a template with
- ``{{ object.mug_shot.url }}``.
+3. All that will be stored in your database is a path to the file
+ (relative to ``MEDIA_ROOT``). You'll most likely want to use the
+ convenience ``url`` function provided by
+ Django. For example, if your ``ImageField`` is called ``mug_shot``,
+ you can get the absolute URL to your image in a template with
+ ``{{ object.mug_shot.url }}``.
For example, say your ``MEDIA_ROOT`` is set to ``'/home/media'``, and
``upload_to`` is set to ``'photos/%Y/%m/%d'``. The ``'%Y/%m/%d'``
@@ -245,19 +241,16 @@ directory on the filesystem. Has three special arguments, of which the first is
**required**:
``path``
-
Required. The absolute filesystem path to a directory from which this
``FilePathField`` should get its choices. Example: ``"/home/images"``.
``match``
-
Optional. A regular expression, as a string, that ``FilePathField``
will use to filter filenames. Note that the regex will be applied to the
base filename, not the full path. Example: ``"foo.*\.txt$"``, which will
match a file called ``foo23.txt`` but not ``bar.txt`` or ``foo23.gif``.
``recursive``
-
Optional. Either ``True`` or ``False``. Default is ``False``. Specifies
whether all subdirectories of ``path`` should be included.
@@ -288,12 +281,10 @@ Like ``FileField``, but validates that the uploaded object is a valid
image. Has two extra optional arguments:
``height_field``
-
Name of a model field which will be auto-populated with the height of the
image each time the model instance is saved.
``width_field``
-
Name of a model field which will be auto-populated with the width of the
image each time the model instance is saved.
@@ -371,7 +362,6 @@ URLField
A ``CharField`` for a URL. Has one extra optional argument:
``verify_exists``
-
If ``True`` (the default), the URL given will be checked for existence
(i.e., the URL actually loads and doesn't give a 404 response). It should
be noted that when using the single-threaded development server, validating
@@ -389,7 +379,6 @@ A ``TextField`` that checks that the value is valid XML that matches a
given schema. Takes one required argument:
``schema_path``
-
The filesystem path to a RelaxNG schema against which to validate the
field. For more on RelaxNG, see http://www.relaxng.org/.
@@ -403,7 +392,7 @@ null
If ``True``, Django will store empty values as ``NULL`` in the database. If
``False``, saving empty values will likely result in a database error. Default
-is ``False``.
+is ``False``.
Note that empty string values will always get stored as empty strings, not as
``NULL``. Only use ``null=True`` for non-string fields such as integers,
@@ -661,7 +650,6 @@ deal with the field names of your model object.
define the details of how the relation works.
``limit_choices_to``
-
A dictionary of lookup arguments and values
that limit the available admin choices for this object. Use this with
functions from the Python ``datetime`` module to limit choices of objects by
@@ -674,13 +662,11 @@ define the details of how the relation works.
``limit_choices_to`` has no effect on the inline FormSets that are created
to display related objects in the admin.
-
-``related_name``
+``related_name``
The name to use for the relation from the related object back to this one.
``to_field``
-
The field on the related object that the relation is to. By default, Django
uses the primary key of the related object.
@@ -705,19 +691,16 @@ You can manually provide the name of the join table using the
that control how the relationship functions.
``related_name``
-
Same as ``related_name`` in ``ForeignKey``.
``limit_choices_to``
-
Same as ``limit_choices_to`` in ``ForeignKey``.
``limit_choices_to`` has no effect when used on a ``ManyToManyField`` with a
custom intermediate table specified using the
``through`` paramter.
``symmetrical``
-
Only used in the definition of ManyToManyFields on self. Consider the
following model::
@@ -736,7 +719,6 @@ that control how the relationship functions.
``ManyToManyField`` relationships to be non-symmetrical.
``through``
-
Django will automatically generate a table to manage many-to-many
relationships. However, if you want to manually specify the intermediary
table, you can use the ``through`` option to specify
@@ -747,7 +729,6 @@ that control how the relationship functions.
extra data with a many-to-many relationship.
``db_table``
-
The name of the table to create for storing the many-to-many data. If this
is not provided, Django will assume a default name based upon the names of
the two tables being joined.
@@ -773,7 +754,6 @@ Additionally, ``OneToOneField`` accepts all of the extra arguments
accepted by ``ForeignKey``, plus one extra argument:
``parent_link``
-
When ``True`` and used in a model which inherits from another
(concrete) model, indicates that this field should be used as the
link back to the parent class, rather than the extra
@@ -795,7 +775,7 @@ model class::
Model metadata is "anything that's not a field," such as ordering options and so forth.
-The sections that follow present a list of all possible ``Meta`` options.
+The sections that follow present a list of all possible ``Meta`` options.
No options are required. Adding ``class Meta`` to a model is completely optional.
abstract
@@ -861,21 +841,21 @@ table or a database view that has been created by some other means. This is
the *only* difference when ``managed`` is ``False``. All other aspects of
model handling are exactly the same as normal. This includes
- 1. Adding an automatic primary key field to the model if you don't declare
- it. To avoid confusion for later code readers, it's recommended to
- specify all the columns from the database table you are modeling when
- using unmanaged models.
-
- 2. If a model with ``managed=False`` contains a
- ``ManyToManyField`` that points to another
- unmanaged model, then the intermediary table for the many-to-many join
- will also not be created. However, the intermediary table between one
- managed and one unmanaged model *will* be created.
-
- If you need to change this default behavior, create the intermediary
- table as an explicit model (with ``managed`` set as needed) and use the
- ``through`` attribute to make the relation use your
- custom model.
+1. Adding an automatic primary key field to the model if you don't declare
+ it. To avoid confusion for later code readers, it's recommended to
+ specify all the columns from the database table you are modeling when
+ using unmanaged models.
+
+2. If a model with ``managed=False`` contains a
+ ``ManyToManyField`` that points to another
+ unmanaged model, then the intermediary table for the many-to-many join
+ will also not be created. However, the intermediary table between one
+ managed and one unmanaged model *will* be created.
+
+ If you need to change this default behavior, create the intermediary
+ table as an explicit model (with ``managed`` set as needed) and use the
+ ``through`` attribute to make the relation use your
+ custom model.
For tests involving models with ``managed=False``, it's up to you to ensure
the correct tables are created as part of the test setup.
View
254 appendixB.rst
@@ -64,37 +64,37 @@ What Happens When You Save?
When you save an object, Django performs the following steps:
- #. **Emit a pre_save signal.** This provides a notification that
- an object is about to be saved. You can register a listener that
- will be invoked whenever this signal is emitted. Check the online
- documentation for more on signals.
-
- #. **Preprocess the data.** Each field on the object is asked to
- perform any automated data modification that the field may need
- to perform.
-
- Most fields do *no* preprocessing -- the field data is kept as is.
- Preprocessing is only used on fields that have special behavior,
- like file fields.
-
- #. **Prepare the data for the database.** Each field is asked to provide
- its current value in a data type that can be written to the database.
-
- Most fields require no data preparation. Simple data types, such as
- integers and strings, are "ready to write" as a Python object. However,
- more complex data types often require some modification. For example,
- ``DateFields`` use a Python ``datetime`` object to store data.
- Databases don't store ``datetime`` objects, so the field value
- must be converted into an ISO-compliant date string for insertion
- into the database.
-
- #. **Insert the data into the database.** The preprocessed, prepared
- data is then composed into an SQL statement for insertion into the
- database.
-
- #. **Emit a post_save signal.** As with the ``pre_save`` signal, this
- is used to provide notification that an object has been successfully
- saved.
+#. **Emit a pre_save signal.** This provides a notification that
+ an object is about to be saved. You can register a listener that
+ will be invoked whenever this signal is emitted. Check the online
+ documentation for more on signals.
+
+#. **Preprocess the data.** Each field on the object is asked to
+ perform any automated data modification that the field may need
+ to perform.
+
+ Most fields do *no* preprocessing -- the field data is kept as is.
+ Preprocessing is only used on fields that have special behavior,
+ like file fields.
+
+#. **Prepare the data for the database.** Each field is asked to provide
+ its current value in a data type that can be written to the database.
+
+ Most fields require no data preparation. Simple data types, such as
+ integers and strings, are "ready to write" as a Python object. However,
+ more complex data types often require some modification. For example,
+ ``DateFields`` use a Python ``datetime`` object to store data.
+ Databases don't store ``datetime`` objects, so the field value
+ must be converted into an ISO-compliant date string for insertion
+ into the database.
+
+#. **Insert the data into the database.** The preprocessed, prepared
+ data is then composed into an SQL statement for insertion into the
+ database.
+
+#. **Emit a post_save signal.** As with the ``pre_save`` signal, this
+ is used to provide notification that an object has been successfully
+ saved.
Autoincrementing Primary Keys
------------------------------
@@ -106,11 +106,11 @@ the section titled "AutoField" in Appendix A).
If your model has an ``AutoField``, that autoincremented value will be
calculated and saved as an attribute on your object the first time you call
``save()``::
-
+
>>> b2 = Blog(name='Cheddar Talk', tagline='Thoughts on cheese.')
>>> b2.id # Returns None, because b doesn't have an ID yet.
None
-
+
>>> b2.save()
>>> b2.id # Returns the ID of your new object.
14
@@ -164,16 +164,16 @@ doesn't hit the database until you explicitly call ``save()``.
``INSERT`` or ``UPDATE`` SQL statements. Specifically, when you call
``save()``, Django follows this algorithm:
- * If the object's primary key attribute is set to a value that evaluates
- to ``True`` (i.e., a value other than ``None`` or the empty string),
- Django executes a ``SELECT`` query to determine whether a record with
- the given primary key already exists.
+ * If the object's primary key attribute is set to a value that evaluates
+ to ``True`` (i.e., a value other than ``None`` or the empty string),
+ Django executes a ``SELECT`` query to determine whether a record with
+ the given primary key already exists.
- * If the record with the given primary key does already exist, Django
- executes an ``UPDATE`` query.
+ * If the record with the given primary key does already exist, Django
+ executes an ``UPDATE`` query.
- * If the object's primary key attribute is *not* set, or if it's set but
- a record doesn't exist, Django executes an ``INSERT``.
+ * If the object's primary key attribute is *not* set, or if it's set but
+ a record doesn't exist, Django executes an ``INSERT``.
Because of this, you should be careful not to specify a primary key value
explicitly when saving new objects if you cannot guarantee the primary key
@@ -305,37 +305,37 @@ long and Django won't actually run the query until the ``QuerySet`` is
You can evaluate a ``QuerySet`` in any following ways:
- * *Iterating*: A ``QuerySet`` is iterable, and it executes its database query the first
- time you iterate over it. For example, the following ``QuerySet`` isn't evaluated
- until it's iterated over in the ``for`` loop::
-
- qs = Entry.objects.filter(pub_date__year=2006)
- qs = qs.filter(headline__icontains="bill")
- for e in qs:
- print e.headline
+* *Iterating*: A ``QuerySet`` is iterable, and it executes its database query the first
+ time you iterate over it. For example, the following ``QuerySet`` isn't evaluated
+ until it's iterated over in the ``for`` loop::
- This prints all headlines from 2006 that contain "bill" but causes
- only one database hit.
+ qs = Entry.objects.filter(pub_date__year=2006)
+ qs = qs.filter(headline__icontains="bill")
+ for e in qs:
+ print e.headline
- * *Printing it*: A ``QuerySet`` is evaluated when you call ``repr()`` on it.
- This is for convenience in the Python interactive interpreter, so you can
- immediately see your results when using the API interactively.
+ This prints all headlines from 2006 that contain "bill" but causes
+ only one database hit.
- * *Slicing*: As explained in the upcoming "Limiting QuerySets" section,
- a ``QuerySet`` can be sliced using Python's array-slicing syntax.
- Usually slicing a ``QuerySet`` returns another (unevaluated)``QuerySet``,
- but Django will execute the database query if you use the "step"
- parameter of slice syntax.
+* *Printing it*: A ``QuerySet`` is evaluated when you call ``repr()`` on it.
+ This is for convenience in the Python interactive interpreter, so you can
+ immediately see your results when using the API interactively.
- * *Converting to a list*: You can force evaluation of a ``QuerySet`` by calling
- ``list()`` on it, for example::
+* *Slicing*: As explained in the upcoming "Limiting QuerySets" section,
+ a ``QuerySet`` can be sliced using Python's array-slicing syntax.
+ Usually slicing a ``QuerySet`` returns another (unevaluated)``QuerySet``,
+ but Django will execute the database query if you use the "step"
+ parameter of slice syntax.
- >>> entry_list = list(Entry.objects.all())
+* *Converting to a list*: You can force evaluation of a ``QuerySet`` by calling
+ ``list()`` on it, for example::
- Be warned, though, that this could have a large memory overhead, because
- Django will load each element of the list into memory. In contrast,
- iterating over a ``QuerySet`` will take advantage of your database to load
- data and instantiate objects only as you need them.
+ >>> entry_list = list(Entry.objects.all())
+
+ Be warned, though, that this could have a large memory overhead, because
+ Django will load each element of the list into memory. In contrast,
+ iterating over a ``QuerySet`` will take advantage of your database to load
+ data and instantiate objects only as you need them.
.. admonition:: Filtered QuerySets Are Unique
@@ -490,11 +490,11 @@ of your model. The ``kind`` argument must be either ``"year"``, ``"month"``, or
``"day"``. Each ``datetime.datetime`` object in the result list is "truncated"
to the given ``type``:
- * ``"year"`` returns a list of all distinct year values for the field.
-
- * ``"month"`` returns a list of all distinct year/month values for the field.
-
- * ``"day"`` returns a list of all distinct year/month/day values for the field.
+* ``"year"`` returns a list of all distinct year values for the field.
+
+* ``"month"`` returns a list of all distinct year/month values for the field.
+
+* ``"day"`` returns a list of all distinct year/month/day values for the field.
``order``, which defaults to ``'ASC'``, should be either ``'ASC'`` or
``'DESC'``. This specifies how to order the results.
@@ -503,16 +503,16 @@ Here are a few examples::
>>> Entry.objects.dates('pub_date', 'year')
[datetime.datetime(2005, 1, 1)]
-
+
>>> Entry.objects.dates('pub_date', 'month')
[datetime.datetime(2005, 2, 1), datetime.datetime(2005, 3, 1)]
-
+
>>> Entry.objects.dates('pub_date', 'day')
[datetime.datetime(2005, 2, 20), datetime.datetime(2005, 3, 20)]
-
+
>>> Entry.objects.dates('pub_date', 'day', order='DESC')
[datetime.datetime(2005, 3, 20), datetime.datetime(2005, 2, 20)]
-
+
>>> Entry.objects.filter(headline__contains='Lennon').dates('pub_date', 'day')
[datetime.datetime(2005, 3, 20)]
@@ -609,13 +609,13 @@ The ``DoesNotExist`` exception inherits from
create(\*\*kwargs)
~~~~~~~~~~~~~~~~~~
-This is a convenience method for creating an object and saving it all in one step.
+This is a convenience method for creating an object and saving it all in one step.
It lets you compress two common steps::
>>> p = Person(first_name="Bruce", last_name="Springsteen")
>>> p.save()
-into a single line::
+into a single line::
>>> p = Person.objects.create(first_name="Bruce", last_name="Springsteen")
@@ -640,7 +640,7 @@ This pattern gets quite unwieldy as the number of fields in a model increases. T
previous example can be rewritten using ``get_or_create()`` like so::
obj, created = Person.objects.get_or_create(
- first_name = 'John',
+ first_name = 'John',
last_name = 'Lennon',
defaults = {'birthday': date(1940, 10, 9)}
)
@@ -667,12 +667,12 @@ If you have a field named ``defaults`` and want to use it as an exact lookup in
``get_or_create()``, just use ``'defaults__exact'`` like so::
Foo.objects.get_or_create(
- defaults__exact = 'bar',
+ defaults__exact = 'bar',
defaults={'defaults': 'bar'}
)
.. note::
-
+
As mentioned earlier, ``get_or_create()`` is mostly useful in scripts that
need to parse data and create new records if existing ones aren't available.
But if you need to use ``get_or_create()`` in a view, please make sure to
@@ -684,7 +684,7 @@ count()
~~~~~~~
Returns an integer representing the number of objects in the database matching
-the ``QuerySet``. ``count()`` never raises exceptions. Here's an example::
+the ``QuerySet``. ``count()`` never raises exceptions. Here's an example::
# Returns the total number of entries in the database.
>>> Entry.objects.count()
@@ -723,7 +723,7 @@ latest(field_name=None)
~~~~~~~~~~~~~~~~~~~~~~~
Returns the latest object in the table, by date, using the ``field_name``
-provided as the date field. This example returns the latest ``Entry`` in the
+provided as the date field. This example returns the latest ``Entry`` in the
table, according to the ``pub_date`` field::
>>> Entry.objects.latest('pub_date')
@@ -762,7 +762,7 @@ exact
Performs an exact match::
>>> Entry.objects.get(headline__exact="Man bites dog")
-
+
This matches any object with the exact headline "Man bites dog".
If you don't provide a lookup type -- that is, if your keyword argument doesn't
@@ -778,7 +778,7 @@ This is for convenience, because ``exact`` lookups are the common case.
iexact
------
-Performs a case-insensitive exact match::
+Performs a case-insensitive exact match::
>>> Blog.objects.get(name__iexact='beatles blog')
@@ -833,7 +833,7 @@ Unlike ``contains``, ``icontains`` *will* match ``'today lennon honored'``.
gt, gte, lt, and lte
--------------------
-These represent greater than, greater than or equal to, less than, and less
+These represent greater than, greater than or equal to, less than, and less
than or equal to::
>>> Entry.objects.filter(id__gt=4)
@@ -872,7 +872,7 @@ istartswith
Performs a case-insensitive starts-with::
>>> Entry.objects.filter(headline__istartswith='will')
-
+
This will return the headlines "Will he run?", "Willbur named judge", and
"will found in crypt", but not "Who is Will?"
@@ -950,7 +950,7 @@ combined with ``pk`` to perform a query on the primary key of a model::
# Get blogs entries with id 1, 4, and 7
>>> Blog.objects.filter(pk__in=[1,4,7])
-
+
# Get all blog entries with id > 14
>>> Blog.objects.filter(pk__gt=14)
@@ -980,7 +980,7 @@ For example, this ``Q`` object encapsulates a single ``LIKE`` query::
Q(question__startswith='What')
``Q`` objects can be combined using the ``&`` and ``|`` operators. When an
-operator is used on two ``Q`` objects, it yields a new ``Q`` object. For example,
+operator is used on two ``Q`` objects, it yields a new ``Q`` object. For example,
this statement yields a single ``Q`` object that represents the
OR of two ``"question__startswith"`` queries::
@@ -1158,56 +1158,56 @@ be accessed from an instance::
In addition to the ``QuerySet`` methods defined in the "Retrieving Objects" section,
the ``ForeignKey`` ``Manager`` has these additional methods:
- * ``add(obj1, obj2, ...)``: Adds the specified model objects to the related
- object set, for example::
+* ``add(obj1, obj2, ...)``: Adds the specified model objects to the related
+ object set, for example::
- b = Blog.objects.get(id=1)
- e = Entry.objects.get(id=234)
- b.entry_set.add(e) # Associates Entry e with Blog b.
+ b = Blog.objects.get(id=1)
+ e = Entry.objects.get(id=234)
+ b.entry_set.add(e) # Associates Entry e with Blog b.
- * ``create(**kwargs)``: Creates a new object, saves it, and puts it in the
- related object set. It returns the newly created object::
+* ``create(**kwargs)``: Creates a new object, saves it, and puts it in the
+ related object set. It returns the newly created object::
- b = Blog.objects.get(id=1)
- e = b.entry_set.create(headline='Hello', body_text='Hi', pub_date=datetime.date(2005, 1, 1))
- # No need to call e.save() at this point -- it's already been saved.
+ b = Blog.objects.get(id=1)
+ e = b.entry_set.create(headline='Hello', body_text='Hi', pub_date=datetime.date(2005, 1, 1))
+ # No need to call e.save() at this point -- it's already been saved.
- This is equivalent to (but much simpler than) the following::
+ This is equivalent to (but much simpler than) the following::
- b = Blog.objects.get(id=1)
- e = Entry(blog=b, headline='Hello', body_text='Hi', pub_date=datetime.date(2005, 1, 1))
- e.save()
+ b = Blog.objects.get(id=1)
+ e = Entry(blog=b, headline='Hello', body_text='Hi', pub_date=datetime.date(2005, 1, 1))
+ e.save()
- Note that there's no need to specify the keyword argument of the model
- that defines the relationship. In the preceding example, we don't pass the
- parameter ``blog`` to ``create()``. Django figures out that the new
- ``Entry`` object's ``blog`` field should be set to ``b``.
+ Note that there's no need to specify the keyword argument of the model
+ that defines the relationship. In the preceding example, we don't pass the
+ parameter ``blog`` to ``create()``. Django figures out that the new
+ ``Entry`` object's ``blog`` field should be set to ``b``.
- * ``remove(obj1, obj2, ...)``: Removes the specified model objects from the
- related object set::
+* ``remove(obj1, obj2, ...)``: Removes the specified model objects from the
+ related object set::
- b = Blog.objects.get(id=1)
- e = Entry.objects.get(id=234)
- b.entry_set.remove(e) # Disassociates Entry e from Blog b.
+ b = Blog.objects.get(id=1)
+ e = Entry.objects.get(id=234)
+ b.entry_set.remove(e) # Disassociates Entry e from Blog b.
- In order to prevent database inconsistency, this method only exists on
- ``ForeignKey`` objects where ``null=True``. If the related field can't be
- set to ``None`` (``NULL``), then an object can't be removed from a
- relation without being added to another. In the preceding example, removing
- ``e`` from ``b.entry_set()`` is equivalent to doing ``e.blog = None``,
- and because the ``blog`` ``ForeignKey`` doesn't have ``null=True``, this
- is invalid.
+ In order to prevent database inconsistency, this method only exists on
+ ``ForeignKey`` objects where ``null=True``. If the related field can't be
+ set to ``None`` (``NULL``), then an object can't be removed from a
+ relation without being added to another. In the preceding example, removing
+ ``e`` from ``b.entry_set()`` is equivalent to doing ``e.blog = None``,
+ and because the ``blog`` ``ForeignKey`` doesn't have ``null=True``, this
+ is invalid.
- * ``clear()``: Removes all objects from the related object set::
+* ``clear()``: Removes all objects from the related object set::
- b = Blog.objects.get(id=1)
- b.entry_set.clear()
+ b = Blog.objects.get(id=1)
+ b.entry_set.clear()
- Note this doesn't delete the related objects -- it just disassociates
- them.
+ Note this doesn't delete the related objects -- it just disassociates
+ them.
- Just like ``remove()``, ``clear()`` is only available on ``ForeignKey``s
- where ``null=True``.
+ Just like ``remove()``, ``clear()`` is only available on ``ForeignKey``s
+ where ``null=True``.
To assign the members of a related set in one fell swoop, just assign to it
from any iterable object, for example::
@@ -1260,7 +1260,7 @@ preceding example, if the ``ManyToManyField`` in ``Entry`` had specified
relationship on only one end. But how is this possible, given that a model
class doesn't know which other model classes are related to it until those
other model classes are loaded?
-
+
The answer lies in the ``INSTALLED_APPS`` setting. The first time any model
is loaded, Django iterates over every model in ``INSTALLED_APPS`` and
creates the backward relationships in memory as needed. Essentially, one of
@@ -1291,7 +1291,7 @@ deletes the object and has no return value::
e.delete()
You can also delete objects in bulk. Every ``QuerySet`` has a ``delete()``
-method, which deletes all members of that ``QuerySet``. For example, this
+method, which deletes all members of that ``QuerySet``. For example, this
deletes all ``Entry`` objects with a ``pub_date`` year of 2005::
Entry.objects.filter(pub_date__year=2005).delete()
View
616 appendixC.rst
@@ -8,7 +8,7 @@ take. Be sure to read Chapter 11 before trying to understand the reference
material that follows. You might want to refer back to the ``Book``,
``Publisher``, and ``Author`` objects defined in that chapter; the examples that
follow use these models.
-
+
Common Arguments to Generic Views
=================================
@@ -23,13 +23,13 @@ the table.
========================== ===============================================
Argument Description
========================== ===============================================
- ``allow_empty`` A Boolean specifying whether to display the
+ ``allow_empty`` A Boolean specifying whether to display the
page if no objects are available. If this is
``False`` and no objects are available, the view
will raise a 404 error instead of displaying an
empty page. By default, this is ``True``.
- ``context_processors`` A list of additional template-context processors
+ ``context_processors`` A list of additional template-context processors
(besides the defaults) to apply to the view's
template. See Chapter 9 for information on
template context processors.
@@ -40,12 +40,12 @@ the table.
callable, the generic view will call it just
before rendering the template.
- ``mimetype`` The MIME type to use for the resulting
+ ``mimetype`` The MIME type to use for the resulting
document. It defaults to the value of the
``DEFAULT_MIME_TYPE`` setting, which is
``text/html`` if you haven't changed it.
-
- ``queryset`` A ``QuerySet`` (i.e., something like
+
+ ``queryset`` A ``QuerySet`` (i.e., something like
``Author.objects.all()``) to read objects from.
See Appendix B for more information about
``QuerySet`` objects. Most generic views require
@@ -56,18 +56,18 @@ the table.
``django.template.loader``. See Chapter 9 for
information on template loaders.
- ``template_name`` The full name of a template to use in rendering
+ ``template_name`` The full name of a template to use in rendering
the page. This lets you override the default
template name derived from the ``QuerySet``.
- ``template_object_name`` The name of the template variable to
+ ``template_object_name`` The name of the template variable to
use in the template context. By default, this is
``'object'``. Views that list more than one
object (i.e., ``object_list`` views and various
objects-for-date views) will append ``'_list'``
to the value of this parameter.
========================== ===============================================
-
+
"Simple" Generic Views
======================
@@ -103,7 +103,7 @@ variable ``{{ params.id }}`` that is set to ``15``.
Required Arguments
``````````````````
- * ``template``: The full name of a template to use.
+* ``template``: The full name of a template to use.
Redirecting to Another URL
--------------------------
@@ -139,8 +139,8 @@ This example returns a "Gone" response for requests to ``/bar/``::
Required Arguments
``````````````````
- * ``url``: The URL to redirect to, as a string. Or ``None`` to return a 410
- ("Gone") HTTP response.
+* ``url``: The URL to redirect to, as a string. Or ``None`` to return a 410
+ ("Gone") HTTP response.
List/Detail Generic Views
=========================
@@ -172,34 +172,34 @@ to show a simple list of all authors given the following URLconf snippet::
}
urlpatterns = patterns('',
- (r'authors/$', list_detail.object_list, author_list_info)
+ (r'authors/$', list_detail.object_list, author_list_info)
)
Required Arguments
``````````````````
- * ``queryset``: A ``QuerySet`` of objects to list (see Table C-1).
+* ``queryset``: A ``QuerySet`` of objects to list (see Table C-1).
Optional Arguments
``````````````````
- * ``paginate_by``: An integer specifying how many objects should be
- displayed per page. If this is given, the view will paginate objects with
- ``paginate_by`` objects per page. The view will expect either a ``page``
- query string parameter (via ``GET``) containing a zero-indexed page
- number, or a ``page`` variable specified in the URLconf. See the following
- "Notes on Pagination" section.
+* ``paginate_by``: An integer specifying how many objects should be
+ displayed per page. If this is given, the view will paginate objects with
+ ``paginate_by`` objects per page. The view will expect either a ``page``
+ query string parameter (via ``GET``) containing a zero-indexed page
+ number, or a ``page`` variable specified in the URLconf. See the following
+ "Notes on Pagination" section.
Additionally, this view may take any of these common arguments described in
Table C-1:
- * ``allow_empty``
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
+* ``allow_empty``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
Template Name
`````````````
@@ -219,51 +219,51 @@ Template Context
In addition to ``extra_context``, the template's context will contain the following:
- * ``object_list``: The list of objects. This variable's name depends on the
- ``template_object_name`` parameter, which is ``'object'`` by default. If
- ``template_object_name`` is ``'foo'``, this variable's name will be
- ``foo_list``.
+* ``object_list``: The list of objects. This variable's name depends on the
+ ``template_object_name`` parameter, which is ``'object'`` by default. If
+ ``template_object_name`` is ``'foo'``, this variable's name will be
+ ``foo_list``.
- * ``is_paginated``: A Boolean representing whether the results are
- paginated. Specifically, this is set to ``False`` if the number of
- available objects is less than or equal to ``paginate_by``.
+* ``is_paginated``: A Boolean representing whether the results are
+ paginated. Specifically, this is set to ``False`` if the number of
+ available objects is less than or equal to ``paginate_by``.
If the results are paginated, the context will contain these extra variables:
- * ``results_per_page``: The number of objects per page. (This is the same as
- the ``paginate_by`` parameter.)
+* ``results_per_page``: The number of objects per page. (This is the same as
+ the ``paginate_by`` parameter.)
- * ``has_next``: A Boolean representing whether there's a next page.
+* ``has_next``: A Boolean representing whether there's a next page.
- * ``has_previous``: A Boolean representing whether there's a previous page.
+* ``has_previous``: A Boolean representing whether there's a previous page.
- * ``page``: The current page number, as an integer. This is 1-based.
+* ``page``: The current page number, as an integer. This is 1-based.
- * ``next``: The next page number, as an integer. If there's no next page,
- this will still be an integer representing the theoretical next-page
- number. This is 1-based.
+* ``next``: The next page number, as an integer. If there's no next page,
+ this will still be an integer representing the theoretical next-page
+ number. This is 1-based.
- * ``previous``: The previous page number, as an integer. This is 1-based.
+* ``previous``: The previous page number, as an integer. This is 1-based.
- * ``pages``: The total number of pages, as an integer.
+* ``pages``: The total number of pages, as an integer.
- * ``hits``: The total number of objects across *all* pages, not just this
- page.
+* ``hits``: The total number of objects across *all* pages, not just this
+ page.
.. admonition:: A Note on Pagination
If ``paginate_by`` is specified, Django will paginate the results. You can
specify the page number in the URL in one of two ways:
- * Use the ``page`` parameter in the URLconf. For example, this is what
- your URLconf might look like::
+ * Use the ``page`` parameter in the URLconf. For example, this is what
+ your URLconf might look like::
- (r'^objects/page(?P<page>[0-9]+)/$', 'object_list', dict(info_dict))
+ (r'^objects/page(?P<page>[0-9]+)/$', 'object_list', dict(info_dict))
- * Pass the page number via the ``page`` query-string parameter. For
- example, a URL would look like this::
+ * Pass the page number via the ``page`` query-string parameter. For
+ example, a URL would look like this::
- /objects/?page=3
+ /objects/?page=3
In both cases, ``page`` is 1-based, not 0-based, so the first page would be
represented as page ``1``.
@@ -303,44 +303,44 @@ given author by modifying the URLconf:
Required Arguments
``````````````````
- * ``queryset``: A ``QuerySet`` that will be searched for the object (see Table C-1).
+* ``queryset``: A ``QuerySet`` that will be searched for the object (see Table C-1).
and either
- * ``object_id``: The value of the primary-key field for the object.
+* ``object_id``: The value of the primary-key field for the object.
or
- * ``slug``: The slug of the given object. If you pass this field, then the
- ``slug_field`` argument (see the following section) is also required.
+* ``slug``: The slug of the given object. If you pass this field, then the
+ ``slug_field`` argument (see the following section) is also required.
Optional Arguments
``````````````````
- * ``slug_field``: The name of the field on the object containing the slug.
- This is required if you are using the ``slug`` argument, but it must be
- absent if you're using the ``object_id`` argument.
+* ``slug_field``: The name of the field on the object containing the slug.
+ This is required if you are using the ``slug`` argument, but it must be
+ absent if you're using the ``object_id`` argument.
+
+* ``template_name_field``: The name of a field on the object whose value is
+ the template name to use. This lets you store template names in your data.
- * ``template_name_field``: The name of a field on the object whose value is
- the template name to use. This lets you store template names in your data.
+ In other words, if your object has a field ``'the_template'`` that
+ contains a string ``'foo.html'``, and you set ``template_name_field`` to
+ ``'the_template'``, then the generic view for this object will use the
+ template ``'foo.html'``.
- In other words, if your object has a field ``'the_template'`` that
- contains a string ``'foo.html'``, and you set ``template_name_field`` to
- ``'the_template'``, then the generic view for this object will use the
- template ``'foo.html'``.
-
- If the template named by ``template_name_field`` doesn't exist, the one
- named by ``template_name`` is used instead. It's a bit of a
- brain-bender, but it's useful in some cases.
+ If the template named by ``template_name_field`` doesn't exist, the one
+ named by ``template_name`` is used instead. It's a bit of a
+ brain-bender, but it's useful in some cases.
This view may also take these common arguments (see Table C-1):
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
Template Name
`````````````
@@ -353,11 +353,11 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``object``: The object. This variable's name depends on the
- ``template_object_name`` parameter, which is ``'object'`` by default. If
- ``template_object_name`` is ``'foo'``, this variable's name will be
- ``foo``.
-
+* ``object``: The object. This variable's name depends on the
+ ``template_object_name`` parameter, which is ``'object'`` by default. If
+ ``template_object_name`` is ``'foo'``, this variable's name will be
+ ``foo``.
+
Date-Based Generic Views
========================
@@ -368,14 +368,14 @@ typical blog archive.
.. admonition:: Tip:
By default, these views ignore objects with dates in the future.
-
+
This means that if you try to visit an archive page in the future, Django
will automatically show a 404 ("Page not found") error, even if there are objects
published that day.
-
+
Thus, you can publish postdated objects that don't appear publicly until
their desired publication date.
-
+
However, for different types of date-based objects, this isn't appropriate
(e.g., a calendar of upcoming events). For these views, setting the
``allow_future`` option to ``True`` will make the future objects appear (and
@@ -398,46 +398,46 @@ Say a typical book publisher wants a page of recently published books. Given som
.. parsed-literal::
- from mysite.books.models import Book
+ from mysite.books.models import Book
from django.conf.urls.defaults import *
from django.views.generic import date_based
book_info = {
"queryset" : Book.objects.all(),
"date_field" : "publication_date"
}
-
+
urlpatterns = patterns('',
- (r'^books/$', date_based.archive_index, book_info),
+ (r'^books/$', date_based.archive_index, book_info),
)
Required Arguments
``````````````````
- * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
- ``QuerySet``'s model that the date-based archive should use to determine
- the objects on the page.
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
+ ``QuerySet``'s model that the date-based archive should use to determine
+ the objects on the page.
- * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
Optional Arguments
``````````````````
-
- * ``allow_future``: A Boolean specifying whether to include "future" objects
- on this page, as described in the previous note.
- * ``num_latest``: The number of latest objects to send to the template
- context. By default, it's 15.
+* ``allow_future``: A Boolean specifying whether to include "future" objects
+ on this page, as described in the previous note.
+
+* ``num_latest``: The number of latest objects to send to the template
+ context. By default, it's 15.
This view may also take these common arguments (see Table C-1):
- * ``allow_empty``
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
-
+* ``allow_empty``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+
Template Name
`````````````
@@ -449,16 +449,16 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``date_list``: A list of ``datetime.date`` objects representing all years
- that have objects available according to ``queryset``. These are ordered
- in reverse.
-
- For example, if you have blog entries from 2003 through 2006, this list
- will contain four ``datetime.date`` objects: one for each of those years.
-
- * ``latest``: The ``num_latest`` objects in the system, in descending order
- by ``date_field``. For example, if ``num_latest`` is ``10``, then
- ``latest`` will be a list of the latest ten objects in ``queryset``.
+* ``date_list``: A list of ``datetime.date`` objects representing all years
+ that have objects available according to ``queryset``. These are ordered
+ in reverse.
+
+ For example, if you have blog entries from 2003 through 2006, this list
+ will contain four ``datetime.date`` objects: one for each of those years.
+
+* ``latest``: The ``num_latest`` objects in the system, in descending order
+ by ``date_field``. For example, if ``num_latest`` is ``10``, then
+ ``latest`` will be a list of the latest ten objects in ``queryset``.
Year Archives
-------------
@@ -477,7 +477,7 @@ the books published in a given year:
.. parsed-literal::
- from mysite.books.models import Book
+ from mysite.books.models import Book
from django.conf.urls.defaults import *
from django.views.generic import date_based
@@ -487,42 +487,42 @@ the books published in a given year:
}
urlpatterns = patterns('',
- (r'^books/$', date_based.archive_index, book_info),
+ (r'^books/$', date_based.archive_index, book_info),
**(r'^books/(?P<year>\d{4})/?$', date_based.archive_year, book_info),**
)
Required Arguments
``````````````````
- * ``date_field``: As for ``archive_index`` (see the previous section).
+* ``date_field``: As for ``archive_index`` (see the previous section).
- * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+
+* ``year``: The four-digit year for which the archive serves (as in our
+ example, this is usually taken from a URL parameter).
- * ``year``: The four-digit year for which the archive serves (as in our
- example, this is usually taken from a URL parameter).
-
Optional Arguments
``````````````````
- * ``make_object_list``: A Boolean specifying whether to retrieve the full
- list of objects for this year and pass those to the template. If ``True``,
- this list of objects will be made available to the template as
- ``object_list``. (The name ``object_list`` may be different; see the
- information about ``object_list`` in the following "Template Context"
- section.) By default, this is ``False``.
-
- * ``allow_future``: A Boolean specifying whether to include "future" objects
- on this page.
-
+* ``make_object_list``: A Boolean specifying whether to retrieve the full
+ list of objects for this year and pass those to the template. If ``True``,
+ this list of objects will be made available to the template as
+ ``object_list``. (The name ``object_list`` may be different; see the
+ information about ``object_list`` in the following "Template Context"
+ section.) By default, this is ``False``.
+
+* ``allow_future``: A Boolean specifying whether to include "future" objects
+ on this page.
+
This view may also take these common arguments (see Table C-1):
- * ``allow_empty``
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
+* ``allow_empty``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
Template Name
`````````````
@@ -535,21 +535,21 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``date_list``: A list of ``datetime.date`` objects representing all months
- that have objects available in the given year, according to ``queryset``,
- in ascending order.
-
- * ``year``: The given year, as a four-character string.
-
- * ``object_list``: If the ``make_object_list`` parameter is ``True``, this
- will be set to a list of objects available for the given year, ordered by
- the date field. This variable's name depends on the
- ``template_object_name`` parameter, which is ``'object'`` by default. If
- ``template_object_name`` is ``'foo'``, this variable's name will be
- ``foo_list``.
-
- If ``make_object_list`` is ``False``, ``object_list`` will be passed to
- the template as an empty list.
+* ``date_list``: A list of ``datetime.date`` objects representing all months
+ that have objects available in the given year, according to ``queryset``,
+ in ascending order.
+
+* ``year``: The given year, as a four-character string.
+
+* ``object_list``: If the ``make_object_list`` parameter is ``True``, this
+ will be set to a list of objects available for the given year, ordered by
+ the date field. This variable's name depends on the
+ ``template_object_name`` parameter, which is ``'object'`` by default. If
+ ``template_object_name`` is ``'foo'``, this variable's name will be
+ ``foo_list``.
+
+ If ``make_object_list`` is ``False``, ``object_list`` will be passed to
+ the template as an empty list.
Month Archives
--------------
@@ -566,7 +566,7 @@ Continuing with our example, adding month views should look familiar:
.. parsed-literal::
urlpatterns = patterns('',
- (r'^books/$', date_based.archive_index, book_info),
+ (r'^books/$', date_based.archive_index, book_info),
(r'^books/(?P<year>\d{4})/?$', date_based.archive_year, book_info),
**(**
**r'^(?P<year>\d{4})/(?P<month>[a-z]{3})/$',**
@@ -578,40 +578,40 @@ Continuing with our example, adding month views should look familiar:
Required Arguments
``````````````````
- * ``year``: The four-digit year for which the archive serves (a string).
-
- * ``month``: The month for which the archive serves, formatted according to
- the ``month_format`` argument.
-
- * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
-
- * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
- ``QuerySet``'s model that the date-based archive should use to determine
- the objects on the page.
+* ``year``: The four-digit year for which the archive serves (a string).
+
+* ``month``: The month for which the archive serves, formatted according to
+ the ``month_format`` argument.
+
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
+ ``QuerySet``'s model that the date-based archive should use to determine
+ the objects on the page.
Optional Arguments
``````````````````
- * ``month_format``: A format string that regulates what format the ``month``
- parameter uses. This should be in the syntax accepted by Python's
- ``time.strftime``. (See Python's strftime documentation at
- http://docs.python.org/library/time.html#time.strftime.) It's set
- to ``"%b"`` by default, which is a three-letter month abbreviation (i.e.,
- "jan", "feb", etc.). To change it to use numbers, use ``"%m"``.
-
- * ``allow_future``: A Boolean specifying whether to include "future" objects
- on this page, as described in the previous note.
-
+* ``month_format``: A format string that regulates what format the ``month``
+ parameter uses. This should be in the syntax accepted by Python's
+ ``time.strftime``. (See Python's strftime documentation at
+ http://docs.python.org/library/time.html#time.strftime.) It's set
+ to ``"%b"`` by default, which is a three-letter month abbreviation (i.e.,
+ "jan", "feb", etc.). To change it to use numbers, use ``"%m"``.
+
+* ``allow_future``: A Boolean specifying whether to include "future" objects
+ on this page, as described in the previous note.
+
This view may also take these common arguments (see Table C-1):
- * ``allow_empty``
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
-
+* ``allow_empty``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
+
Template Name
`````````````
@@ -623,18 +623,18 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``month``: A ``datetime.date`` object representing the given month.
-
- * ``next_month``: A ``datetime.date`` object representing the first day of
- the next month. If the next month is in the future, this will be ``None``.
+* ``month``: A ``datetime.date`` object representing the given month.
- * ``previous_month``: A ``datetime.date`` object representing the first day
- of the previous month. Unlike ``next_month``, this will never be ``None``.
-
- * ``object_list``: A list of objects available for the given month. This
- variable's name depends on the ``template_object_name`` parameter, which
- is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this
- variable's name will be ``foo_list``.
+* ``next_month``: A ``datetime.date`` object representing the first day of
+ the next month. If the next month is in the future, this will be ``None``.
+
+* ``previous_month``: A ``datetime.date`` object representing the first day
+ of the previous month. Unlike ``next_month``, this will never be ``None``.
+
+* ``object_list``: A list of objects available for the given month. This
+ variable's name depends on the ``template_object_name`` parameter, which
+ is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this
+ variable's name will be ``foo_list``.
Week Archives
-------------
@@ -666,31 +666,31 @@ Example
Required Arguments
``````````````````
- * ``year``: The four-digit year for which the archive serves (a string).
-
- * ``week``: The week of the year for which the archive serves (a string).
-
- * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
-
- * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
- ``QuerySet``'s model that the date-based archive should use to determine
- the objects on the page.
+* ``year``: The four-digit year for which the archive serves (a string).
+
+* ``week``: The week of the year for which the archive serves (a string).
+
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
+ ``QuerySet``'s model that the date-based archive should use to determine
+ the objects on the page.
Optional Arguments
``````````````````
- * ``allow_future``: A Boolean specifying whether to include "future" objects
- on this page, as described in the previous note.
-
+* ``allow_future``: A Boolean specifying whether to include "future" objects
+ on this page, as described in the previous note.
+
This view may also take these common arguments (see Table C-1):
- * ``allow_empty``
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
+* ``allow_empty``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
Template Name
`````````````
@@ -703,13 +703,13 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``week``: A ``datetime.date`` object representing the first day of the
- given week.
-
- * ``object_list``: A list of objects available for the given week. This
- variable's name depends on the ``template_object_name`` parameter, which
- is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this
- variable's name will be ``foo_list``.
+* ``week``: A ``datetime.date`` object representing the first day of the
+ given week.
+
+* ``object_list``: A list of objects available for the given week. This
+ variable's name depends on the ``template_object_name`` parameter, which
+ is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this
+ variable's name will be ``foo_list``.
Day Archives
------------
@@ -736,42 +736,42 @@ Example
Required Arguments
``````````````````
- * ``year``: The four-digit year for which the archive serves (a string).
-
- * ``month``: The month for which the archive serves, formatted according to the
- ``month_format`` argument.
-
- * ``day``: The day for which the archive serves, formatted according to the
- ``day_format`` argument.
-
- * ``queryset``: A ``QuerySet`` of objects for which the archive serves.
-
- * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
- ``QuerySet``'s model that the date-based archive should use to determine
- the objects on the page.
+* ``year``: The four-digit year for which the archive serves (a string).
+
+* ``month``: The month for which the archive serves, formatted according to the
+ ``month_format`` argument.
+
+* ``day``: The day for which the archive serves, formatted according to the
+ ``day_format`` argument.
+
+* ``queryset``: A ``QuerySet`` of objects for which the archive serves.
+
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
+ ``QuerySet``'s model that the date-based archive should use to determine
+ the objects on the page.
Optional Arguments
``````````````````
-
- * ``month_format``: A format string that regulates what format the ``month``
- parameter uses. See the detailed explanation in the "Month Archives"
- section, above.
- * ``day_format``: Like ``month_format``, but for the ``day`` parameter. It
- defaults to ``"%d"`` (the day of the month as a decimal number, 01-31).
+* ``month_format``: A format string that regulates what format the ``month``
+ parameter uses. See the detailed explanation in the "Month Archives"
+ section, above.
+
+* ``day_format``: Like ``month_format``, but for the ``day`` parameter. It
+ defaults to ``"%d"`` (the day of the month as a decimal number, 01-31).
- * ``allow_future``: A Boolean specifying whether to include "future" objects
- on this page, as described in the previous note.
+* ``allow_future``: A Boolean specifying whether to include "future" objects
+ on this page, as described in the previous note.
This view may also take these common arguments (see Table C-1):
- * ``allow_empty``
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
+* ``allow_empty``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
Template Name
`````````````
@@ -784,18 +784,18 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``day``: A ``datetime.date`` object representing the given day.
-
- * ``next_day``: A ``datetime.date`` object representing the next day. If the
- next day is in the future, this will be ``None``.
+* ``day``: A ``datetime.date`` object representing the given day.
- * ``previous_day``: A ``datetime.date`` object representing the previous day.
- Unlike ``next_day``, this will never be ``None``.
-
- * ``object_list``: A list of objects available for the given day. This
- variable's name depends on the ``template_object_name`` parameter, which
- is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this
- variable's name will be ``foo_list``.
+* ``next_day``: A ``datetime.date`` object representing the next day. If the
+ next day is in the future, this will be ``None``.
+
+* ``previous_day``: A ``datetime.date`` object representing the previous day.
+ Unlike ``next_day``, this will never be ``None``.
+
+* ``object_list``: A list of objects available for the given day. This
+ variable's name depends on the ``template_object_name`` parameter, which
+ is ``'object'`` by default. If ``template_object_name`` is ``'foo'``, this
+ variable's name will be ``foo_list``.
Archive for Today
-----------------
@@ -812,7 +812,7 @@ Example
urlpatterns = patterns('',
# ...
- **(r'^books/today/$', date_based.archive_today, book_info),**
+ **(r'^books/today/$', date_based.archive_today, book_info),**
)
@@ -821,7 +821,7 @@ Date-Based Detail Pages
*View function*: ``django.views.generic.date_based.object_detail``
-Use this view for a page representing an individual object.
+Use this view for a page representing an individual object.
This has a different URL from the ``object_detail`` view; the ``object_detail``
view uses URLs like ``/entries/<slug>/``, while this one uses URLs like
@@ -833,12 +833,12 @@ view uses URLs like ``/entries/<slug>/``, while this one uses URLs like
also want to use the ``unique_for_date`` option on the slug field to
validate that slugs aren't duplicated in a single day. See Appendix A for
details on ``unique_for_date``.
-
+
Example
```````
-This one differs (slightly) from all the other date-based examples in that we
-need to provide either an object ID or a slug so that Django can look up the
+This one differs (slightly) from all the other date-based examples in that we
+need to provide either an object ID or a slug so that Django can look up the
object in question.
Since the object we're using doesn't have a slug field, we'll use ID-based URLs.
@@ -859,61 +859,61 @@ simplicity we'll let it go.
Required Arguments
``````````````````
- * ``year``: The object's four-digit year (a string).
-
- * ``month``: The object's month, formatted according to the ``month_format``
- argument.
-
- * ``day``: The object's day, formatted according to the ``day_format`` argument.
-
- * ``queryset``: A ``QuerySet`` that contains the object.
-
- * ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
- ``QuerySet``'s model that the generic view should use to look up the
- object according to ``year``, ``month``, and ``day``.
+* ``year``: The object's four-digit year (a string).
+
+* ``month``: The object's month, formatted according to the ``month_format``
+ argument.
+
+* ``day``: The object's day, formatted according to the ``day_format`` argument.
+
+* ``queryset``: A ``QuerySet`` that contains the object.
+
+* ``date_field``: The name of the ``DateField`` or ``DateTimeField`` in the
+ ``QuerySet``'s model that the generic view should use to look up the
+ object according to ``year``, ``month``, and ``day``.
You'll also need either:
- * ``object_id``: The value of the primary-key field for the object.
+* ``object_id``: The value of the primary-key field for the object.
or:
- * ``slug``: The slug of the given object. If you pass this field, then the
- ``slug_field`` argument (described in the following section) is also
- required.
+* ``slug``: The slug of the given object. If you pass this field, then the
+ ``slug_field`` argument (described in the following section) is also
+ required.
Optional Arguments
``````````````````
- * ``allow_future``: A Boolean specifying whether to include "future" objects
- on this page, as described in the previous note.
-
- * ``day_format``: Like ``month_format``, but for the ``day`` parameter. It
- defaults to ``"%d"`` (the day of the month as a decimal number, 01-31).
-
- * ``month_format``: A format string that regulates what format the ``month``
- parameter uses. See the detailed explanation in the "Month Archives"
- section, above.
-
- * ``slug_field``: The name of the field on the object containing the slug.
- This is required if you are using the ``slug`` argument, but it must be
- absent if you're using the ``object_id`` argument.
-
- * ``template_name_field``: The name of a field on the object whose value is
- the template name to use. This lets you store template names in the data.
- In other words, if your object has a field ``'the_template'`` that
- contains a string ``'foo.html'``, and you set ``template_name_field`` to
- ``'the_template'``, then the generic view for this object will use the
- template ``'foo.html'``.
-
+* ``allow_future``: A Boolean specifying whether to include "future" objects
+ on this page, as described in the previous note.
+
+* ``day_format``: Like ``month_format``, but for the ``day`` parameter. It
+ defaults to ``"%d"`` (the day of the month as a decimal number, 01-31).
+
+* ``month_format``: A format string that regulates what format the ``month``
+ parameter uses. See the detailed explanation in the "Month Archives"
+ section, above.
+
+* ``slug_field``: The name of the field on the object containing the slug.
+ This is required if you are using the ``slug`` argument, but it must be
+ absent if you're using the ``object_id`` argument.
+
+* ``template_name_field``: The name of a field on the object whose value is
+ the template name to use. This lets you store template names in the data.
+ In other words, if your object has a field ``'the_template'`` that
+ contains a string ``'foo.html'``, and you set ``template_name_field`` to
+ ``'the_template'``, then the generic view for this object will use the
+ template ``'foo.html'``.
+
This view may also take these common arguments (see Table C-1):
- * ``context_processors``
- * ``extra_context``
- * ``mimetype``
- * ``template_loader``
- * ``template_name``
- * ``template_object_name``
+* ``context_processors``
+* ``extra_context``
+* ``mimetype``
+* ``template_loader``
+* ``template_name``
+* ``template_object_name``
Template Name
`````````````
@@ -926,7 +926,7 @@ Template Context
In addition to ``extra_context``, the template's context will be as follows:
- * ``object``: The object. This variable's name depends on the
- ``template_object_name`` parameter, which is ``'object'`` by default. If
- ``template_object_name`` is ``'foo'``, this variable's name will be
- ``foo``.
+* ``object``: The object. This variable's name depends on the
+ ``template_object_name`` parameter, which is ``'object'`` by default. If
+ ``template_object_name`` is ``'foo'``, this variable's name will be
+ ``foo``.
View
56 appendixD.rst
@@ -19,15 +19,15 @@ Here are a couple of example settings::
Because a settings file is a Python module, the following apply:
- * It must be valid Python code; syntax errors aren't allowed.
-
- * It can assign settings dynamically using normal Python syntax,
- for example::
+* It must be valid Python code; syntax errors aren't allowed.
- MY_SETTING = [str(i) for i in range(30)]
+* It can assign settings dynamically using normal Python syntax,
+ for example::
+
+ MY_SETTING = [str(i) for i in range(30)]
+
+* It can import values from other settings files.
- * It can import values from other settings files.
-
Default Settings
----------------
@@ -37,9 +37,9 @@ to. Each setting has a sensible default value. These defaults live in the file
Here's the algorithm Django uses in compiling settings:
- * Load settings from ``global_settings.py``.
- * Load settings from the specified settings file, overriding the global
- settings as necessary.
+* Load settings from ``global_settings.py``.
+* Load settings from the specified settings file, overriding the global
+ settings as necessary.
Note that a settings file should *not* import from ``global_settings``, because
that's redundant.
@@ -101,13 +101,13 @@ Creating Your Own Settings
There's nothing stopping you from creating your own settings, for your own
Django applications. Just follow these conventions:
- * Use all uppercase for setting names.
-
- * For settings that are sequences, use tuples instead of lists. Settings
- should be considered immutable and shouldn't be changed once they're
- defined. Using tuples mirrors these semantics.
-
- * Don't reinvent an already existing setting.
+* Use all uppercase for setting names.
+
+* For settings that are sequences, use tuples instead of lists. Settings
+ should be considered immutable and shouldn't be changed once they're
+ defined. Using tuples mirrors these semantics.
+
+* Don't reinvent an already existing setting.
Designating the Settings: DJANGO_SETTINGS_MODULE
================================================
@@ -178,7 +178,7 @@ calling ``django.conf.settings.configure()``. Here's an example::
from django.conf import settings
settings.configure(
- DEBUG = True,
+ DEBUG = True,
TEMPLATE_DEBUG = True,
TEMPLATE_DIRS = [
'/home/web-apps/myapp',
@@ -279,7 +279,7 @@ ADMIN_MEDIA_PREFIX
*Default*: ``'/media/'``
-This setting is the URL prefix for admin media: CSS, JavaScript, and images.
+This setting is the URL prefix for admin media: CSS, JavaScript, and images.
Make sure to use a trailing slash.
ADMINS
@@ -344,7 +344,7 @@ DATABASE_HOST
*Default*: ``''`` (empty string)
-This setting indicates which host to use when connecting to the database.
+This setting indicates which host to use when connecting to the database.
An empty string means ``localhost``. This is not used with SQLite.
If this value starts with a forward slash (``'/'``) and you're using MySQL,
@@ -558,7 +558,7 @@ LANGUAGE_CODE
*Default*: ``'en-us'``
This is a string representing the language code for this installation. This should be
-in standard language format -- for example, U.S. English is ``"en-us"``. See
+in standard language format -- for example, U.S. English is ``"en-us"``. See
Chapter 19.
LANGUAGES
@@ -622,8 +622,8 @@ This URL handles the media served from ``MEDIA_ROOT`` (e.g.,
Note that this should have a trailing slash if it has a path component:
- * *Correct*: ``"http://www.example.com/static/"``
- * *Incorrect*: ``"http://www.example.com/static"``
+* *Correct*: ``"http://www.example.com/static/"``
+* *Incorrect*: ``"http://www.example.com/static"``
See Chapter 12 for more on deployment and serving media.
@@ -662,7 +662,7 @@ PREPEND_WWW
*Default*: ``False``
-This setting indicates whether to prepend the "www." subdomain to URLs that don't have it.
+This setting indicates whether to prepend the "www." subdomain to URLs that don't have it.
This is used only if ``CommonMiddleware`` is installed (see the Chapter 17). See also
``APPEND_SLASH``.
@@ -740,8 +740,8 @@ SESSION_COOKIE_SECURE
*Default*: ``False``
-This setting indicates whether to use a secure cookie for the session cookie.
-If this is set to ``True``, the cookie will be marked as "secure,"
+This setting indicates whether to use a secure cookie for the session cookie.
+If this is set to ``True``, the cookie will be marked as "secure,"
which means browsers may ensure that the cookie is only sent under an HTTPS connection.
See Chapter 14.
@@ -750,7 +750,7 @@ SESSION_EXPIRE_AT_BROWSER_CLOSE
*Default*: ``False``
-This setting indicates whether to expire the session when the user closes
+This setting indicates whether to expire the session when the user closes
his browser. See Chapter 14.
SESSION_SAVE_EVERY_REQUEST
@@ -810,7 +810,7 @@ paths should use Unix-style forward slashes, even on Windows. See Chapters 4 and
TEMPLATE_LOADERS
----------------
-*Default*:
+*Default*::
('django.template.loaders.filesystem.load_template_source',
'django.template.loaders.app_directories.load_template_source')
View
44 appendixE.rst
@@ -107,13 +107,13 @@ Signal that this template extends a parent template.
This tag can be used in two ways:
- * ``{% extends "base.html" %}`` (with quotes) uses the literal value
- ``"base.html"`` as the name of the parent template to extend.
+* ``{% extends "base.html" %}`` (with quotes) uses the literal value
+ ``"base.html"`` as the name of the parent template to extend.
- * ``{% extends variable %}`` uses the value of ``variable``. If the variable
- evaluates to a string, Django will use that string as the name of the
- parent template. If the variable evaluates to a ``Template`` object,
- Django will use that object as the parent template.
+* ``{% extends variable %}`` uses the value of ``variable``. If the variable
+ evaluates to a string, Django will use that string as the name of the
+ parent template. If the variable evaluates to a ``Template`` object,
+ Django will use that object as the parent template.
See Chapter 4 for more information on template inheritance.
@@ -386,14 +386,14 @@ the variable ``template_name``::
An included template is rendered with the context of the template that's
including it. This example produces the output ``"Hello, John"``:
- * Context: variable ``person`` is set to ``"john"``.
- * Template::
+* Context: variable ``person`` is set to ``"john"``.
+* Template::
- {% include "name_snippet.html" %}
+ {% include "name_snippet.html" %}
- * The ``name_snippet.html`` template::
+* The ``name_snippet.html`` template::
- Hello, {{ person }}
+ Hello, {{ person }}
See also: ``{% ssi %}``.
@@ -508,7 +508,7 @@ is a list of people represented by dictionaries with ``first_name``,
]
...and you'd like to display a hierarchical list that is ordered by gender,
-like this:
+like this::
* Male:
* George Bush
@@ -544,10 +544,10 @@ attribute and calling the result ``gender_list``.
``{% regroup %}`` produces a list (in this case, ``gender_list``) of
**group objects**. Each group object has two attributes:
- * ``grouper`` -- the item that was grouped by (e.g., the string "Male" or
- "Female").
- * ``list`` -- a list of all items in this group (e.g., a list of all people
- with gender='Male').
+* ``grouper`` -- the item that was grouped by (e.g., the string "Male" or
+ "Female").
+* ``list`` -- a list of all items in this group (e.g., a list of all people
+ with gender='Male').
Note that ``{% regroup %}`` does not order its input! Our example relies on
the fact that the ``people`` list was ordered by ``gender`` in the first place.
@@ -567,7 +567,7 @@ together):
]
With this input for ``people``, the example ``{% regroup %}`` template code
-above would result in the following output:
+above would result in the following output::
* Male:
* Bill Clinton
@@ -856,11 +856,11 @@ escape
Escapes a string's HTML. Specifically, it makes these replacements:
- * ``<`` is converted to ``&lt;``
- * ``>`` is converted to ``&gt;``
- * ``'`` (single quote) is converted to ``&#39;``
- * ``"`` (double quote) is converted to ``&quot;``
- * ``&`` is converted to ``&amp;``
+* ``<`` is converted to ``&lt;``
+* ``>`` is converted to ``&gt;``
+* ``'`` (single quote) is converted to ``&#39;``
+* ``"`` (double quote) is converted to ``&quot;``
+* ``&`` is converted to ``&amp;``
The escaping is only applied when the string is output, so it does not matter
where in a chained sequence of filters you put ``escape``: it will always be
View
60 appendixF.rst
@@ -10,10 +10,10 @@ wrapper. ``manage.py`` is automatically created in each Django project and is a
thin wrapper around ``django-admin.py``. It takes care of two things for you
before delegating to ``django-admin.py``:
- * It puts your project's package on ``sys.path``.
+* It puts your project's package on ``sys.path``.
- * It sets the ``DJANGO_SETTINGS_MODULE`` environment variable so that it
- points to your project's ``settings.py`` file.
+* It sets the ``DJANGO_SETTINGS_MODULE`` environment variable so that it
+ points to your project's ``settings.py`` file.
The ``django-admin.py`` script should be on your system path if you installed
Django via its ``setup.py`` utility. If it's not on your path, you can find it in
@@ -140,9 +140,9 @@ Runs the command-line client for the database engine specified in your
``DATABASE_ENGINE`` setting, with the connection parameters specified in your
``DATABASE_USER``, ``DATABASE_PASSWORD``, etc., settings.
- * For PostgreSQL, this runs the ``psql`` command-line client.
- * For MySQL, this runs the ``mysql`` command-line client.
- * For SQLite, this runs the ``sqlite3`` command-line client.
+* For PostgreSQL, this runs the ``psql`` command-line client.
+* For MySQL, this runs the ``mysql`` command-line client.
+* For SQLite, this runs the ``sqlite3`` command-line client.
This command assumes the programs are on your ``PATH`` so that a simple call to
the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
@@ -232,19 +232,19 @@ As you might expect, the created models will have an attribute for every field
in the table. Note that ``inspectdb`` has a few special cases in its field-name
output:
- * If ``inspectdb`` cannot map a column's type to a model field type, it'll
- use ``TextField`` and will insert the Python comment
- ``'This field type is a guess.'`` next to the field in the generated
- model.
+* If ``inspectdb`` cannot map a column's type to a model field type, it'll
+ use ``TextField`` and will insert the Python comment
+ ``'This field type is a guess.'`` next to the field in the generated
+ model.
- * If the database column name is a Python reserved word (such as
- ``'pass'``, ``'class'`` or ``'for'``), ``inspectdb`` will append
- ``'_field'`` to the attribute name. For example, if a table has a column
- ``'for'``, the generated model will have a field ``'for_field'``, with
- the ``db_column`` attribute set to ``'for'``. ``inspectdb`` will insert
- the Python comment
- ``'Field renamed because it was a Python reserved word.'`` next to the
- field.
+* If the database column name is a Python reserved word (such as
+ ``'pass'``, ``'class'`` or ``'for'``), ``inspectdb`` will append
+ ``'_field'`` to the attribute name. For example, if a table has a column
+ ``'for'``, the generated model will have a field ``'for_field'``, with
+ the ``db_column`` attribute set to ``'for'``. ``inspectdb`` will insert
+ the Python comment
+ ``'Field renamed because it was a Python reserved word.'`` next to the
+ field.
This feature is meant as a shortcut, not as definitive model generation. After
you run it, you'll want to look over the generated models yourself to make
@@ -272,9 +272,9 @@ fixture can be distributed over multiple directories, in multiple applications.
Django will search in three locations for fixtures:
- 1. In the ``fixtures`` directory of every installed application
- 2. In any directory named in the ``FIXTURE_DIRS`` setting
- 3. In the literal path named by the fixture
+1. In the ``fixtures`` directory of every installed application
+2. In any directory named in the ``FIXTURE_DIRS`` setting
+3. In the literal path named by the fixture
Django will load any and all fixtures it finds in these locations that match
the provided fixture names.
@@ -395,8 +395,8 @@ Example usage::
Use the ``--domain`` or ``-d`` option to change the domain of the messages files.
Currently supported:
- * ``django`` for all ``*.py`` and ``*.html`` files (default)
- * ``djangojs`` for ``*.js`` files
+* ``django`` for all ``*.py`` and ``*.html`` files (default)
+* ``djangojs`` for ``*.js`` files
.. _django-admin-reset:
@@ -704,9 +704,9 @@ Example usage::
Use ``--verbosity`` to specify the amount of notification and debug information
that ``django-admin.py`` should print to the console.
- * ``0`` means no output.
- * ``1`` means normal output (default).
- * ``2`` means verbose output.
+* ``0`` means no output.
+* ``1`` means normal output (default).
+* ``2`` means verbose output.
Extra niceties
==============
@@ -727,7 +727,7 @@ script, which lives in ``extras/django_bash_completion`` in the Django
distribution. It enables tab-completion of ``django-admin.py`` and
``manage.py`` commands, so you can, for instance...
- * Type ``django-admin.py``.
- * Press [TAB] to see all available options.
- * Type ``sql``, then [TAB], to see all available options whose names start
- with ``sql``.
+* Type ``django-admin.py``.
+* Press [TAB] to see all available options.
+* Type ``sql``, then [TAB], to see all available options whose names start
+ with ``sql``.
View
196 appendixG.rst
@@ -26,117 +26,117 @@ on the ``HttpRequest`` instance (see Table G-1). All attributes except
================== =======================================================
Attribute Description
================== =======================================================
- ``path`` A string representing the full path to the requested
- page, not including the domain -- for example,
+ ``path`` A string representing the full path to the requested
+ page, not including the domain -- for example,
``"/music/bands/the_beatles/"``.
-
- ``method`` A string representing the HTTP method used in the
- request. This is guaranteed to be uppercase. For
+
+ ``method`` A string representing the HTTP method used in the
+ request. This is guaranteed to be uppercase. For
example::
-
+
if request.method == 'GET':
do_something()
elif request.method == 'POST':
do_something_else()
-
+
``encoding`` A string representing the current encoding used to
decode form submission data (or ``None``, which means
the ``DEFAULT_CHARSET`` setting is used).
-
+
You can write to this attribute to change the encoding
used when accessing the form data. Any subsequent
attribute accesses (such as reading from ``GET`` or
``POST``) will use the new ``encoding`` value. Useful
if you know the form data is not in the
``DEFAULT_CHARSET`` encoding.
-
+
``GET`` A dictionary-like object containing all given HTTP GET
parameters. See the upcoming ``QueryDict`` documentation.
-
+
``POST`` A dictionary-like object containing all given HTTP POST
parameters. See the upcoming ``QueryDict`` documentation.
-
+
It's possible that a request can come in via POST with
an empty ``POST`` dictionary -- if, say, a form is
requested via the POST HTTP method but does not
include form data. Therefore, you shouldn't use ``if
request.POST`` to check for use of the POST method;
instead, use ``if request.method == "POST"`` (see
the ``method`` entry in this table).
-
+
Note: ``POST`` does *not* include file-upload
information. See ``FILES``.
-
+
``REQUEST`` For convenience, a dictionary-like object that searches
``POST`` first, and then ``GET``. Inspired by PHP's
``$_REQUEST``.
-
+
For example, if ``GET = {"name": "john"}`` and ``POST
= {"age": '34'}``, ``REQUEST["name"]`` would be
``"john"``, and ``REQUEST["age"]`` would be ``"34"``.