Fixed display of lists after website redesign
Thanks Brian Jacobel for the report. refs django/djangoproject.com#197
This commit is contained in:
parent
1c5cbf5e5d
commit
c7786550c4
|
@ -833,12 +833,17 @@ This complex tag is best illustrated by way of an example: say that "places" is
|
|||
...and you'd like to display a hierarchical list that is ordered by country, like this:
|
||||
|
||||
* India
|
||||
|
||||
* Mumbai: 19,000,000
|
||||
* Calcutta: 15,000,000
|
||||
|
||||
* USA
|
||||
|
||||
* New York: 20,000,000
|
||||
* Chicago: 7,000,000
|
||||
|
||||
* Japan
|
||||
|
||||
* Tokyo: 33,000,000
|
||||
|
||||
|
||||
|
@ -893,14 +898,23 @@ With this input for ``cities``, the example ``{% regroup %}`` template code
|
|||
above would result in the following output:
|
||||
|
||||
* India
|
||||
|
||||
* Mumbai: 19,000,000
|
||||
|
||||
* USA
|
||||
|
||||
* New York: 20,000,000
|
||||
|
||||
* India
|
||||
|
||||
* Calcutta: 15,000,000
|
||||
|
||||
* USA
|
||||
|
||||
* Chicago: 7,000,000
|
||||
|
||||
* Japan
|
||||
|
||||
* Tokyo: 33,000,000
|
||||
|
||||
The easiest solution to this gotcha is to make sure in your view code that the
|
||||
|
|
|
@ -836,11 +836,11 @@ Object Relational Mapper changes
|
|||
Django 1.6 contains many changes to the ORM. These changes fall mostly in
|
||||
three categories:
|
||||
|
||||
1. Bug fixes (e.g. proper join clauses for generic relations, query
|
||||
combining, join promotion, and join trimming fixes)
|
||||
2. Preparation for new features. For example the ORM is now internally ready
|
||||
1. Bug fixes (e.g. proper join clauses for generic relations, query combining,
|
||||
join promotion, and join trimming fixes)
|
||||
2. Preparation for new features. For example the ORM is now internally ready
|
||||
for multicolumn foreign keys.
|
||||
3. General cleanup.
|
||||
3. General cleanup.
|
||||
|
||||
These changes can result in some compatibility problems. For example, some
|
||||
queries will now generate different table aliases. This can affect
|
||||
|
|
|
@ -169,11 +169,12 @@ got a fast, well-indexed database server.
|
|||
|
||||
To use a database table as your cache backend:
|
||||
|
||||
* Set :setting:`BACKEND <CACHES-BACKEND>` to
|
||||
* Set :setting:`BACKEND <CACHES-BACKEND>` to
|
||||
``django.core.cache.backends.db.DatabaseCache``
|
||||
* Set :setting:`LOCATION <CACHES-LOCATION>` to ``tablename``, the name of
|
||||
the database table. This name can be whatever you want, as long as it's
|
||||
a valid table name that's not already being used in your database.
|
||||
|
||||
* Set :setting:`LOCATION <CACHES-LOCATION>` to ``tablename``, the name of the
|
||||
database table. This name can be whatever you want, as long as it's a valid
|
||||
table name that's not already being used in your database.
|
||||
|
||||
In this example, the cache table's name is ``my_cache_table``::
|
||||
|
||||
|
|
|
@ -148,9 +148,9 @@ Instantiating, processing, and rendering forms
|
|||
|
||||
When rendering an object in Django, we generally:
|
||||
|
||||
1. get hold of it in the view (fetch it from the database, for example)
|
||||
2. pass it to the template context
|
||||
3. expand it to HTML markup using template variables
|
||||
1. get hold of it in the view (fetch it from the database, for example)
|
||||
2. pass it to the template context
|
||||
3. expand it to HTML markup using template variables
|
||||
|
||||
Rendering a form in a template involves nearly the same work as rendering any
|
||||
other kind of object, but there are some key differences.
|
||||
|
|
Loading…
Reference in New Issue