summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorMarkus Holtermann <info@markusholtermann.eu>2014-12-17 14:01:19 +0100
committerTim Graham <timograham@gmail.com>2014-12-17 08:24:00 -0500
commitc7786550c4ed396b8580db58f7da60e850894d19 (patch)
treee4e0920c0ab61d15b18fd7df50e8cf6b5a363c63 /docs
parent1c5cbf5e5d5b350f4df4aca6431d46c767d3785a (diff)
Fixed display of lists after website redesign
Thanks Brian Jacobel for the report. refs django/djangoproject.com#197
Diffstat (limited to 'docs')
-rw-r--r--docs/ref/templates/builtins.txt34
-rw-r--r--docs/releases/1.6.txt10
-rw-r--r--docs/topics/cache.txt11
-rw-r--r--docs/topics/forms/index.txt6
4 files changed, 38 insertions, 23 deletions
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index 146f2eacd6..e1ea472f7a 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -833,13 +833,18 @@ 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
+
+ * Mumbai: 19,000,000
+ * Calcutta: 15,000,000
+
* USA
- * New York: 20,000,000
- * Chicago: 7,000,000
+
+ * New York: 20,000,000
+ * Chicago: 7,000,000
+
* Japan
- * Tokyo: 33,000,000
+
+ * Tokyo: 33,000,000
You can use the ``{% regroup %}`` tag to group the list of cities by country.
@@ -893,15 +898,24 @@ With this input for ``cities``, the example ``{% regroup %}`` template code
above would result in the following output:
* India
- * Mumbai: 19,000,000
+
+ * Mumbai: 19,000,000
+
* USA
- * New York: 20,000,000
+
+ * New York: 20,000,000
+
* India
- * Calcutta: 15,000,000
+
+ * Calcutta: 15,000,000
+
* USA
- * Chicago: 7,000,000
+
+ * Chicago: 7,000,000
+
* Japan
- * Tokyo: 33,000,000
+
+ * Tokyo: 33,000,000
The easiest solution to this gotcha is to make sure in your view code that the
data is ordered according to how you want to display it.
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 2585de13b8..d261a480ba 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -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
- for multicolumn foreign keys.
- 3. General cleanup.
+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.
These changes can result in some compatibility problems. For example, some
queries will now generate different table aliases. This can affect
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index b515925df2..38d2f26cbe 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -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
- ``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:`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.
In this example, the cache table's name is ``my_cache_table``::
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index c11b96ba15..85c03a48b8 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -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.