newforms-admin: Merged to [4616]

git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@4617 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/generic_views.txt

@@ -686,7 +686,7 @@ A page representing a list of objects.
     * ``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
+      query string parameter (via ``GET``) containing a 1-based page
       number, or a ``page`` variable specified in the URLconf. See
       "Notes on pagination" below.
 
@@ -752,6 +752,12 @@ If the results are paginated, the context will contain these extra variables:
 
     * ``previous``: The previous page number, as an integer. This is 1-based.
 
+    * `last_on_page`: **New in Django development version** The number of the
+      last result on the current page. This is 1-based.
+
+    * `first_on_page`: **New in Django development version** The number of the
+      first result on the current page. This is 1-based.
+
     * ``pages``: The total number of pages, as an integer.
 
     * ``hits``: The total number of objects across *all* pages, not just this

docs/model-api.txt

@@ -1295,10 +1295,30 @@ A few special cases to note about ``list_display``:
 
           list_display = ('__str__', 'some_other_field')
 
-    * For any element of ``list_display`` that is not a field on the model, the
-      change list page will not allow ordering by that column. This is because
-      ordering is done at the database level, and Django has no way of knowing
-      how to order the result of a custom method at the SQL level.
+    * Usually, elements of ``list_display`` that aren't actual database fields
+      can't be used in sorting (because Django does all the sorting at the
+      database level).
+      
+      However, if an element of ``list_display`` represents a certain database
+      field, you can indicate this fact by setting the ``admin_order_field``
+      attribute of the item.
+      
+      For example::
+      
+        class Person(models.Model):
+            first_name = models.CharField(maxlength=50)
+            color_code = models.CharField(maxlength=6)
+
+            class Admin:
+                list_display = ('first_name', 'colored_first_name')
+
+            def colored_first_name(self):
+                return '<span style="color: #%s;">%s</span>' % (self.color_code, self.first_name)
+            colored_first_name.allow_tags = True
+            colored_first_name.admin_order_field = 'first_name'
+    
+      The above will tell Django to order by the ``first_name`` field when
+      trying to sort by ``colored_first_name`` in the admin.
 
 ``list_display_links``
 ----------------------

docs/testing.txt

@@ -417,7 +417,10 @@ failed::
 
     FAILED (failures=1)
 
-When the tests have all been executed, the test database is destroyed.
+The return code for the script will indicate the number of tests that failed.
+
+Regardless of whether the tests pass or fail, the test database is destroyed when
+all the tests have been executed. 
 
 Using a different testing framework
 ===================================
@@ -428,7 +431,8 @@ it does provide a mechanism to allow you to invoke tests constructed for
 an alternative framework as if they were normal Django tests.
 
 When you run ``./manage.py test``, Django looks at the ``TEST_RUNNER``
-setting to determine what to do. By default, ``TEST_RUNNER`` points to ``django.test.simple.run_tests``. This method defines the default Django
+setting to determine what to do. By default, ``TEST_RUNNER`` points to 
+``django.test.simple.run_tests``. This method defines the default Django
 testing behavior. This behavior involves:
 
 #. Performing global pre-test setup
@@ -436,7 +440,7 @@ testing behavior. This behavior involves:
 #. Running ``syncdb`` to install models and initial data into the test database
 #. Looking for Unit Tests and Doctests in ``models.py`` and ``tests.py`` file for each installed application
 #. Running the Unit Tests and Doctests that are found
-#. Destroying the test database.
+#. Destroying the test database
 #. Performing global post-test teardown
 
 If you define your own test runner method and point ``TEST_RUNNER``
@@ -457,6 +461,8 @@ arguments:
     Verbosity determines the amount of notification and debug information that
     will be printed to the console; `0` is no output, `1` is normal output,
     and `2` is verbose output.
+    
+    This method should return the number of tests that failed.
 
 Testing utilities
 -----------------

docs/tutorial01.txt

@@ -19,6 +19,15 @@ installed.
 
 .. _`Django installed`: ../install/
 
+.. admonition:: Where to get help:
+
+    If you're having trouble going through this tutorial, please post a message
+    to `django-users`_ or drop by `#django`_ on ``irc.freenode.net`` and we'll 
+    try to help.
+
+.. _django-users: http://groups.google.com/group/django-users 
+.. _#django: irc://irc.freenode.net/django
+
 Creating a project
 ==================