sqlalchemy: Merged revisions 4054 to 4185 from trunk.

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

8 files changed, 112 insertions, 15 deletions

diff --git a/docs/add_ons.txt b/docs/add_ons.txt
index a0377700d7..58c01c4fc0 100644
--- a/docs/add_ons.txt
+++ b/docs/add_ons.txt
@@ -48,6 +48,23 @@ See the `csrf documentation`_.
 
 .. _csrf documentation: http://www.djangoproject.com/documentation/csrf/
 
+formtools
+=========
+
+**New in Django development version**
+
+A set of high-level abstractions for Django forms (django.newforms).
+
+django.contrib.formtools.preview
+--------------------------------
+
+An abstraction of the following workflow:
+
+"Display an HTML form, force a preview, then do something with the submission."
+
+Full documentation for this feature does not yet exist, but you can read the
+code and docstrings in ``django/contrib/formtools/preview.py`` for a start.
+
 humanize
 ========
 
diff --git a/docs/newforms.txt b/docs/newforms.txt
new file mode 100644
index 0000000000..9bfbc75ee7
--- /dev/null
+++ b/docs/newforms.txt
@@ -0,0 +1,79 @@
+====================
+The newforms library
+====================
+
+``django.newforms`` is a new replacement for ``django.forms``, the old Django
+form/manipulator/validation framework. This document explains how to use this
+new form library.
+
+Migration plan
+==============
+
+``django.newforms`` currently is only available in the Django development version
+-- i.e., it's not available in the Django 0.95 release. For the next Django
+release, our plan is to do the following:
+
+    * Move the current ``django.forms`` to ``django.oldforms``. This will allow
+      for an eased migration of form code. You'll just have to change your
+      import statements::
+
+          from django import forms             # old
+          from django import oldforms as forms # new
+
+    * Move the current ``django.newforms`` to ``django.forms``.
+
+    * We will remove ``django.oldforms`` in the release *after* the next Django
+      release -- the release that comes after the release in which we're
+      creating ``django.oldforms``.
+
+With this in mind, we recommend you use the following import statement when
+using ``django.newforms``::
+
+    from django import newforms as forms
+
+This way, your code can refer to the ``forms`` module, and when
+``django.newforms`` is renamed to ``django.forms``, you'll only have to change
+your ``import`` statements.
+
+If you prefer "``import *``" syntax, you can do the following::
+
+    from django.newforms import *
+
+This will import all fields, widgets, form classes and other various utilities
+into your local namespace. Some people find this convenient; others find it
+too messy. The choice is yours.
+
+Overview
+========
+
+As the ``django.forms`` system before it, ``django.newforms`` is intended to
+handle HTML form display, validation and redisplay. It's what you use if you
+want to perform server-side validation for an HTML form.
+
+The library deals with these concepts:
+
+    * **Widget** -- A class that corresponds to an HTML form widget, e.g.
+      ``<input type="text">`` or ``<textarea>``. This handles rendering of the
+      widget as HTML.
+
+    * **Field** -- A class that is responsible for doing validation, e.g.
+      an ``EmailField`` that makes sure its data is a valid e-mail address.
+
+    * **Form** -- A collection of fields that knows how to validate itself and
+      display itself as HTML.
+
+
+
+Using forms with templates
+==========================
+
+Using forms in views
+====================
+
+More coming soon
+================
+
+That's all the documentation for now. For more, see the file
+http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py
+-- the unit tests for ``django.newforms``. This can give you a good idea of
+what's possible.
diff --git a/docs/sessions.txt b/docs/sessions.txt
index d39f42c3bf..dd4a581d91 100644
--- a/docs/sessions.txt
+++ b/docs/sessions.txt
@@ -141,7 +141,7 @@ Do this after you've verified that the test cookie worked.
 Here's a typical usage example::
 
     def login(request):
-        if request.POST:
+        if request.method == 'POST':
             if request.session.test_cookie_worked():
                 request.session.delete_test_cookie()
                 return HttpResponse("You're logged in.")
diff --git a/docs/settings.txt b/docs/settings.txt
index ff1e2eeca2..00672060db 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -830,7 +830,7 @@ 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
+.. _URLField: ../model_api/#urlfield
 
 USE_ETAGS
 ---------
diff --git a/docs/sitemaps.txt b/docs/sitemaps.txt
index fec65572f2..7414567b16 100644
--- a/docs/sitemaps.txt
+++ b/docs/sitemaps.txt
@@ -5,9 +5,9 @@ The sitemap framework
 **New in Django development version**.
 
 Django comes with a high-level sitemap-generating framework that makes
-creating `Google Sitemap`_ XML files easy.
+creating sitemap_ XML files easy.
 
-.. _Google Sitemap: http://www.google.com/webmasters/sitemaps/docs/en/protocol.html
+.. _sitemap: http://www.sitemaps.org/
 
 Overview
 ========
@@ -55,11 +55,12 @@ URLconf_:
 
 This tells Django to build a sitemap when a client accesses ``/sitemap.xml``.
 
-The name of the sitemap file is not important, but the location is. Google will
-only index links in your sitemap for the current URL level and below. For
-instance, if ``sitemap.xml`` lives in your root directory, it may reference any
-URL in your site. However, if your sitemap lives at ``/content/sitemap.xml``,
-it may only reference URLs that begin with ``/content/``.
+The name of the sitemap file is not important, but the location is. Search
+engines will only index links in your sitemap for the current URL level and
+below. For instance, if ``sitemap.xml`` lives in your root directory, it may
+reference any URL in your site. However, if your sitemap lives at
+``/content/sitemap.xml``, it may only reference URLs that begin with
+``/content/``.
 
 The sitemap view takes an extra, required argument: ``{'sitemaps': sitemaps}``.
 ``sitemaps`` should be a dictionary that maps a short section label (e.g.,
@@ -199,9 +200,9 @@ If it's an attribute, its value should be either a string or float representing
 the priority of *every* object returned by ``items()``.
 
 Example values for ``priority``: ``0.4``, ``1.0``. The default priority of a
-page is ``0.5``. See Google's documentation for more documentation.
+page is ``0.5``. See the `sitemaps.org documentation`_ for more.
 
-.. _Google's documentation: http://www.google.com/webmasters/sitemaps/docs/en/protocol.html
+.. _sitemaps.org documentation: http://www.sitemaps.org/protocol.html#prioritydef
 
 Shortcuts
 =========
diff --git a/docs/templates.txt b/docs/templates.txt
index 7a580bd0db..b4cc47b9f3 100644
--- a/docs/templates.txt
+++ b/docs/templates.txt
@@ -571,7 +571,7 @@ The arguments can be hard-coded strings, so the following is valid::
 It is only possible to compare an argument to template variables or strings.
 You cannot check for equality with Python objects such as ``True`` or
 ``False``.  If you need to test if something is true or false, use the ``if``
-and ``ifnot`` tags instead.
+tag instead.
 
 ifnotequal
 ~~~~~~~~~~
diff --git a/docs/templates_python.txt b/docs/templates_python.txt
index ae2582d7b8..7aeed935b9 100644
--- a/docs/templates_python.txt
+++ b/docs/templates_python.txt
@@ -321,7 +321,7 @@ Note::
 
         def some_view(request):
             # ...
-            return render_to_response('my_template'html',
+            return render_to_response('my_template.html',
                                       my_data_dictionary,
                                       context_instance=RequestContext(request))
 
diff --git a/docs/testing.txt b/docs/testing.txt
index 19eef9f071..a0b8a8a187 100644
--- a/docs/testing.txt
+++ b/docs/testing.txt
@@ -10,7 +10,7 @@ used to validate that code behaves as expected. When refactoring or
 modifying code, tests serve as a guide to ensure that behavior hasn't
 changed unexpectedly as a result of the refactor.
 
-Testing an web application is a complex task, as there are many
+Testing a web application is a complex task, as there are many
 components of a web application that must be validated and tested. To
 help you test your application, Django provides a test execution
 framework, and range of utilities that can be used to stimulate and
@@ -133,7 +133,7 @@ together, picking the test system to match the type of tests you need to
 write.
 
 For developers new to testing, however, this choice can seem
-confusing, so here are a few key differences to help you decide weather
+confusing, so here are a few key differences to help you decide whether
 doctests or unit tests are right for you.
 
 If you've been using Python for a while, ``doctest`` will probably feel more