diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/generic_views.txt | 8 | ||||
| -rw-r--r-- | docs/model-api.txt | 28 | ||||
| -rw-r--r-- | docs/testing.txt | 12 | ||||
| -rw-r--r-- | docs/tutorial01.txt | 9 |
4 files changed, 49 insertions, 8 deletions
diff --git a/docs/generic_views.txt b/docs/generic_views.txt index 23f40acb24..a136c72a07 100644 --- a/docs/generic_views.txt +++ b/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 diff --git a/docs/model-api.txt b/docs/model-api.txt index 0a10918d54..9f87d53719 100644 --- a/docs/model-api.txt +++ b/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`` ---------------------- diff --git a/docs/testing.txt b/docs/testing.txt index 33014723cd..57e50f483d 100644 --- a/docs/testing.txt +++ b/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 ----------------- diff --git a/docs/tutorial01.txt b/docs/tutorial01.txt index 1b241f728a..d47dd4a19d 100644 --- a/docs/tutorial01.txt +++ b/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 ================== |