sqlalchemy: Merged revisions 3918 to 4053 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/sqlalchemy@4054 bcc190cf-cafb-0310-a4f2-bffc1f526a37

11 files changed, 113 insertions, 31 deletions

diff --git a/docs/authentication.txt b/docs/authentication.txt
index 2a61ec82b5..08565e13e1 100644
--- a/docs/authentication.txt
+++ b/docs/authentication.txt
@@ -745,7 +745,7 @@ messages are made available in the `template context`_ as the template variable
     {% if messages %}
     <ul>
         {% for message in messages %}
-        <li>{{ message.message }}</li>
+        <li>{{ message }}</li>
         {% endfor %}
     </ul>
     {% endif %}
diff --git a/docs/forms.txt b/docs/forms.txt
index 4a4ba37289..ff192a4717 100644
--- a/docs/forms.txt
+++ b/docs/forms.txt
@@ -610,6 +610,15 @@ fails. If no message is passed in, a default message is used.
     string "123" is less than the string "2", for example. If you don't want
     string comparison here, you will need to write your own validator.
 
+``NumberIsInRange``
+    Takes two boundary numbers, ``lower`` and ``upper``, and checks that the
+    field is greater than ``lower`` (if given) and less than ``upper`` (if
+    given).  
+    
+    Both checks are inclusive. That is, ``NumberIsInRange(10, 20)`` will allow
+    values of both 10 and 20. This validator only checks numeric values
+    (e.g., float and integer values).
+
 ``IsAPowerOf``
     Takes an integer argument and when called as a validator, checks that the
     field being validated is a power of the integer.
diff --git a/docs/generic_views.txt b/docs/generic_views.txt
index 99a9b7cf6b..1736770a20 100644
--- a/docs/generic_views.txt
+++ b/docs/generic_views.txt
@@ -92,6 +92,14 @@ which is a dictionary of the parameters captured in the URL.
 
     * ``template``: The full name of a template to use.
 
+**Optional arguments:**
+
+    * ``extra_context``: A dictionary of values to add to the template
+      context. By default, this is an empty dictionary. If a value in the
+      dictionary is callable, the generic view will call it
+      just before rendering the template. (**This is new in the
+      Django development version.**)
+      
 **Example:**
 
 Given the following URL patterns::
@@ -171,7 +179,7 @@ a date in the *future* are not included unless you set ``allow_future`` to
       template. By default, it's ``django.template.loader``.
 
     * ``extra_context``: A dictionary of values to add to the template
-      context. By default, this is an empty dictionary.
+      context. By default, this is an empty dictionary. If a value in the
       dictionary is callable, the generic view will call it
       just before rendering the template.
 
diff --git a/docs/modpython.txt b/docs/modpython.txt
index b88874d3d3..5177abf728 100644
--- a/docs/modpython.txt
+++ b/docs/modpython.txt
@@ -43,6 +43,11 @@ This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the
 Django mod_python handler." It passes the value of ``DJANGO_SETTINGS_MODULE``
 so mod_python knows which settings to use.
 
+Note that we're using the ``<Location>`` directive, not the ``<Directory>``
+directive. The latter is used for pointing at places on your filesystem,
+whereas ``<Location>`` points at places in the URL structure of a Web site.
+``<Directory>`` would be meaningless here.
+
 Also, if you've manually altered your ``PYTHONPATH`` to put your Django project
 on it, you'll need to tell mod_python::
 
diff --git a/docs/settings.txt b/docs/settings.txt
index 0e808c018b..ff1e2eeca2 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -265,6 +265,14 @@ Default: ``''`` (Empty string)
 The name of the database to use. For SQLite, it's the full path to the database
 file.
 
+DATABASE_OPTIONS
+----------------
+
+Default: ``{}`` (Empty dictionary)
+
+Extra parameters to use when connecting to the database. Consult backend
+module's document for available keywords.
+
 DATABASE_PASSWORD
 -----------------
 
@@ -528,7 +536,7 @@ any code that uses ``LANGUAGES`` at runtime.
 MANAGERS
 --------
 
-Default: ``ADMINS`` (Whatever ``ADMINS`` is set to)
+Default: ``()`` (Empty tuple)
 
 A tuple in the same format as ``ADMINS`` that specifies who should get
 broken-link notifications when ``SEND_BROKEN_LINK_EMAILS=True``.
@@ -814,6 +822,16 @@ manual configuration option (see below), Django will *not* touch the ``TZ``
 environment variable, and it'll be up to you to ensure your processes are
 running in the correct environment.
 
+URL_VALIDATOR_USER_AGENT
+------------------------
+
+Default: ``Django/<version> (http://www.djangoproject.com/)``
+
+The string to use as the ``User-Agent`` header when checking to see if URLs
+exist (see the ``verify_exists`` option on URLField_).
+
+.. URLField: ../model_api/#urlfield
+
 USE_ETAGS
 ---------
 
diff --git a/docs/static_files.txt b/docs/static_files.txt
index d8d90e52d5..55380a659b 100644
--- a/docs/static_files.txt
+++ b/docs/static_files.txt
@@ -31,7 +31,7 @@ How to do it
 
 Just put this in your URLconf_::
 
-    (r'^site_media/(.*)$', 'django.views.static.serve', {'document_root': '/path/to/media'}),
+    (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/path/to/media'}),
 
 ...where ``site_media`` is the URL where your media will be rooted, and
 ``/path/to/media`` is the filesystem root for your media.
@@ -60,7 +60,7 @@ listings for directories.
 
 Example::
 
-    (r'^site_media/(.*)$', 'django.views.static.serve', {'document_root': '/path/to/media', 'show_indexes': True}),
+    (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/path/to/media', 'show_indexes': True}),
 
 You can customize the index view by creating a template called
 ``static/directory_index``. That template gets two objects in its context:
diff --git a/docs/syndication_feeds.txt b/docs/syndication_feeds.txt
index 225b67eb02..59a9022d9b 100644
--- a/docs/syndication_feeds.txt
+++ b/docs/syndication_feeds.txt
@@ -95,7 +95,7 @@ latest five news items::
     from django.contrib.syndication.feeds import Feed
     from chicagocrime.models import NewsItem
 
-    class SiteNewsFeed(Feed):
+    class LatestEntries(Feed):
         title = "Chicagocrime.org site news"
         link = "/sitenews/"
         description = "Updates on changes and additions to chicagocrime.org."
@@ -120,14 +120,14 @@ One thing's left to do. In an RSS feed, each ``<item>`` has a ``<title>``,
 put into those elements.
 
     * To specify the contents of ``<title>`` and ``<description>``, create
-      `Django templates`_ called ``feeds/sitenews_title.html`` and
-      ``feeds/sitenews_description.html``, where ``sitenews`` is the ``slug``
+      `Django templates`_ called ``feeds/latest_title.html`` and
+      ``feeds/latest_description.html``, where ``latest`` is the ``slug``
       specified in the URLconf for the given feed. Note the ``.html`` extension
       is required. The RSS system renders that template for each item, passing
       it two template context variables:
 
           * ``{{ obj }}`` -- The current object (one of whichever objects you
-            returned in ``items()``).
+            returned in ``items()``). 
           * ``{{ site }}`` -- A ``django.models.core.sites.Site`` object
             representing the current site. This is useful for
             ``{{ site.domain }}`` or ``{{ site.name }}``.
@@ -145,6 +145,16 @@ put into those elements.
       Both ``get_absolute_url()`` and ``item_link()`` should return the item's
       URL as a normal Python string.
 
+    * For the LatestEntries example above, we could have very simple feed templates:
+
+          * latest_title.html::
+
+             {{ obj.title }}
+
+          * latest_description.html::
+
+             {{ obj.description }}
+
 .. _chicagocrime.org: http://www.chicagocrime.org/
 .. _object-relational mapper: http://www.djangoproject.com/documentation/db_api/
 .. _Django templates: http://www.djangoproject.com/documentation/templates/
diff --git a/docs/templates.txt b/docs/templates.txt
index b263a64aec..7a580bd0db 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -109,6 +109,21 @@ Some tags require beginning and ending tags (i.e.
 below describes all the built-in tags. You can create your own tags, if you
 know how to write Python code.
 
+Comments
+========
+
+**New in Django development version**
+
+To comment-out part of a template, use the comment syntax: ``{# #}``.
+
+For example, this template would render as ``'hello'``::
+
+    {# greeting #}hello
+
+A comment can contain any template code, invalid or not. For example::
+
+    {# {% if foo %}bar{% else %} #}
+
 Template inheritance
 ====================
 
@@ -458,7 +473,7 @@ block are output::
 In the above, if ``athlete_list`` is not empty, the number of athletes will be
 displayed by the ``{{ athlete_list|length }}`` variable.
 
-As you can see, the ``if`` tag can take an option ``{% else %}`` clause that
+As you can see, the ``if`` tag can take an optional ``{% else %}`` clause that
 will be displayed if the test fails.
 
 ``if`` tags may use ``and``, ``or`` or ``not`` to test a number of variables or
@@ -510,16 +525,29 @@ ifchanged
 
 Check if a value has changed from the last iteration of a loop.
 
-The ``ifchanged`` block tag is used within a loop. It checks its own rendered
-contents against its previous state and only displays its content if the value
-has changed::
+The 'ifchanged' block tag is used within a loop. It has two possible uses.
 
-    <h1>Archive for {{ year }}</h1>
+1. Checks its own rendered contents against its previous state and only
+   displays the content if it has changed. For example, this displays a list of
+   days, only displaying the month if it changes::
 
-    {% for day in days %}
-    {% ifchanged %}<h3>{{ day|date:"F" }}</h3>{% endifchanged %}
-    <a href="{{ day|date:"M/d"|lower }}/">{{ day|date:"j" }}</a>
-    {% endfor %}
+        <h1>Archive for {{ year }}</h1>
+
+        {% for date in days %}
+            {% ifchanged %}<h3>{{ date|date:"F" }}</h3>{% endifchanged %}
+            <a href="{{ date|date:"M/d"|lower }}/">{{ date|date:"j" }}</a>
+        {% endfor %}
+
+2. **New in Django development version.** If given a variable, check whether that
+   variable has changed. For example, the following shows the date every time it
+   changes, but only shows the hour if both the hour and the date has changed::
+
+        {% for date in days %}
+            {% ifchanged date.date %} {{ date.date }} {% endifchanged %}
+            {% ifchanged date.hour date.date %}
+                {{ date.hour }}
+            {% endifchanged %}
+        {% endfor %}
 
 ifequal
 ~~~~~~~
@@ -785,8 +813,12 @@ The argument tells which template bit to output:
     ``closevariable``   ``}}``
     ``openbrace``       ``{``
     ``closebrace``      ``}``
+    ``opencomment``     ``{#``
+    ``closecomment``    ``#}``
     ==================  =======
 
+Note: ``opencomment`` and ``closecomment`` are new in the Django development version.
+
 widthratio
 ~~~~~~~~~~
 
diff --git a/docs/templates_python.txt b/docs/templates_python.txt
index 81e7d45133..ae2582d7b8 100644
--- a/docs/templates_python.txt
+++ b/docs/templates_python.txt
@@ -312,18 +312,18 @@ optional, third positional argument, ``processors``. In this example, the
         }, [ip_address_processor])
 
 Note::
-    If you are using Django's ``render_to_response()`` shortcut to populate a
+    If you're using Django's ``render_to_response()`` shortcut to populate a
     template with the contents of a dictionary, your template will be passed a
-    ``Context`` instance by default (not a ``RequestContext``). If you wish to
-    use a ``RequestContext`` in your template rendering, you need to pass an
-    optional third argument to ``render_to_response()``: a ``RequestContext``
+    ``Context`` instance by default (not a ``RequestContext``). To use a
+    ``RequestContext`` in your template rendering, pass an optional third
+    argument to ``render_to_response()``: a ``RequestContext``
     instance. Your code might look like this::
 
         def some_view(request):
             # ...
             return render_to_response('my_template'html',
                                       my_data_dictionary,
-                                      context_instance = RequestContext(request))
+                                      context_instance=RequestContext(request))
 
 Here's what each of the default processors does:
 
@@ -1092,7 +1092,7 @@ Configuring the template system in standalone mode
 .. note::
 
     This section is only of interest to people trying to use the template
-    system as an output component in another application. If you are using the
+    system as an output component in another application. If you're using the
     template system as part of a Django application, nothing here applies to
     you.
 
@@ -1109,7 +1109,7 @@ described in the `settings file`_ documentation. Simply import the appropriate
 pieces of the templating system and then, *before* you call any of the
 templating functions, call ``django.conf.settings.configure()`` with any
 settings you wish to specify. You might want to consider setting at least
-``TEMPLATE_DIRS`` (if you are going to use template loaders),
+``TEMPLATE_DIRS`` (if you're going to use template loaders),
 ``DEFAULT_CHARSET`` (although the default of ``utf-8`` is probably fine) and
 ``TEMPLATE_DEBUG``. All available settings are described in the
 `settings documentation`_, and any setting starting with *TEMPLATE_*
diff --git a/docs/tutorial02.txt b/docs/tutorial02.txt
index 06cde251e5..f6d4045fa3 100644
--- a/docs/tutorial02.txt
+++ b/docs/tutorial02.txt
@@ -383,10 +383,10 @@ Django where our templates live::
 Now copy the template ``admin/base_site.html`` from within the default Django
 admin template directory (``django/contrib/admin/templates``) into an ``admin``
 subdirectory of whichever directory you're using in ``TEMPLATE_DIRS``. For
-example, if your ``TEMPLATE_DIRS`` includes ``"/home/mytemplates"``, as above,
-then copy ``django/contrib/admin/templates/admin/base_site.html`` to
-``/home/mytemplates/admin/base_site.html``. Don't forget that ``admin``
-subdirectory.
+example, if your ``TEMPLATE_DIRS`` includes ``"/home/my_username/mytemplates"``,
+as above, then copy ``django/contrib/admin/templates/admin/base_site.html`` to
+``/home/my_username/mytemplates/admin/base_site.html``. Don't forget that
+``admin`` subdirectory.
 
 Then, just edit the file and replace the generic Django text with your own
 site's name and URL as you see fit.
diff --git a/docs/tutorial04.txt b/docs/tutorial04.txt
index c5e2ea3cea..49ed649cff 100644
--- a/docs/tutorial04.txt
+++ b/docs/tutorial04.txt
@@ -192,13 +192,13 @@ objects" and "display a detail page for a particular type of object."
       ``object_id`` for the generic views.
 
 By default, the ``object_detail`` generic view uses a template called
-``<app name>/<module name>_detail.html``. In our case, it'll use the template
+``<app name>/<model name>_detail.html``. In our case, it'll use the template
 ``"polls/poll_detail.html"``. Thus, rename your ``polls/detail.html`` template to
 ``polls/poll_detail.html``, and change the ``render_to_response()`` line in
 ``vote()``.
 
 Similarly, the ``object_list`` generic view uses a template called
-``<app name>/<module name>_list.html``. Thus, rename ``polls/index.html`` to
+``<app name>/<model name>_list.html``. Thus, rename ``polls/index.html`` to
 ``polls/poll_list.html``.
 
 Because we have more than one entry in the URLconf that uses ``object_detail``