-
diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt
|
a
|
b
|
|
| 2 | 2 | Writing custom django-admin commands |
| 3 | 3 | ==================================== |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.0 |
| 6 | | |
| 7 | 5 | Applications can register their own actions with ``manage.py``. For example, |
| 8 | 6 | you might want to add a ``manage.py`` action for a Django app that you're |
| 9 | 7 | distributing. In this document, we will be building a custom ``closepoll`` |
-
diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt
|
a
|
b
|
|
| 2 | 2 | Writing custom model fields |
| 3 | 3 | =========================== |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.0 |
| 6 | 5 | .. currentmodule:: django.db.models |
| 7 | 6 | |
| 8 | 7 | Introduction |
-
diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt
|
a
|
b
|
|
| 155 | 155 | Filters and auto-escaping |
| 156 | 156 | ~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 157 | 157 | |
| 158 | | .. versionadded:: 1.0 |
| 159 | | |
| 160 | 158 | When writing a custom filter, give some thought to how the filter will interact |
| 161 | 159 | with Django's auto-escaping behavior. Note that three types of strings can be |
| 162 | 160 | passed around inside the template code: |
| … |
… |
|
| 426 | 424 | Auto-escaping considerations |
| 427 | 425 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 428 | 426 | |
| 429 | | .. versionadded:: 1.0 |
| 430 | | |
| 431 | 427 | The output from template tags is **not** automatically run through the |
| 432 | 428 | auto-escaping filters. However, there are still a couple of things you should |
| 433 | 429 | keep in mind when writing a template tag. |
| … |
… |
|
| 605 | 601 | raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name |
| 606 | 602 | return FormatTimeNode(date_to_be_formatted, format_string[1:-1]) |
| 607 | 603 | |
| 608 | | .. versionchanged:: 1.0 |
| 609 | | Variable resolution has changed in the 1.0 release of Django. ``template.resolve_variable()`` |
| 610 | | has been deprecated in favor of a new ``template.Variable`` class. |
| 611 | | |
| 612 | 604 | You also have to change the renderer to retrieve the actual contents of the |
| 613 | 605 | ``date_updated`` property of the ``blog_entry`` object. This can be |
| 614 | 606 | accomplished by using the ``Variable()`` class in ``django.template``. |
-
diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt
|
a
|
b
|
|
| 63 | 63 | Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE |
| 64 | 64 | <django-settings-module>` so mod_python knows which settings to use. |
| 65 | 65 | |
| 66 | | .. versionadded:: 1.0 |
| 67 | | The ``PythonOption django.root ...`` is new in this version. |
| 68 | | |
| 69 | 66 | Because mod_python does not know we are serving this site from underneath the |
| 70 | 67 | ``/mysite/`` prefix, this value needs to be passed through to the mod_python |
| 71 | 68 | handler in Django, via the ``PythonOption django.root ...`` line. The value set |
-
diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt
|
a
|
b
|
|
| 38 | 38 | need to know is that it maps URL roots to applications. In the end, you |
| 39 | 39 | should have a ``urls.py`` file that looks like this: |
| 40 | 40 | |
| 41 | | .. versionchanged:: 1.1 |
| 42 | | The method for adding admin urls has changed in Django 1.1. |
| 43 | | |
| 44 | 41 | .. parsed-literal:: |
| 45 | 42 | |
| 46 | 43 | from django.conf.urls.defaults import * |
-
diff --git a/docs/ref/authbackends.txt b/docs/ref/authbackends.txt
|
a
|
b
|
|
| 26 | 26 | |
| 27 | 27 | .. class:: RemoteUserBackend |
| 28 | 28 | |
| 29 | | .. versionadded:: 1.1 |
| 30 | | |
| 31 | 29 | Use this backend to take advantage of external-to-Django-handled |
| 32 | 30 | authentication. It authenticates using usernames passed in |
| 33 | 31 | :attr:`request.META['REMOTE_USER'] <django.http.HttpRequest.META>`. See |
-
diff --git a/docs/ref/contrib/admin/actions.txt b/docs/ref/contrib/admin/actions.txt
|
a
|
b
|
|
| 2 | 2 | Admin actions |
| 3 | 3 | ============= |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.1 |
| 6 | | |
| 7 | 5 | .. currentmodule:: django.contrib.admin |
| 8 | 6 | |
| 9 | 7 | The basic workflow of Django's admin is, in a nutshell, "select an object, |
-
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
|
a
|
b
|
|
| 423 | 423 | |
| 424 | 424 | .. attribute:: ModelAdmin.list_editable |
| 425 | 425 | |
| 426 | | .. versionadded:: 1.1 |
| 427 | | |
| 428 | 426 | Set ``list_editable`` to a list of field names on the model which will allow |
| 429 | 427 | editing on the change list page. That is, fields listed in ``list_editable`` |
| 430 | 428 | will be displayed as form widgets on the change list page, allowing users to |
| … |
… |
|
| 647 | 645 | |
| 648 | 646 | .. attribute:: ModelAdmin.formfield_overrides |
| 649 | 647 | |
| 650 | | .. versionadded:: 1.1 |
| 651 | | |
| 652 | 648 | This provides a quick-and-dirty way to override some of the |
| 653 | 649 | :class:`~django.forms.Field` options for use in the admin. |
| 654 | 650 | ``formfield_overrides`` is a dictionary mapping a field class to a dict of |
| … |
… |
|
| 689 | 685 | |
| 690 | 686 | .. attribute:: ModelAdmin.actions |
| 691 | 687 | |
| 692 | | .. versionadded:: 1.1 |
| 693 | | |
| 694 | 688 | A list of actions to make available on the change list page. See |
| 695 | 689 | :doc:`/ref/contrib/admin/actions` for details. |
| 696 | 690 | |
| 697 | 691 | .. attribute:: ModelAdmin.actions_on_top |
| 698 | 692 | .. attribute:: ModelAdmin.actions_on_bottom |
| 699 | 693 | |
| 700 | | .. versionadded:: 1.1 |
| 701 | | |
| 702 | 694 | Controls where on the page the actions bar appears. By default, the admin |
| 703 | 695 | changelist displays actions at the top of the page (``actions_on_top = True; |
| 704 | 696 | actions_on_bottom = False``). |
| … |
… |
|
| 797 | 789 | |
| 798 | 790 | .. method:: ModelAdmin.get_urls(self) |
| 799 | 791 | |
| 800 | | .. versionadded:: 1.1 |
| 801 | | |
| 802 | 792 | The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for |
| 803 | 793 | that ModelAdmin in the same way as a URLconf. Therefore you can extend them as |
| 804 | 794 | documented in :doc:`/topics/http/urls`:: |
| … |
… |
|
| 855 | 845 | |
| 856 | 846 | .. method:: ModelAdmin.formfield_for_foreignkey(self, db_field, request, **kwargs) |
| 857 | 847 | |
| 858 | | .. versionadded:: 1.1 |
| 859 | | |
| 860 | 848 | The ``formfield_for_foreignkey`` method on a ``ModelAdmin`` allows you to |
| 861 | 849 | override the default formfield for a foreign key field. For example, to |
| 862 | 850 | return a subset of objects for this foreign key field based on the user:: |
| … |
… |
|
| 872 | 860 | |
| 873 | 861 | .. method:: ModelAdmin.formfield_for_manytomany(self, db_field, request, **kwargs) |
| 874 | 862 | |
| 875 | | .. versionadded:: 1.1 |
| 876 | | |
| 877 | 863 | Like the ``formfield_for_foreignkey`` method, the ``formfield_for_manytomany`` |
| 878 | 864 | method can be overridden to change the default formfield for a many to many |
| 879 | 865 | field. For example, if an owner can own multiple cars and cars can belong |
| … |
… |
|
| 1418 | 1404 | Python class), and register your models and ``ModelAdmin`` subclasses |
| 1419 | 1405 | with it instead of using the default. |
| 1420 | 1406 | |
| 1421 | | .. versionadded:: 1.1 |
| 1422 | | |
| 1423 | 1407 | When constructing an instance of an ``AdminSite``, you are able to provide |
| 1424 | 1408 | a unique instance name using the ``name`` argument to the constructor. This |
| 1425 | 1409 | instance name is used to identify the instance, especially when |
| … |
… |
|
| 1505 | 1489 | Django-powered Web site. Just create multiple instances of ``AdminSite`` and |
| 1506 | 1490 | root each one at a different URL. |
| 1507 | 1491 | |
| 1508 | | .. versionchanged:: 1.1 |
| 1509 | | The method for hooking ``AdminSite`` instances into urls has changed in |
| 1510 | | Django 1.1. |
| 1511 | | |
| 1512 | 1492 | In this example, the URLs ``/basic-admin/`` and ``/advanced-admin/`` feature |
| 1513 | 1493 | separate versions of the admin site -- using the ``AdminSite`` instances |
| 1514 | 1494 | ``myproject.admin.basic_site`` and ``myproject.admin.advanced_site``, |
| … |
… |
|
| 1531 | 1511 | Adding views to admin sites |
| 1532 | 1512 | --------------------------- |
| 1533 | 1513 | |
| 1534 | | .. versionadded:: 1.1 |
| 1535 | | |
| 1536 | 1514 | Just like :class:`ModelAdmin`, :class:`AdminSite` provides a |
| 1537 | 1515 | :meth:`~django.contrib.admin.ModelAdmin.get_urls()` method |
| 1538 | 1516 | that can be overridden to define additional views for the site. To add |
| … |
… |
|
| 1552 | 1530 | Reversing Admin URLs |
| 1553 | 1531 | ==================== |
| 1554 | 1532 | |
| 1555 | | .. versionadded:: 1.1 |
| 1556 | | |
| 1557 | 1533 | When an :class:`AdminSite` is deployed, the views provided by that site are |
| 1558 | 1534 | accessible using Django's :ref:`URL reversing system <naming-url-patterns>`. |
| 1559 | 1535 | |
-
diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
|
a
|
b
|
|
| 241 | 241 | Exceptions |
| 242 | 242 | ---------- |
| 243 | 243 | |
| 244 | | .. versionadded:: 1.1 |
| 245 | 244 | .. versionchanged:: 1.2 |
| 246 | 245 | Import paths for the decorators below were changed. |
| 247 | 246 | |
-
diff --git a/docs/ref/contrib/flatpages.txt b/docs/ref/contrib/flatpages.txt
|
a
|
b
|
|
| 17 | 17 | A flatpage can use a custom template or a default, systemwide flatpage |
| 18 | 18 | template. It can be associated with one, or multiple, sites. |
| 19 | 19 | |
| 20 | | .. versionadded:: 1.0 |
| 21 | | |
| 22 | 20 | The content field may optionally be left blank if you prefer to put your |
| 23 | 21 | content in a custom template. |
| 24 | 22 | |
-
diff --git a/docs/ref/contrib/formtools/form-wizard.txt b/docs/ref/contrib/formtools/form-wizard.txt
|
a
|
b
|
|
| 5 | 5 | .. module:: django.contrib.formtools.wizard |
| 6 | 6 | :synopsis: Splits forms across multiple Web pages. |
| 7 | 7 | |
| 8 | | .. versionadded:: 1.0 |
| 9 | | |
| 10 | 8 | Django comes with an optional "form wizard" application that splits |
| 11 | 9 | :doc:`forms </topics/forms/index>` across multiple Web pages. It maintains |
| 12 | 10 | state in hashed HTML :samp:`<input type="hidden">` fields, and the data isn't |
-
diff --git a/docs/ref/contrib/gis/gdal.txt b/docs/ref/contrib/gis/gdal.txt
|
a
|
b
|
|
| 459 | 459 | |
| 460 | 460 | .. classmethod:: from_bbox(bbox) |
| 461 | 461 | |
| 462 | | .. versionadded:: 1.1 |
| 463 | | |
| 464 | 462 | Constructs a :class:`Polygon` from the given bounding-box (a 4-tuple). |
| 465 | 463 | |
| 466 | 464 | .. method:: __len__ |
| … |
… |
|
| 601 | 599 | |
| 602 | 600 | .. attribute:: kml |
| 603 | 601 | |
| 604 | | .. versionadded:: 1.1 |
| 605 | | |
| 606 | 602 | Returns a string representation of this geometry in KML format. |
| 607 | 603 | |
| 608 | 604 | .. attribute:: wkb_size |
| … |
… |
|
| 889 | 885 | |
| 890 | 886 | .. method:: expand_to_include(self, *args) |
| 891 | 887 | |
| 892 | | .. versionadded:: 1.1 |
| 893 | | |
| 894 | 888 | Coordinate System Objects |
| 895 | 889 | ========================= |
| 896 | 890 | |
| … |
… |
|
| 992 | 986 | Import spatial reference from PROJ.4 string. |
| 993 | 987 | |
| 994 | 988 | .. method:: import_user_input(user_input) |
| 995 | | |
| 996 | | .. versionadded:: 1.1 |
| 997 | 989 | |
| 998 | 990 | .. method:: import_wkt(wkt) |
| 999 | 991 | |
-
diff --git a/docs/ref/contrib/gis/geoquerysets.txt b/docs/ref/contrib/gis/geoquerysets.txt
|
a
|
b
|
|
| 835 | 835 | |
| 836 | 836 | .. method:: GeoQuerySet.snap_to_grid(*args, **kwargs) |
| 837 | 837 | |
| 838 | | .. versionadded:: 1.1 |
| 839 | | |
| 840 | 838 | Snap all points of the input geometry to the grid. How the |
| 841 | 839 | geometry is snapped to the grid depends on how many numeric |
| 842 | 840 | (either float, integer, or long) arguments are given. |
| … |
… |
|
| 957 | 955 | |
| 958 | 956 | .. method:: GeoQuerySet.geojson(**kwargs) |
| 959 | 957 | |
| 960 | | .. versionadded:: 1.1 |
| 961 | | |
| 962 | 958 | *Availability*: PostGIS |
| 963 | 959 | |
| 964 | 960 | Attaches a ``geojson`` attribute to every model in the queryset that contains the |
| … |
… |
|
| 1102 | 1098 | |
| 1103 | 1099 | Spatial Aggregates |
| 1104 | 1100 | ================== |
| 1105 | | .. versionadded:: 1.1 |
| 1106 | 1101 | |
| 1107 | 1102 | Aggregate Methods |
| 1108 | 1103 | ----------------- |
| … |
… |
|
| 1112 | 1107 | |
| 1113 | 1108 | .. method:: GeoQuerySet.collect(**kwargs) |
| 1114 | 1109 | |
| 1115 | | .. versionadded:: 1.1 |
| 1116 | | |
| 1117 | 1110 | *Availability*: PostGIS |
| 1118 | 1111 | |
| 1119 | 1112 | Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry |
-
diff --git a/docs/ref/contrib/gis/geos.txt b/docs/ref/contrib/gis/geos.txt
|
a
|
b
|
|
| 497 | 497 | |
| 498 | 498 | .. attribute:: GEOSGeometry.prepared |
| 499 | 499 | |
| 500 | | .. versionadded:: 1.1 |
| 501 | | |
| 502 | 500 | .. note:: |
| 503 | 501 | |
| 504 | 502 | Support for prepared geometries requires GEOS 3.1. |
| … |
… |
|
| 593 | 591 | |
| 594 | 592 | .. classmethod:: from_bbox(bbox) |
| 595 | 593 | |
| 596 | | .. versionadded:: 1.1 |
| 597 | | |
| 598 | 594 | Returns a polygon object from the given bounding-box, a 4-tuple |
| 599 | 595 | comprising (xmin, ymin, xmax, ymax). |
| 600 | 596 | |
| … |
… |
|
| 633 | 629 | |
| 634 | 630 | .. attribute:: merged |
| 635 | 631 | |
| 636 | | .. versionadded:: 1.1 |
| 637 | | |
| 638 | 632 | Returns a :class:`LineString` representing the line merge of |
| 639 | 633 | all the components in this ``MultiLineString``. |
| 640 | 634 | |
| … |
… |
|
| 655 | 649 | |
| 656 | 650 | .. attribute:: cascaded_union |
| 657 | 651 | |
| 658 | | .. versionadded:: 1.1 |
| 659 | | |
| 660 | 652 | Returns a :class:`Polygon` that is the union of all of the component |
| 661 | 653 | polygons in this collection. The algorithm employed is significantly |
| 662 | 654 | more efficient (faster) than trying to union the geometries together |
-
diff --git a/docs/ref/contrib/gis/index.txt b/docs/ref/contrib/gis/index.txt
|
a
|
b
|
|
| 4 | 4 | GeoDjango |
| 5 | 5 | ========= |
| 6 | 6 | |
| 7 | | .. versionadded:: 1.0 |
| 8 | | |
| 9 | 7 | .. module:: django.contrib.gis |
| 10 | 8 | :synopsis: Geographic Information System (GIS) extensions for Django |
| 11 | 9 | |
-
diff --git a/docs/ref/contrib/gis/install.txt b/docs/ref/contrib/gis/install.txt
|
a
|
b
|
|
| 356 | 356 | |
| 357 | 357 | SpatiaLite |
| 358 | 358 | ---------- |
| 359 | | .. versionadded:: 1.1 |
| 360 | 359 | |
| 361 | 360 | .. note:: |
| 362 | 361 | |
-
diff --git a/docs/ref/contrib/gis/testing.txt b/docs/ref/contrib/gis/testing.txt
|
a
|
b
|
|
| 33 | 33 | ``POSTGIS_TEMPLATE`` |
| 34 | 34 | ^^^^^^^^^^^^^^^^^^^^ |
| 35 | 35 | |
| 36 | | .. versionadded:: 1.1 |
| 37 | | |
| 38 | 36 | .. versionchanged:: 1.2 |
| 39 | 37 | |
| 40 | 38 | This setting may be used to customize the name of the PostGIS template |
| … |
… |
|
| 53 | 51 | |
| 54 | 52 | ``POSTGIS_VERSION`` |
| 55 | 53 | ^^^^^^^^^^^^^^^^^^^ |
| 56 | | .. versionadded:: 1.1 |
| 57 | 54 | |
| 58 | 55 | When GeoDjango's spatial backend initializes on PostGIS, it has to perform |
| 59 | 56 | a SQL query to determine the version. Setting the version manually |
| … |
… |
|
| 123 | 120 | SpatiaLite |
| 124 | 121 | ========== |
| 125 | 122 | |
| 126 | | .. versionadded:: 1.1 |
| 127 | | |
| 128 | 123 | You will need to download the `initialization SQL`__ script for SpatiaLite:: |
| 129 | 124 | |
| 130 | 125 | $ wget http://www.gaia-gis.it/spatialite/init_spatialite-2.3.zip |
| … |
… |
|
| 142 | 137 | |
| 143 | 138 | ``SPATIALITE_SQL`` |
| 144 | 139 | ^^^^^^^^^^^^^^^^^^ |
| 145 | | .. versionadded:: 1.1 |
| 146 | 140 | |
| 147 | 141 | By default, the GeoDjango test runner looks for the SpatiaLite SQL in the |
| 148 | 142 | same directory where it was invoked (by default the same directory where |
-
diff --git a/docs/ref/contrib/humanize.txt b/docs/ref/contrib/humanize.txt
|
a
|
b
|
|
| 72 | 72 | naturalday |
| 73 | 73 | ---------- |
| 74 | 74 | |
| 75 | | .. versionadded:: 1.0 |
| 76 | | |
| 77 | 75 | For dates that are the current day or within one day, return "today", |
| 78 | 76 | "tomorrow" or "yesterday", as appropriate. Otherwise, format the date using |
| 79 | 77 | the passed in format string. |
-
diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt
|
a
|
b
|
|
| 60 | 60 | comments |
| 61 | 61 | ======== |
| 62 | 62 | |
| 63 | | .. versionchanged:: 1.0 |
| 64 | | The comments application has been rewriten. See :doc:`/ref/contrib/comments/upgrade` |
| 65 | | for information on howto upgrade. |
| 66 | | |
| 67 | 63 | A simple yet flexible comments system. See :doc:`/ref/contrib/comments/index`. |
| 68 | 64 | |
| 69 | 65 | contenttypes |
-
diff --git a/docs/ref/contrib/sitemaps.txt b/docs/ref/contrib/sitemaps.txt
|
a
|
b
|
|
| 340 | 340 | Pinging Google via `manage.py` |
| 341 | 341 | ------------------------------ |
| 342 | 342 | |
| 343 | | .. versionadded:: 1.0 |
| 344 | | |
| 345 | 343 | Once the sitemaps application is added to your project, you may also |
| 346 | 344 | ping the Google server's through the command line manage.py interface:: |
| 347 | 345 | |
-
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
|
a
|
b
|
|
| 230 | 230 | Caching the current ``Site`` object |
| 231 | 231 | =================================== |
| 232 | 232 | |
| 233 | | .. versionadded:: 1.0 |
| 234 | | |
| 235 | 233 | As the current site is stored in the database, each call to |
| 236 | 234 | ``Site.objects.get_current()`` could result in a database query. But Django is a |
| 237 | 235 | little cleverer than that: on the first request, the current site is cached, and |
| … |
… |
|
| 385 | 383 | |
| 386 | 384 | .. _requestsite-objects: |
| 387 | 385 | |
| 388 | | .. versionadded:: 1.0 |
| 389 | | |
| 390 | 386 | Some :doc:`django.contrib </ref/contrib/index>` applications take advantage of |
| 391 | 387 | the sites framework but are architected in a way that doesn't *require* the |
| 392 | 388 | sites framework to be installed in your database. (Some people don't want to, or |
-
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
|
a
|
b
|
|
| 58 | 58 | Autocommit mode |
| 59 | 59 | ~~~~~~~~~~~~~~~ |
| 60 | 60 | |
| 61 | | .. versionadded:: 1.1 |
| 62 | | |
| 63 | 61 | If your application is particularly read-heavy and doesn't make many |
| 64 | 62 | database writes, the overhead of a constantly open transaction can |
| 65 | 63 | sometimes be noticeable. For those situations, if you're using the |
| … |
… |
|
| 101 | 99 | Indexes for ``varchar`` and ``text`` columns |
| 102 | 100 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 103 | 101 | |
| 104 | | .. versionadded:: 1.1.2 |
| 105 | | |
| 106 | 102 | When specifying ``db_index=True`` on your model fields, Django typically |
| 107 | 103 | outputs a single ``CREATE INDEX`` statement. However, if the database type |
| 108 | 104 | for the field is either ``varchar`` or ``text`` (e.g., used by ``CharField``, |
| … |
… |
|
| 452 | 448 | Using newer versions of the SQLite DB-API 2.0 driver |
| 453 | 449 | ---------------------------------------------------- |
| 454 | 450 | |
| 455 | | .. versionadded:: 1.1 |
| 456 | | |
| 457 | 451 | For versions of Python 2.5 or newer that include ``sqlite3`` in the standard |
| 458 | 452 | library Django will now use a ``pysqlite2`` interface in preference to |
| 459 | 453 | ``sqlite3`` if it finds one is available. |
| … |
… |
|
| 605 | 599 | field would also generate an index, but no tablespace for it is specified, so |
| 606 | 600 | it would be stored in the model tablespace ``tables`` by default. |
| 607 | 601 | |
| 608 | | .. versionadded:: 1.0 |
| 609 | | |
| 610 | 602 | Use the :setting:`DEFAULT_TABLESPACE` and :setting:`DEFAULT_INDEX_TABLESPACE` |
| 611 | 603 | settings to specify default values for the db_tablespace options. |
| 612 | 604 | These are useful for setting a tablespace for the built-in Django apps and |
-
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
|
a
|
b
|
|
| 88 | 88 | |
| 89 | 89 | .. django-admin:: cleanup |
| 90 | 90 | |
| 91 | | .. versionadded:: 1.0 |
| 92 | | |
| 93 | 91 | Can be run as a cronjob or directly to clean out old data from the database |
| 94 | 92 | (only expired sessions at the moment). |
| 95 | 93 | |
| … |
… |
|
| 98 | 96 | |
| 99 | 97 | .. django-admin:: compilemessages |
| 100 | 98 | |
| 101 | | .. versionchanged:: 1.0 |
| 102 | | Before 1.0 this was the "bin/compile-messages.py" command. |
| 103 | | |
| 104 | 99 | Compiles .po files created with ``makemessages`` to .mo files for use with |
| 105 | 100 | the builtin gettext support. See :doc:`/topics/i18n/index`. |
| 106 | 101 | |
| … |
… |
|
| 129 | 124 | |
| 130 | 125 | .. django-admin:: createsuperuser |
| 131 | 126 | |
| 132 | | .. versionadded:: 1.0 |
| 133 | | |
| 134 | 127 | Creates a superuser account (a user who has all permissions). This is |
| 135 | 128 | useful if you need to create an initial superuser account but did not |
| 136 | 129 | do so during ``syncdb``, or if you need to programmatically generate |
| … |
… |
|
| 226 | 219 | easy for humans to read, so you can use the ``--indent`` option to |
| 227 | 220 | pretty-print the output with a number of indentation spaces. |
| 228 | 221 | |
| 229 | | .. versionadded:: 1.0 |
| 230 | | |
| 231 | 222 | The :djadminopt:`--exclude` option may be provided to prevent specific |
| 232 | 223 | applications from being dumped. |
| 233 | 224 | |
| … |
… |
|
| 236 | 227 | The :djadminopt:`--exclude` option may also be provided to prevent specific |
| 237 | 228 | models (specified as in the form of ``appname.ModelName``) from being dumped. |
| 238 | 229 | |
| 239 | | .. versionadded:: 1.1 |
| 240 | | |
| 241 | 230 | In addition to specifying application names, you can provide a list of |
| 242 | 231 | individual models, in the form of ``appname.Model``. If you specify a model |
| 243 | 232 | name to ``dumpdata``, the dumped output will be restricted to that model, |
| … |
… |
|
| 436 | 425 | |
| 437 | 426 | .. django-admin:: makemessages |
| 438 | 427 | |
| 439 | | .. versionchanged:: 1.0 |
| 440 | | Before 1.0 this was the ``bin/make-messages.py`` command. |
| 441 | | |
| 442 | 428 | Runs over the entire source tree of the current directory and pulls out all |
| 443 | 429 | strings marked for translation. It creates (or updates) a message file in the |
| 444 | 430 | conf/locale (in the django tree) or locale (for project and application) |
| … |
… |
|
| 839 | 825 | |
| 840 | 826 | .. django-admin:: testserver |
| 841 | 827 | |
| 842 | | .. versionadded:: 1.0 |
| 843 | | |
| 844 | 828 | Runs a Django development server (as in ``runserver``) using data from the |
| 845 | 829 | given fixture(s). |
| 846 | 830 | |
-
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
|
a
|
b
|
|
| 195 | 195 | >>> f.cleaned_data |
| 196 | 196 | {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'} |
| 197 | 197 | |
| 198 | | .. versionchanged:: 1.0 |
| 199 | | The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases. |
| 200 | | |
| 201 | 198 | Note that any text-based field -- such as ``CharField`` or ``EmailField`` -- |
| 202 | 199 | always cleans the input into a Unicode string. We'll cover the encoding |
| 203 | 200 | implications later in this document. |
| … |
… |
|
| 667 | 664 | Binding uploaded files to a form |
| 668 | 665 | -------------------------------- |
| 669 | 666 | |
| 670 | | .. versionadded:: 1.0 |
| 671 | | |
| 672 | 667 | Dealing with forms that have ``FileField`` and ``ImageField`` fields |
| 673 | 668 | is a little more complicated than a normal form. |
| 674 | 669 | |
-
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
|
a
|
b
|
|
| 230 | 230 | ``error_messages`` |
| 231 | 231 | ~~~~~~~~~~~~~~~~~~ |
| 232 | 232 | |
| 233 | | .. versionadded:: 1.0 |
| 234 | | |
| 235 | 233 | .. attribute:: Field.error_messages |
| 236 | 234 | |
| 237 | 235 | The ``error_messages`` argument lets you override the default messages that the |
| … |
… |
|
| 303 | 301 | the field has ``required=True``. |
| 304 | 302 | * Error message keys: ``required`` |
| 305 | 303 | |
| 306 | | .. versionchanged:: 1.0 |
| 307 | | The empty value for a ``CheckboxInput`` (and hence the standard |
| 308 | | ``BooleanField``) has changed to return ``False`` instead of ``None`` in |
| 309 | | the Django 1.0. |
| 310 | | |
| 311 | 304 | .. note:: |
| 312 | 305 | |
| 313 | 306 | Since all ``Field`` subclasses have ``required=True`` by default, the |
| … |
… |
|
| 408 | 401 | '%B %d %Y', '%B %d, %Y', # 'October 25 2006', 'October 25, 2006' |
| 409 | 402 | '%d %B %Y', '%d %B, %Y', # '25 October 2006', '25 October, 2006' |
| 410 | 403 | |
| 411 | | .. versionchanged:: 1.1 |
| 412 | | The ``DateField`` previously used a ``TextInput`` widget by default. It now |
| 413 | | uses a ``DateInput`` widget. |
| 414 | | |
| 415 | 404 | ``DateTimeField`` |
| 416 | 405 | ~~~~~~~~~~~~~~~~~ |
| 417 | 406 | |
| … |
… |
|
| 443 | 432 | '%m/%d/%y %H:%M', # '10/25/06 14:30' |
| 444 | 433 | '%m/%d/%y', # '10/25/06' |
| 445 | 434 | |
| 446 | | .. versionchanged:: 1.0 |
| 447 | | The ``DateTimeField`` used to use a ``TextInput`` widget by default. This has now changed. |
| 448 | | |
| 449 | 435 | ``DecimalField`` |
| 450 | 436 | ~~~~~~~~~~~~~~~~ |
| 451 | 437 | |
| 452 | | .. versionadded:: 1.0 |
| 453 | | |
| 454 | 438 | .. class:: DecimalField(**kwargs) |
| 455 | 439 | |
| 456 | 440 | * Default widget: ``TextInput`` |
| … |
… |
|
| 503 | 487 | ``FileField`` |
| 504 | 488 | ~~~~~~~~~~~~~ |
| 505 | 489 | |
| 506 | | .. versionadded:: 1.0 |
| 507 | | |
| 508 | 490 | .. class:: FileField(**kwargs) |
| 509 | 491 | |
| 510 | 492 | * Default widget: ``FileInput`` |
| … |
… |
|
| 523 | 505 | ``FilePathField`` |
| 524 | 506 | ~~~~~~~~~~~~~~~~~ |
| 525 | 507 | |
| 526 | | .. versionadded:: 1.0 |
| 527 | | |
| 528 | 508 | .. class:: FilePathField(**kwargs) |
| 529 | 509 | |
| 530 | 510 | * Default widget: ``Select`` |
| … |
… |
|
| 569 | 549 | ``ImageField`` |
| 570 | 550 | ~~~~~~~~~~~~~~ |
| 571 | 551 | |
| 572 | | .. versionadded:: 1.0 |
| 573 | | |
| 574 | 552 | .. class:: ImageField(**kwargs) |
| 575 | 553 | |
| 576 | 554 | * Default widget: ``FileInput`` |
| … |
… |
|
| 834 | 812 | If no ``input_time_formats`` argument is provided, the default input formats |
| 835 | 813 | for ``TimeField`` are used. |
| 836 | 814 | |
| 837 | | .. versionchanged:: 1.1 |
| 838 | | The ``SplitDateTimeField`` previously used two ``TextInput`` widgets by |
| 839 | | default. The ``input_date_formats`` and ``input_time_formats`` arguments |
| 840 | | are also new. |
| 841 | | |
| 842 | 815 | Fields which handle relationships |
| 843 | 816 | --------------------------------- |
| 844 | 817 | |
-
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
|
a
|
b
|
|
| 48 | 48 | |
| 49 | 49 | .. class:: DateInput |
| 50 | 50 | |
| 51 | | .. versionadded:: 1.1 |
| 52 | | |
| 53 | 51 | Date input as a simple text box: ``<input type='text' ...>`` |
| 54 | 52 | |
| 55 | 53 | Takes one optional argument: |
| … |
… |
|
| 62 | 60 | |
| 63 | 61 | .. class:: DateTimeInput |
| 64 | 62 | |
| 65 | | .. versionadded:: 1.0 |
| 66 | | |
| 67 | 63 | Date/time input as a simple text box: ``<input type='text' ...>`` |
| 68 | 64 | |
| 69 | 65 | Takes one optional argument: |
| … |
… |
|
| 87 | 83 | |
| 88 | 84 | If no ``format`` argument is provided, the default format is ``'%H:%M:%S'``. |
| 89 | 85 | |
| 90 | | .. versionchanged:: 1.1 |
| 91 | | The ``format`` argument was not supported in Django 1.0. |
| 92 | | |
| 93 | 86 | .. class:: Textarea |
| 94 | 87 | |
| 95 | 88 | Text area: ``<textarea>...</textarea>`` |
| … |
… |
|
| 159 | 152 | Takes two optional arguments, ``date_format`` and ``time_format``, which |
| 160 | 153 | work just like the ``format`` argument for ``DateInput`` and ``TimeInput``. |
| 161 | 154 | |
| 162 | | .. versionchanged:: 1.1 |
| 163 | | The ``date_format`` and ``time_format`` arguments were not supported in Django 1.0. |
| 164 | | |
| 165 | 155 | .. class:: SelectDateWidget |
| 166 | 156 | |
| 167 | 157 | Wrapper around three select widgets: one each for month, day, and year. |
-
diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt
|
a
|
b
|
|
| 93 | 93 | to the URL. If ``False``, then the query string is discarded. By |
| 94 | 94 | default, ``query_string`` is ``False``. |
| 95 | 95 | |
| 96 | | .. versionadded:: 1.1 |
| 97 | | The ``permanent`` keyword argument is new in Django 1.1. |
| 98 | | |
| 99 | | |
| 100 | 96 | **Example:** |
| 101 | 97 | |
| 102 | 98 | This example issues a permanent redirect (HTTP status code 301) from |
| … |
… |
|
| 182 | 178 | specified in ``date_field`` is greater than the current date/time. By |
| 183 | 179 | default, this is ``False``. |
| 184 | 180 | |
| 185 | | .. versionadded:: 1.0 |
| 186 | | |
| 187 | 181 | * ``template_object_name``: Designates the name of the template variable |
| 188 | 182 | to use in the template context. By default, this is ``'latest'``. |
| 189 | 183 | |
| … |
… |
|
| 208 | 202 | ordered in reverse. This is equivalent to |
| 209 | 203 | ``queryset.dates(date_field, 'year')[::-1]``. |
| 210 | 204 | |
| 211 | | .. versionchanged:: 1.0 |
| 212 | | The behaviour depending on ``template_object_name`` is new in this version. |
| 213 | | |
| 214 | 205 | * ``latest``: The ``num_latest`` objects in the system, ordered descending |
| 215 | 206 | by ``date_field``. For example, if ``num_latest`` is ``10``, then |
| 216 | 207 | ``latest`` will be a list of the latest 10 objects in ``queryset``. |
| … |
… |
|
| 380 | 371 | |
| 381 | 372 | * ``date_list``: A list of ``datetime.date`` objects representing all |
| 382 | 373 | days that have objects available in the given month, according to |
| 383 | | ``queryset``, in ascending order. |
| | 374 | ``queryset``, in ascending order. |
| 384 | 375 | |
| 385 | 376 | * ``month``: A ``datetime.date`` object representing the given month. |
| 386 | 377 | |
| … |
… |
|
| 727 | 718 | |
| 728 | 719 | **Template context:** |
| 729 | 720 | |
| 730 | | .. versionadded:: 1.0 |
| 731 | | The ``paginator`` and ``page_obj`` context variables are new. |
| 732 | | |
| 733 | 721 | In addition to ``extra_context``, the template's context will be: |
| 734 | 722 | |
| 735 | 723 | * ``object_list``: The list of objects. This variable's name depends on the |
| … |
… |
|
| 773 | 761 | For more on pagination, read the :doc:`pagination documentation |
| 774 | 762 | </topics/pagination>`. |
| 775 | 763 | |
| 776 | | .. versionadded:: 1.0 |
| 777 | | |
| 778 | 764 | As a special case, you are also permitted to use ``last`` as a value for |
| 779 | 765 | ``page``:: |
| 780 | 766 | |
| … |
… |
|
| 859 | 845 | The ``django.views.generic.create_update`` module contains a set of functions |
| 860 | 846 | for creating, editing and deleting objects. |
| 861 | 847 | |
| 862 | | .. versionchanged:: 1.0 |
| 863 | | |
| 864 | 848 | ``django.views.generic.create_update.create_object`` and |
| 865 | 849 | ``django.views.generic.create_update.update_object`` now use the new :doc:`forms |
| 866 | 850 | library </topics/forms/index>` to build and display the form. |
-
diff --git a/docs/ref/middleware.txt b/docs/ref/middleware.txt
|
a
|
b
|
|
| 52 | 52 | you don't have a valid URL pattern for ``foo.com/bar`` but *do* have a |
| 53 | 53 | valid pattern for ``foo.com/bar/``. |
| 54 | 54 | |
| 55 | | .. versionchanged:: 1.0 |
| 56 | | The behavior of :setting:`APPEND_SLASH` has changed slightly in this |
| 57 | | version. It didn't used to check whether the pattern was matched in |
| 58 | | the URLconf. |
| 59 | | |
| 60 | 55 | If :setting:`PREPEND_WWW` is ``True``, URLs that lack a leading "www." |
| 61 | 56 | will be redirected to the same URL with a leading "www." |
| 62 | 57 | |
| … |
… |
|
| 120 | 115 | |
| 121 | 116 | .. class:: django.middleware.http.SetRemoteAddrFromForwardedFor |
| 122 | 117 | |
| 123 | | .. versionchanged:: 1.1 |
| 124 | | |
| 125 | 118 | This middleware was removed in Django 1.1. See :ref:`the release notes |
| 126 | 119 | <removed-setremoteaddrfromforwardedfor-middleware>` for details. |
| 127 | 120 | |
| … |
… |
|
| 183 | 176 | |
| 184 | 177 | .. class:: django.middleware.csrf.CsrfMiddleware |
| 185 | 178 | |
| 186 | | .. versionadded:: 1.0 |
| 187 | | |
| 188 | 179 | Adds protection against Cross Site Request Forgeries by adding hidden form |
| 189 | 180 | fields to POST forms and checking requests for the correct value. See the |
| 190 | 181 | :doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`. |
-
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
|
a
|
b
|
|
| 171 | 171 | |
| 172 | 172 | .. attribute:: Field.db_tablespace |
| 173 | 173 | |
| 174 | | .. versionadded:: 1.0 |
| 175 | | |
| 176 | 174 | The name of the database tablespace to use for this field's index, if this field |
| 177 | 175 | is indexed. The default is the project's :setting:`DEFAULT_INDEX_TABLESPACE` |
| 178 | 176 | setting, if set, or the :attr:`~Field.db_tablespace` of the model, if any. If |
| … |
… |
|
| 425 | 423 | ``DecimalField`` |
| 426 | 424 | ---------------- |
| 427 | 425 | |
| 428 | | .. versionadded:: 1.0 |
| 429 | | |
| 430 | 426 | .. class:: DecimalField(max_digits=None, decimal_places=None, [**options]) |
| 431 | 427 | |
| 432 | 428 | A fixed-precision decimal number, represented in Python by a |
| … |
… |
|
| 482 | 478 | date/time of the file upload (so that uploaded files don't fill up the given |
| 483 | 479 | directory). |
| 484 | 480 | |
| 485 | | .. versionchanged:: 1.0 |
| 486 | | |
| 487 | 481 | This may also be a callable, such as a function, which will be called to |
| 488 | 482 | obtain the upload path, including the filename. This callable must be able |
| 489 | 483 | to accept two arguments, and return a Unix-style path (with forward slashes) |
| … |
… |
|
| 512 | 506 | |
| 513 | 507 | .. attribute:: FileField.storage |
| 514 | 508 | |
| 515 | | .. versionadded:: 1.0 |
| 516 | | |
| 517 | 509 | Optional. A storage object, which handles the storage and retrieval of your |
| 518 | 510 | files. See :doc:`/topics/files` for details on how to provide this object. |
| 519 | 511 | |
| … |
… |
|
| 560 | 552 | root, then somebody could upload a CGI or PHP script and execute that script by |
| 561 | 553 | visiting its URL on your site. Don't allow that. |
| 562 | 554 | |
| 563 | | .. versionadded:: 1.0 |
| 564 | | The ``max_length`` argument was added in this version. |
| 565 | | |
| 566 | 555 | By default, :class:`FileField` instances are |
| 567 | 556 | created as ``varchar(100)`` columns in your database. As with other fields, you |
| 568 | 557 | can change the maximum length using the :attr:`~CharField.max_length` argument. |
| … |
… |
|
| 645 | 634 | because the :attr:`~FilePathField.match` applies to the base filename |
| 646 | 635 | (``foo.gif`` and ``bar.gif``). |
| 647 | 636 | |
| 648 | | .. versionadded:: 1.0 |
| 649 | | The ``max_length`` argument was added in this version. |
| 650 | | |
| 651 | 637 | By default, :class:`FilePathField` instances are |
| 652 | 638 | created as ``varchar(100)`` columns in your database. As with other fields, you |
| 653 | 639 | can change the maximum length using the :attr:`~CharField.max_length` argument. |
| … |
… |
|
| 657 | 643 | |
| 658 | 644 | .. class:: FloatField([**options]) |
| 659 | 645 | |
| 660 | | .. versionchanged:: 1.0 |
| 661 | | |
| 662 | 646 | A floating-point number represented in Python by a ``float`` instance. |
| 663 | 647 | |
| 664 | 648 | The admin represents this as an ``<input type="text">`` (a single-line input). |
| … |
… |
|
| 692 | 676 | |
| 693 | 677 | .. _Python Imaging Library: http://www.pythonware.com/products/pil/ |
| 694 | 678 | |
| 695 | | .. versionadded:: 1.0 |
| 696 | | The ``max_length`` argument was added in this version. |
| 697 | | |
| 698 | 679 | By default, :class:`ImageField` instances are created as ``varchar(100)`` |
| 699 | 680 | columns in your database. As with other fields, you can change the maximum |
| 700 | 681 | length using the :attr:`~CharField.max_length` argument. |
| … |
… |
|
| 867 | 848 | class Manufacturer(models.Model): |
| 868 | 849 | # ... |
| 869 | 850 | |
| 870 | | .. versionadded:: 1.0 |
| 871 | | |
| 872 | 851 | To refer to models defined in another application, you can explicitly specify |
| 873 | 852 | a model with the full application label. For example, if the ``Manufacturer`` |
| 874 | 853 | model above is defined in another application called ``production``, you'd |
-
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
|
a
|
b
|
|
| 133 | 133 | |
| 134 | 134 | .. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS]) |
| 135 | 135 | |
| 136 | | .. versionadded:: 1.0 |
| 137 | | The ``force_insert`` and ``force_update`` arguments were added. |
| 138 | | |
| 139 | 136 | .. versionadded:: 1.2 |
| 140 | 137 | The ``using`` argument was added. |
| 141 | 138 | |
| … |
… |
|
| 168 | 165 | The ``pk`` property |
| 169 | 166 | ~~~~~~~~~~~~~~~~~~~ |
| 170 | 167 | |
| 171 | | .. versionadded:: 1.0 |
| 172 | | |
| 173 | 168 | .. attribute:: Model.pk |
| 174 | 169 | |
| 175 | 170 | Regardless of whether you define a primary key field yourself, or let Django |
| … |
… |
|
| 278 | 273 | Forcing an INSERT or UPDATE |
| 279 | 274 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 280 | 275 | |
| 281 | | .. versionadded:: 1.0 |
| 282 | | |
| 283 | 276 | In some rare circumstances, it's necessary to be able to force the ``save()`` |
| 284 | 277 | method to perform an SQL ``INSERT`` and not fall back to doing an ``UPDATE``. |
| 285 | 278 | Or vice-versa: update, if possible, but not insert a new row. In these cases |
-
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
|
a
|
b
|
|
| 65 | 65 | |
| 66 | 66 | .. attribute:: Options.db_tablespace |
| 67 | 67 | |
| 68 | | .. versionadded:: 1.0 |
| 69 | | |
| 70 | 68 | The name of the database tablespace to use for the model. If the backend doesn't |
| 71 | 69 | support tablespaces, this option is ignored. |
| 72 | 70 | |
| … |
… |
|
| 90 | 88 | |
| 91 | 89 | .. attribute:: Options.managed |
| 92 | 90 | |
| 93 | | .. versionadded:: 1.1 |
| 94 | | |
| 95 | 91 | Defaults to ``True``, meaning Django will create the appropriate database |
| 96 | 92 | tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`reset` |
| 97 | 93 | management command. That is, Django *manages* the database tables' lifecycles. |
| … |
… |
|
| 193 | 189 | |
| 194 | 190 | .. attribute:: Options.proxy |
| 195 | 191 | |
| 196 | | .. versionadded:: 1.1 |
| 197 | | |
| 198 | 192 | If set to ``True``, a model which subclasses another model will be treated as |
| 199 | 193 | a :ref:`proxy model <proxy-models>`. |
| 200 | 194 | |
| … |
… |
|
| 212 | 206 | appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE`` |
| 213 | 207 | statement). |
| 214 | 208 | |
| 215 | | .. versionadded:: 1.0 |
| 216 | | |
| 217 | 209 | For convenience, unique_together can be a single list when dealing with a single |
| 218 | 210 | set of fields:: |
| 219 | 211 | |
-
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
|
a
|
b
|
|
| 185 | 185 | |
| 186 | 186 | .. method:: annotate(*args, **kwargs) |
| 187 | 187 | |
| 188 | | .. versionadded:: 1.1 |
| 189 | | |
| 190 | 188 | Annotates each object in the ``QuerySet`` with the provided list of |
| 191 | 189 | aggregate values (averages, sums, etc) that have been computed over |
| 192 | 190 | the objects that are related to the objects in the ``QuerySet``. |
| … |
… |
|
| 278 | 276 | ordering may well be exactly what you want to do. Use ordering on multi-valued |
| 279 | 277 | fields with care and make sure the results are what you expect. |
| 280 | 278 | |
| 281 | | .. versionadded:: 1.0 |
| 282 | | |
| 283 | 279 | If you don't want any ordering to be applied to a query, not even the default |
| 284 | 280 | ordering, call ``order_by()`` with no parameters. |
| 285 | 281 | |
| 286 | | .. versionadded:: 1.0 |
| 287 | | |
| 288 | | The syntax for ordering across related models has changed. See the `Django 0.96 |
| 289 | | documentation`_ for the old behaviour. |
| 290 | | |
| 291 | | .. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield |
| 292 | | |
| 293 | 282 | There's no way to specify whether ordering should be case sensitive. With |
| 294 | 283 | respect to case-sensitivity, Django will order results however your database |
| 295 | 284 | backend normally orders them. |
| 296 | 285 | |
| 297 | | .. versionadded:: 1.1 |
| 298 | | |
| 299 | 286 | You can tell if a query is ordered or not by checking the |
| 300 | 287 | :attr:`QuerySet.ordered` attribute, which will be ``True`` if the |
| 301 | 288 | ``QuerySet`` has been ordered in any way. |
| … |
… |
|
| 305 | 292 | |
| 306 | 293 | .. method:: reverse() |
| 307 | 294 | |
| 308 | | .. versionadded:: 1.0 |
| 309 | | |
| 310 | 295 | Use the ``reverse()`` method to reverse the order in which a queryset's |
| 311 | 296 | elements are returned. Calling ``reverse()`` a second time restores the |
| 312 | 297 | ordering back to the normal direction. |
| … |
… |
|
| 431 | 416 | if the ``extra()`` clause is used after the ``values()``, the |
| 432 | 417 | fields added by the select will be included automatically. |
| 433 | 418 | |
| 434 | | .. versionadded:: 1.0 |
| 435 | | |
| 436 | | Previously, it was not possible to pass ``blog_id`` to ``values()`` in the above |
| 437 | | example, only ``blog``. |
| 438 | | |
| 439 | 419 | A ``ValuesQuerySet`` is useful when you know you're only going to need values |
| 440 | 420 | from a small number of the available fields and you won't need the |
| 441 | 421 | functionality of a model instance object. It's more efficient to select only |
| … |
… |
|
| 458 | 438 | |
| 459 | 439 | .. method:: values_list(*fields) |
| 460 | 440 | |
| 461 | | .. versionadded:: 1.0 |
| 462 | | |
| 463 | 441 | This is similar to ``values()`` except that instead of returning dictionaries, |
| 464 | 442 | it returns tuples when iterated over. Each tuple contains the value from the |
| 465 | 443 | respective field passed into the ``values_list()`` call -- so the first item is |
| … |
… |
|
| 524 | 502 | |
| 525 | 503 | .. method:: none() |
| 526 | 504 | |
| 527 | | .. versionadded:: 1.0 |
| 528 | | |
| 529 | 505 | Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to |
| 530 | 506 | an empty list. This can be used in cases where you know that you should |
| 531 | 507 | return an empty result set and your caller is expecting a ``QuerySet`` |
| … |
… |
|
| 541 | 517 | |
| 542 | 518 | .. method:: all() |
| 543 | 519 | |
| 544 | | .. versionadded:: 1.0 |
| 545 | | |
| 546 | 520 | Returns a ''copy'' of the current ``QuerySet`` (or ``QuerySet`` subclass you |
| 547 | 521 | pass in). This can be useful in some situations where you might want to pass |
| 548 | 522 | in either a model manager or a ``QuerySet`` and do further filtering on the |
| … |
… |
|
| 656 | 630 | parameter in the same ``select_related()`` call, since they are |
| 657 | 631 | conflicting options. |
| 658 | 632 | |
| 659 | | .. versionadded:: 1.0 |
| 660 | | |
| 661 | | Both the ``depth`` argument and the ability to specify field names in the call |
| 662 | | to ``select_related()`` are new in Django version 1.0. |
| 663 | | |
| 664 | 633 | .. versionchanged:: 1.2 |
| 665 | 634 | |
| 666 | 635 | You can also refer to the reverse direction of a ``OneToOneFields`` in |
| … |
… |
|
| 733 | 702 | some database backends, such as some MySQL versions, don't support |
| 734 | 703 | subqueries. |
| 735 | 704 | |
| 736 | | .. versionadded:: 1.0 |
| 737 | | |
| 738 | 705 | In some rare cases, you might wish to pass parameters to the SQL fragments |
| 739 | 706 | in ``extra(select=...)``. For this purpose, use the ``select_params`` |
| 740 | 707 | parameter. Since ``select_params`` is a sequence and the ``select`` |
| … |
… |
|
| 840 | 807 | |
| 841 | 808 | .. method:: defer(*fields) |
| 842 | 809 | |
| 843 | | .. versionadded:: 1.1 |
| 844 | | |
| 845 | 810 | In some complex data-modeling situations, your models might contain a lot of |
| 846 | 811 | fields, some of which could contain a lot of data (for example, text fields), |
| 847 | 812 | or require expensive processing to convert them to Python objects. If you are |
| … |
… |
|
| 900 | 865 | |
| 901 | 866 | .. method:: only(*fields) |
| 902 | 867 | |
| 903 | | .. versionadded:: 1.1 |
| 904 | | |
| 905 | 868 | The ``only()`` method is more or less the opposite of ``defer()``. You |
| 906 | 869 | call it with the fields that should *not* be deferred when retrieving a model. |
| 907 | 870 | If you have a model where almost all the fields need to be deferred, using |
| … |
… |
|
| 1176 | 1139 | |
| 1177 | 1140 | .. method:: aggregate(*args, **kwargs) |
| 1178 | 1141 | |
| 1179 | | .. versionadded:: 1.1 |
| 1180 | | |
| 1181 | 1142 | Returns a dictionary of aggregate values (averages, sums, etc) calculated |
| 1182 | 1143 | over the ``QuerySet``. Each argument to ``aggregate()`` specifies |
| 1183 | 1144 | a value that will be included in the dictionary that is returned. |
| … |
… |
|
| 1250 | 1211 | SELECT ... WHERE id = 14; |
| 1251 | 1212 | SELECT ... WHERE id IS NULL; |
| 1252 | 1213 | |
| 1253 | | .. versionchanged:: 1.0 |
| 1254 | | The semantics of ``id__exact=None`` have changed in Django 1.0. Previously, |
| 1255 | | it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level, |
| 1256 | | which would never match anything. It has now been changed to behave the |
| 1257 | | same as ``id__isnull=True``. |
| 1258 | | |
| 1259 | 1214 | .. admonition:: MySQL comparisons |
| 1260 | 1215 | |
| 1261 | 1216 | In MySQL, a database table's "collation" setting determines whether |
| … |
… |
|
| 1362 | 1317 | inner_q = Blog.objects.filter(name__contains='Cheddar').values('pk').query |
| 1363 | 1318 | entries = Entry.objects.filter(blog__in=inner_q) |
| 1364 | 1319 | |
| 1365 | | |
| 1366 | | .. versionchanged:: 1.1 |
| 1367 | | In Django 1.0, only the latter piece of code is valid. |
| 1368 | | |
| 1369 | 1320 | This second form is a bit less readable and unnatural to write, since it |
| 1370 | 1321 | accesses the internal ``query`` attribute and requires a ``ValuesQuerySet``. |
| 1371 | 1322 | If your code doesn't require compatibility with Django 1.0, use the first |
| … |
… |
|
| 1603 | 1554 | week_day |
| 1604 | 1555 | ~~~~~~~~ |
| 1605 | 1556 | |
| 1606 | | .. versionadded:: 1.1 |
| 1607 | | |
| 1608 | 1557 | For date/datetime fields, a 'day of the week' match. |
| 1609 | 1558 | |
| 1610 | 1559 | Takes an integer value representing the day of week from 1 (Sunday) to 7 |
| … |
… |
|
| 1663 | 1612 | regex |
| 1664 | 1613 | ~~~~~ |
| 1665 | 1614 | |
| 1666 | | .. versionadded:: 1.0 |
| 1667 | | |
| 1668 | 1615 | Case-sensitive regular expression match. |
| 1669 | 1616 | |
| 1670 | 1617 | The regular expression syntax is that of the database backend in use. |
| … |
… |
|
| 1694 | 1641 | iregex |
| 1695 | 1642 | ~~~~~~ |
| 1696 | 1643 | |
| 1697 | | .. versionadded:: 1.0 |
| 1698 | | |
| 1699 | 1644 | Case-insensitive regular expression match. |
| 1700 | 1645 | |
| 1701 | 1646 | Example:: |
| … |
… |
|
| 1717 | 1662 | Aggregation Functions |
| 1718 | 1663 | --------------------- |
| 1719 | 1664 | |
| 1720 | | .. versionadded:: 1.1 |
| 1721 | | |
| 1722 | 1665 | Django provides the following aggregation functions in the |
| 1723 | 1666 | ``django.db.models`` module. For details on how to use these |
| 1724 | 1667 | aggregate functions, see |
-
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
|
a
|
b
|
|
| 47 | 47 | |
| 48 | 48 | .. attribute:: HttpRequest.encoding |
| 49 | 49 | |
| 50 | | .. versionadded:: 1.0 |
| 51 | | |
| 52 | 50 | A string representing the current encoding used to decode form submission |
| 53 | 51 | data (or ``None``, which means the ``DEFAULT_CHARSET`` setting is used). |
| 54 | 52 | You can write to this attribute to change the encoding used when accessing |
| … |
… |
|
| 111 | 109 | ``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank |
| 112 | 110 | dictionary-like object. |
| 113 | 111 | |
| 114 | | .. versionchanged:: 1.0 |
| 115 | | |
| 116 | | In previous versions of Django, ``request.FILES`` contained simple ``dict`` |
| 117 | | objects representing uploaded files. This is no longer true -- files are |
| 118 | | represented by ``UploadedFile`` objects as described below. |
| 119 | | |
| 120 | 112 | These ``UploadedFile`` objects will emulate the old-style ``dict`` |
| 121 | 113 | interface, but this is deprecated and will be removed in the next release of |
| 122 | 114 | Django. |
| … |
… |
|
| 189 | 181 | |
| 190 | 182 | .. method:: HttpRequest.get_host() |
| 191 | 183 | |
| 192 | | .. versionadded:: 1.0 |
| 193 | | |
| 194 | 184 | Returns the originating host of the request using information from the |
| 195 | 185 | ``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If |
| 196 | 186 | they don't provide a value, the method uses a combination of |
| … |
… |
|
| 208 | 198 | |
| 209 | 199 | .. method:: HttpRequest.build_absolute_uri(location) |
| 210 | 200 | |
| 211 | | .. versionadded:: 1.0 |
| 212 | | |
| 213 | 201 | Returns the absolute URI form of ``location``. If no location is provided, |
| 214 | 202 | the location will be set to ``request.get_full_path()``. |
| 215 | 203 | |
| … |
… |
|
| 226 | 214 | |
| 227 | 215 | .. method:: HttpRequest.is_ajax() |
| 228 | 216 | |
| 229 | | .. versionadded:: 1.0 |
| 230 | | |
| 231 | 217 | Returns ``True`` if the request was made via an ``XMLHttpRequest``, by |
| 232 | 218 | checking the ``HTTP_X_REQUESTED_WITH`` header for the string |
| 233 | 219 | ``'XMLHttpRequest'``. Most modern JavaScript libraries send this header. |
| … |
… |
|
| 434 | 420 | >>> response = HttpResponse() |
| 435 | 421 | >>> response['Cache-Control'] = 'no-cache' |
| 436 | 422 | |
| 437 | | .. versionadded:: 1.1 |
| 438 | | |
| 439 | 423 | HTTP headers cannot contain newlines. An attempt to set a header containing a |
| 440 | 424 | newline character (CR or LF) will raise ``BadHeaderError`` |
| 441 | 425 | |
| … |
… |
|
| 478 | 462 | |
| 479 | 463 | ``status`` is the `HTTP Status code`_ for the response. |
| 480 | 464 | |
| 481 | | .. versionadded:: 1.0 |
| 482 | | |
| 483 | 465 | ``content_type`` is an alias for ``mimetype``. Historically, this parameter |
| 484 | 466 | was only called ``mimetype``, but since this is actually the value included |
| 485 | 467 | in the HTTP ``Content-Type`` header, it can also include the character set |
| … |
… |
|
| 576 | 558 | |
| 577 | 559 | .. class:: HttpResponseBadRequest |
| 578 | 560 | |
| 579 | | .. versionadded:: 1.0 |
| 580 | | |
| 581 | 561 | Acts just like :class:`HttpResponse` but uses a 400 status code. |
| 582 | 562 | |
| 583 | 563 | .. class:: HttpResponseNotFound |
-
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
|
a
|
b
|
|
| 538 | 538 | DEBUG_PROPAGATE_EXCEPTIONS |
| 539 | 539 | -------------------------- |
| 540 | 540 | |
| 541 | | .. versionadded:: 1.0 |
| 542 | | |
| 543 | 541 | Default: ``False`` |
| 544 | 542 | |
| 545 | 543 | If set to True, Django's normal exception handling of view functions |
| … |
… |
|
| 605 | 603 | DEFAULT_INDEX_TABLESPACE |
| 606 | 604 | ------------------------ |
| 607 | 605 | |
| 608 | | .. versionadded:: 1.0 |
| 609 | | |
| 610 | 606 | Default: ``''`` (Empty string) |
| 611 | 607 | |
| 612 | 608 | Default tablespace to use for indexes on fields that don't specify |
| … |
… |
|
| 617 | 613 | DEFAULT_TABLESPACE |
| 618 | 614 | ------------------ |
| 619 | 615 | |
| 620 | | .. versionadded:: 1.0 |
| 621 | | |
| 622 | 616 | Default: ``''`` (Empty string) |
| 623 | 617 | |
| 624 | 618 | Default tablespace to use for models that don't specify one, if the |
| … |
… |
|
| 721 | 715 | EMAIL_USE_TLS |
| 722 | 716 | ------------- |
| 723 | 717 | |
| 724 | | .. versionadded:: 1.0 |
| 725 | | |
| 726 | 718 | Default: ``False`` |
| 727 | 719 | |
| 728 | 720 | Whether to use a TLS (secure) connection when talking to the SMTP server. |
| … |
… |
|
| 732 | 724 | FILE_CHARSET |
| 733 | 725 | ------------ |
| 734 | 726 | |
| 735 | | .. versionadded:: 1.0 |
| 736 | | |
| 737 | 727 | Default: ``'utf-8'`` |
| 738 | 728 | |
| 739 | 729 | The character encoding used to decode any files read from disk. This includes |
| … |
… |
|
| 744 | 734 | FILE_UPLOAD_HANDLERS |
| 745 | 735 | -------------------- |
| 746 | 736 | |
| 747 | | .. versionadded:: 1.0 |
| 748 | | |
| 749 | 737 | Default:: |
| 750 | 738 | |
| 751 | 739 | ("django.core.files.uploadhandler.MemoryFileUploadHandler", |
| … |
… |
|
| 758 | 746 | FILE_UPLOAD_MAX_MEMORY_SIZE |
| 759 | 747 | --------------------------- |
| 760 | 748 | |
| 761 | | .. versionadded:: 1.0 |
| 762 | | |
| 763 | 749 | Default: ``2621440`` (i.e. 2.5 MB). |
| 764 | 750 | |
| 765 | 751 | The maximum size (in bytes) that an upload will be before it gets streamed to |
| … |
… |
|
| 798 | 784 | FILE_UPLOAD_TEMP_DIR |
| 799 | 785 | -------------------- |
| 800 | 786 | |
| 801 | | .. versionadded:: 1.0 |
| 802 | | |
| 803 | 787 | Default: ``None`` |
| 804 | 788 | |
| 805 | 789 | The directory to store data temporarily while uploading files. If ``None``, |
| … |
… |
|
| 945 | 929 | LANGUAGE_COOKIE_NAME |
| 946 | 930 | -------------------- |
| 947 | 931 | |
| 948 | | .. versionadded:: 1.0 |
| 949 | | |
| 950 | 932 | Default: ``'django_language'`` |
| 951 | 933 | |
| 952 | 934 | The name of the cookie to use for the language cookie. This can be whatever you |
| … |
… |
|
| 1011 | 993 | LOGIN_REDIRECT_URL |
| 1012 | 994 | ------------------ |
| 1013 | 995 | |
| 1014 | | .. versionadded:: 1.0 |
| 1015 | | |
| 1016 | 996 | Default: ``'/accounts/profile/'`` |
| 1017 | 997 | |
| 1018 | 998 | The URL where requests are redirected after login when the |
| … |
… |
|
| 1026 | 1006 | LOGIN_URL |
| 1027 | 1007 | --------- |
| 1028 | 1008 | |
| 1029 | | .. versionadded:: 1.0 |
| 1030 | | |
| 1031 | 1009 | Default: ``'/accounts/login/'`` |
| 1032 | 1010 | |
| 1033 | 1011 | The URL where requests are redirected for login, especially when using the |
| … |
… |
|
| 1038 | 1016 | LOGOUT_URL |
| 1039 | 1017 | ---------- |
| 1040 | 1018 | |
| 1041 | | .. versionadded:: 1.0 |
| 1042 | | |
| 1043 | 1019 | Default: ``'/accounts/logout/'`` |
| 1044 | 1020 | |
| 1045 | 1021 | LOGIN_URL counterpart. |
| … |
… |
|
| 1304 | 1280 | SESSION_COOKIE_PATH |
| 1305 | 1281 | ------------------- |
| 1306 | 1282 | |
| 1307 | | .. versionadded:: 1.0 |
| 1308 | | |
| 1309 | 1283 | Default: ``'/'`` |
| 1310 | 1284 | |
| 1311 | 1285 | The path set on the session cookie. This should either match the URL path of your |
| … |
… |
|
| 1332 | 1306 | SESSION_ENGINE |
| 1333 | 1307 | -------------- |
| 1334 | 1308 | |
| 1335 | | .. versionadded:: 1.0 |
| 1336 | | |
| 1337 | | .. versionchanged:: 1.1 |
| 1338 | | The ``cached_db`` backend was added |
| 1339 | | |
| 1340 | 1309 | Default: ``django.contrib.sessions.backends.db`` |
| 1341 | 1310 | |
| 1342 | 1311 | Controls where Django stores session data. Valid values are: |
| … |
… |
|
| 1363 | 1332 | SESSION_FILE_PATH |
| 1364 | 1333 | ----------------- |
| 1365 | 1334 | |
| 1366 | | .. versionadded:: 1.0 |
| 1367 | | |
| 1368 | 1335 | Default: ``None`` |
| 1369 | 1336 | |
| 1370 | 1337 | If you're using file-based session storage, this sets the directory in |
-
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
|
a
|
b
|
|
| 470 | 470 | .. data:: django.db.backends.signals.connection_created |
| 471 | 471 | :module: |
| 472 | 472 | |
| 473 | | .. versionadded:: 1.1 |
| 474 | | |
| 475 | 473 | .. versionchanged:: 1.2 |
| 476 | 474 | The connection argument was added |
| 477 | 475 | |
-
diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
|
a
|
b
|
|
| 426 | 426 | django.core.context_processors.media |
| 427 | 427 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 428 | 428 | |
| 429 | | .. versionadded:: 1.0 |
| 430 | | |
| 431 | 429 | If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every |
| 432 | 430 | ``RequestContext`` will contain a variable ``MEDIA_URL``, providing the |
| 433 | 431 | value of the :setting:`MEDIA_URL` setting. |
-
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
|
a
|
b
|
|
| 19 | 19 | autoescape |
| 20 | 20 | ~~~~~~~~~~ |
| 21 | 21 | |
| 22 | | .. versionadded:: 1.0 |
| 23 | | |
| 24 | 22 | Control the current auto-escaping behavior. This tag takes either ``on`` or |
| 25 | 23 | ``off`` as an argument and that determines whether auto-escaping is in effect |
| 26 | 24 | inside the block. The block is closed with an ``endautoescape`` ending tag. |
| … |
… |
|
| 72 | 70 | cycle |
| 73 | 71 | ~~~~~ |
| 74 | 72 | |
| 75 | | .. versionchanged:: 1.0 |
| 76 | | Cycle among the given strings or variables each time this tag is encountered. |
| | 73 | Cycle among the given strings or variables each time this tag is encountered. |
| 77 | 74 | |
| 78 | 75 | Within a loop, cycles among the given strings each time through the |
| 79 | 76 | loop:: |
| … |
… |
|
| 239 | 236 | |
| 240 | 237 | You can loop over a list in reverse by using ``{% for obj in list reversed %}``. |
| 241 | 238 | |
| 242 | | .. versionadded:: 1.0 |
| 243 | | |
| 244 | 239 | If you need to loop over a list of lists, you can unpack the values |
| 245 | 240 | in each sub-list into individual variables. For example, if your context |
| 246 | 241 | contains a list of (x,y) coordinates called ``points``, you could use the |
| … |
… |
|
| 278 | 273 | for ... empty |
| 279 | 274 | ^^^^^^^^^^^^^ |
| 280 | 275 | |
| 281 | | .. versionadded:: 1.1 |
| 282 | | |
| 283 | 276 | The ``for`` tag can take an optional ``{% empty %}`` clause that will be |
| 284 | 277 | displayed if the given array is empty or could not be found:: |
| 285 | 278 | |
| … |
… |
|
| 953 | 946 | |
| 954 | 947 | The template tag will output the string ``/clients/client/123/``. |
| 955 | 948 | |
| 956 | | .. versionadded:: 1.0 |
| 957 | | |
| 958 | 949 | If you're using :ref:`named URL patterns <naming-url-patterns>`, you can |
| 959 | 950 | refer to the name of the pattern in the ``url`` tag instead of using the |
| 960 | 951 | path to the view. |
| … |
… |
|
| 963 | 954 | :exc:`NoReverseMatch` exception raised, which will cause your site to display an |
| 964 | 955 | error page. |
| 965 | 956 | |
| 966 | | .. versionadded:: 1.0 |
| 967 | | |
| 968 | 957 | If you'd like to retrieve a URL without displaying it, you can use a slightly |
| 969 | 958 | different call:: |
| 970 | 959 | |
| … |
… |
|
| 981 | 970 | <a href="{{ the_url }}">Link to optional stuff</a> |
| 982 | 971 | {% endif %} |
| 983 | 972 | |
| 984 | | .. versionadded:: 1.1 |
| 985 | | |
| 986 | 973 | If you'd like to retrieve a namespaced URL, specify the fully qualified name:: |
| 987 | 974 | |
| 988 | 975 | {% url myapp:view-name %} |
| … |
… |
|
| 1026 | 1013 | with |
| 1027 | 1014 | ~~~~ |
| 1028 | 1015 | |
| 1029 | | .. versionadded:: 1.0 |
| 1030 | | |
| 1031 | 1016 | Caches a complex variable under a simpler name. This is useful when accessing |
| 1032 | 1017 | an "expensive" method (e.g., one that hits the database) multiple times. |
| 1033 | 1018 | |
| … |
… |
|
| 1278 | 1263 | it is safe to use this function even in auto-escaping environments. If you want |
| 1279 | 1264 | multiple escaping passes to be applied, use the ``force_escape`` filter. |
| 1280 | 1265 | |
| 1281 | | .. versionchanged:: 1.0 |
| 1282 | | Due to auto-escaping, the behavior of this filter has changed slightly. |
| 1283 | | The replacements are only made once, after |
| 1284 | | all other filters are applied -- including filters before and after it. |
| 1285 | | |
| 1286 | 1266 | .. templatefilter:: escapejs |
| 1287 | 1267 | |
| 1288 | 1268 | escapejs |
| 1289 | 1269 | ~~~~~~~~ |
| 1290 | 1270 | |
| 1291 | | .. versionadded:: 1.0 |
| 1292 | | |
| 1293 | 1271 | Escapes characters for use in JavaScript strings. This does *not* make the |
| 1294 | 1272 | string safe for use in HTML, but does protect you from syntax errors when using |
| 1295 | 1273 | templates to generate JavaScript/JSON. |
| … |
… |
|
| 1333 | 1311 | fix_ampersands |
| 1334 | 1312 | ~~~~~~~~~~~~~~ |
| 1335 | 1313 | |
| 1336 | | .. versionchanged:: 1.0 |
| 1337 | | This is rarely useful as ampersands are now automatically escaped. See escape_ for more information. |
| | 1314 | ..note:: |
| | 1315 | |
| | 1316 | This is rarely useful as ampersands are automatically escaped. See escape_ for more information. |
| 1338 | 1317 | |
| 1339 | 1318 | Replaces ampersands with ``&`` entities. |
| 1340 | 1319 | |
| … |
… |
|
| 1391 | 1370 | force_escape |
| 1392 | 1371 | ~~~~~~~~~~~~ |
| 1393 | 1372 | |
| 1394 | | .. versionadded:: 1.0 |
| 1395 | | |
| 1396 | 1373 | Applies HTML escaping to a string (see the ``escape`` filter for details). |
| 1397 | 1374 | This filter is applied *immediately* and returns a new, escaped string. This |
| 1398 | 1375 | is useful in the rare cases where you need multiple escaping or want to apply |
| … |
… |
|
| 1452 | 1429 | last |
| 1453 | 1430 | ~~~~ |
| 1454 | 1431 | |
| 1455 | | .. versionadded:: 1.0 |
| 1456 | | |
| 1457 | 1432 | Returns the last item in a list. |
| 1458 | 1433 | |
| 1459 | 1434 | For example:: |
| … |
… |
|
| 1918 | 1893 | Recursively takes a self-nested list and returns an HTML unordered list -- |
| 1919 | 1894 | WITHOUT opening and closing <ul> tags. |
| 1920 | 1895 | |
| 1921 | | .. versionchanged:: 1.0 |
| 1922 | | The format accepted by ``unordered_list`` has changed to be easier to understand. |
| 1923 | | |
| 1924 | 1896 | The list is assumed to be in the proper format. For example, if ``var`` contains |
| 1925 | 1897 | ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then |
| 1926 | 1898 | ``{{ var|unordered_list }}`` would return:: |
| … |
… |
|
| 1937 | 1909 | </ul> |
| 1938 | 1910 | </li> |
| 1939 | 1911 | |
| 1940 | | Note: the previous more restrictive and verbose format is still supported: |
| | 1912 | Note: An older, more restrictive and verbose input format is also supported: |
| 1941 | 1913 | ``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``, |
| 1942 | 1914 | |
| 1943 | 1915 | .. templatefilter:: upper |
-
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
|
a
|
b
|
|
| 2 | 2 | Unicode data |
| 3 | 3 | ============ |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.0 |
| 6 | | |
| 7 | 5 | Django natively supports Unicode data everywhere. Providing your database can |
| 8 | 6 | somehow store the data, you can safely pass around Unicode strings to |
| 9 | 7 | templates, models and the database. |
-
diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
|
a
|
b
|
|
| 190 | 190 | |
| 191 | 191 | .. method:: models.User.set_unusable_password() |
| 192 | 192 | |
| 193 | | .. versionadded:: 1.0 |
| 194 | | |
| 195 | 193 | Marks the user as having no password set. This isn't the same as |
| 196 | 194 | having a blank string for a password. |
| 197 | 195 | :meth:`~django.contrib.auth.models.User.check_password()` for this user |
| … |
… |
|
| 203 | 201 | |
| 204 | 202 | .. method:: models.User.has_usable_password() |
| 205 | 203 | |
| 206 | | .. versionadded:: 1.0 |
| 207 | | |
| 208 | 204 | Returns ``False`` if |
| 209 | 205 | :meth:`~django.contrib.auth.models.User.set_unusable_password()` has |
| 210 | 206 | been called for this user. |
| … |
… |
|
| 395 | 391 | only supported on platforms that have the standard Python ``crypt`` module |
| 396 | 392 | available. |
| 397 | 393 | |
| 398 | | .. versionadded:: 1.0 |
| 399 | | Support for the ``crypt`` module is new in Django 1.0. |
| 400 | | |
| 401 | 394 | For example:: |
| 402 | 395 | |
| 403 | 396 | sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 |
| … |
… |
|
| 450 | 443 | Creating superusers |
| 451 | 444 | ------------------- |
| 452 | 445 | |
| 453 | | .. versionadded:: 1.0 |
| 454 | | The ``manage.py createsuperuser`` command is new. |
| 455 | | |
| 456 | 446 | :djadmin:`manage.py syncdb <syncdb>` prompts you to create a superuser the |
| 457 | 447 | first time you run it after adding ``'django.contrib.auth'`` to your |
| 458 | 448 | :setting:`INSTALLED_APPS`. If you need to create a superuser at a later date, |
| … |
… |
|
| 653 | 643 | Note that :func:`~django.contrib.auth.logout()` doesn't throw any errors if |
| 654 | 644 | the user wasn't logged in. |
| 655 | 645 | |
| 656 | | .. versionchanged:: 1.0 |
| 657 | | Calling ``logout()`` now cleans session data. |
| 658 | | |
| 659 | 646 | When you call :func:`~django.contrib.auth.logout()`, the session data for |
| 660 | 647 | the current request is completely cleaned out. All existing data is |
| 661 | 648 | removed. This is to prevent another person from using the same web browser |
-
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
|
a
|
b
|
|
| 238 | 238 | Using a custom cache backend |
| 239 | 239 | ---------------------------- |
| 240 | 240 | |
| 241 | | .. versionadded:: 1.0 |
| 242 | | |
| 243 | 241 | While Django includes support for a number of cache backends out-of-the-box, |
| 244 | 242 | sometimes you might want to use a customized cache backend. To use an external |
| 245 | 243 | cache backend with Django, use a Python import path as the scheme portion (the |
| … |
… |
|
| 291 | 289 | The per-site cache |
| 292 | 290 | ================== |
| 293 | 291 | |
| 294 | | .. versionchanged:: 1.0 |
| 295 | | (previous versions of Django only provided a single ``CacheMiddleware`` instead |
| 296 | | of the two pieces described below). |
| 297 | | |
| 298 | 292 | Once the cache is set up, the simplest way to use caching is to cache your |
| 299 | 293 | entire site. You'll need to add |
| 300 | 294 | ``'django.middleware.cache.UpdateCacheMiddleware'`` and |
| … |
… |
|
| 344 | 338 | |
| 345 | 339 | See :doc:`/topics/http/middleware` for more on middleware. |
| 346 | 340 | |
| 347 | | .. versionadded:: 1.0 |
| 348 | | |
| 349 | 341 | If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in |
| 350 | 342 | its ``Cache-Control`` header) then the page will be cached until the expiry |
| 351 | 343 | time, rather than ``CACHE_MIDDLEWARE_SECONDS``. Using the decorators in |
| … |
… |
|
| 441 | 433 | Template fragment caching |
| 442 | 434 | ========================= |
| 443 | 435 | |
| 444 | | .. versionadded:: 1.0 |
| 445 | | |
| 446 | 436 | If you're after even more control, you can also cache template fragments using |
| 447 | 437 | the ``cache`` template tag. To give your template access to this tag, put |
| 448 | 438 | ``{% load cache %}`` near the top of your template. |
| … |
… |
|
| 558 | 548 | >>> cache.get('my_key', 'has expired') |
| 559 | 549 | 'has expired' |
| 560 | 550 | |
| 561 | | .. versionadded:: 1.0 |
| 562 | | |
| 563 | 551 | To add a key only if it doesn't already exist, use the ``add()`` method. |
| 564 | 552 | It takes the same parameters as ``set()``, but it will not attempt to |
| 565 | 553 | update the cache if the key specified is already present:: |
| … |
… |
|
| 614 | 602 | |
| 615 | 603 | >>> cache.clear() |
| 616 | 604 | |
| 617 | | .. versionadded:: 1.1 |
| 618 | | |
| 619 | 605 | You can also increment or decrement a key that already exists using the |
| 620 | 606 | ``incr()`` or ``decr()`` methods, respectively. By default, the existing cache |
| 621 | 607 | value will incremented or decremented by 1. Other increment/decrement values |
-
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
|
a
|
b
|
|
| 2 | 2 | Conditional View Processing |
| 3 | 3 | =========================== |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.1 |
| 6 | | |
| 7 | 5 | HTTP clients can send a number of headers to tell the server about copies of a |
| 8 | 6 | resource that they have already seen. This is commonly used when retrieving a |
| 9 | 7 | web page (using an HTTP ``GET`` request) to avoid sending all the data for |
-
diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt
|
a
|
b
|
|
| 2 | 2 | Aggregation |
| 3 | 3 | =========== |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.1 |
| 6 | | |
| 7 | 5 | .. currentmodule:: django.db.models |
| 8 | 6 | |
| 9 | 7 | The topic guide on :doc:`Django's database-abstraction API </topics/db/queries>` |
-
diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt
|
a
|
b
|
|
| 387 | 387 | Extra fields on many-to-many relationships |
| 388 | 388 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 389 | 389 | |
| 390 | | .. versionadded:: 1.0 |
| 391 | | |
| 392 | 390 | When you're only dealing with simple many-to-many relationships such as |
| 393 | 391 | mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes |
| 394 | 392 | you may need to associate data with the relationship between two models. |
| … |
… |
|
| 552 | 550 | |
| 553 | 551 | .. _One-to-one relationship model example: http://www.djangoproject.com/documentation/models/one_to_one/ |
| 554 | 552 | |
| 555 | | .. versionadded:: 1.0 |
| 556 | | |
| 557 | 553 | :class:`~django.db.models.OneToOneField` fields also accept one optional argument |
| 558 | 554 | described in the :ref:`model field reference <ref-onetoone>`. |
| 559 | 555 | |
| … |
… |
|
| 605 | 601 | Custom field types |
| 606 | 602 | ------------------ |
| 607 | 603 | |
| 608 | | .. versionadded:: 1.0 |
| 609 | | |
| 610 | 604 | If one of the existing model fields cannot be used to fit your purposes, or if |
| 611 | 605 | you wish to take advantage of some less common database column types, you can |
| 612 | 606 | create your own field class. Full coverage of creating your own fields is |
| … |
… |
|
| 768 | 762 | Model inheritance |
| 769 | 763 | ================= |
| 770 | 764 | |
| 771 | | .. versionadded:: 1.0 |
| 772 | | |
| 773 | 765 | Model inheritance in Django works almost identically to the way normal |
| 774 | 766 | class inheritance works in Python. The only decision you have to make |
| 775 | 767 | is whether you want the parent models to be models in their own right |
| … |
… |
|
| 1025 | 1017 | Proxy models |
| 1026 | 1018 | ------------ |
| 1027 | 1019 | |
| 1028 | | .. versionadded:: 1.1 |
| 1029 | | |
| 1030 | 1020 | When using :ref:`multi-table inheritance <multi-table-inheritance>`, a new |
| 1031 | 1021 | database table is created for each subclass of a model. This is usually the |
| 1032 | 1022 | desired behavior, since the subclass needs a place to store any additional |
-
diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt
|
a
|
b
|
|
| 437 | 437 | Spanning multi-valued relationships |
| 438 | 438 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 439 | 439 | |
| 440 | | .. versionadded:: 1.0 |
| 441 | | |
| 442 | 440 | When you are filtering an object based on a ``ManyToManyField`` or a reverse |
| 443 | 441 | ``ForeignKey``, there are two different sorts of filter you may be |
| 444 | 442 | interested in. Consider the ``Blog``/``Entry`` relationship (``Blog`` to |
| … |
… |
|
| 494 | 492 | Filters can reference fields on the model |
| 495 | 493 | ----------------------------------------- |
| 496 | 494 | |
| 497 | | .. versionadded:: 1.1 |
| 498 | | |
| 499 | 495 | In the examples given so far, we have constructed filters that compare |
| 500 | 496 | the value of a model field with a constant. But what if you want to compare |
| 501 | 497 | the value of a model field with another field on the same model? |
| … |
… |
|
| 766 | 762 | Updating multiple objects at once |
| 767 | 763 | ================================= |
| 768 | 764 | |
| 769 | | .. versionadded:: 1.0 |
| 770 | | |
| 771 | 765 | Sometimes you want to set a field to a particular value for all the objects in |
| 772 | 766 | a ``QuerySet``. You can do this with the ``update()`` method. For example:: |
| 773 | 767 | |
| … |
… |
|
| 806 | 800 | for item in my_queryset: |
| 807 | 801 | item.save() |
| 808 | 802 | |
| 809 | | .. versionadded:: 1.1 |
| 810 | | |
| 811 | 803 | Calls to update can also use :ref:`F() objects <query-expressions>` to update |
| 812 | 804 | one field based on the value of another field in the model. This is especially |
| 813 | 805 | useful for incrementing counters based upon their current value. For example, to |
-
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
|
a
|
b
|
|
| 301 | 301 | Database-level autocommit |
| 302 | 302 | ------------------------- |
| 303 | 303 | |
| 304 | | .. versionadded:: 1.1 |
| 305 | | |
| 306 | 304 | With PostgreSQL 8.2 or later, there is an advanced option to run PostgreSQL |
| 307 | 305 | with :doc:`database-level autocommit </ref/databases>`. If you use this option, |
| 308 | 306 | there is no constantly open transaction, so it is always possible to continue |
-
diff --git a/docs/topics/email.txt b/docs/topics/email.txt
|
a
|
b
|
|
| 196 | 196 | The EmailMessage class |
| 197 | 197 | ====================== |
| 198 | 198 | |
| 199 | | .. versionadded:: 1.0 |
| 200 | | |
| 201 | 199 | Django's :meth:`~django.core.mail.send_mail()` and |
| 202 | 200 | :meth:`~django.core.mail.send_mass_mail()` functions are actually thin |
| 203 | 201 | wrappers that make use of the :class:`~django.core.mail.EmailMessage` class. |
-
diff --git a/docs/topics/files.txt b/docs/topics/files.txt
|
a
|
b
|
|
| 2 | 2 | Managing files |
| 3 | 3 | ============== |
| 4 | 4 | |
| 5 | | .. versionadded:: 1.0 |
| 6 | | |
| 7 | 5 | This document describes Django's file access APIs. |
| 8 | 6 | |
| 9 | 7 | By default, Django stores files locally, using the :setting:`MEDIA_ROOT` and |
-
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
|
a
|
b
|
|
| 157 | 157 | the management data by rendering ``{{ my_formset.management_form }}`` |
| 158 | 158 | (substituting the name of your formset as appropriate). |
| 159 | 159 | |
| 160 | | .. versionadded:: 1.1 |
| 161 | | |
| 162 | 160 | ``total_form_count`` and ``initial_form_count`` |
| 163 | 161 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 164 | 162 | |
-
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
|
a
|
b
|
|
| 113 | 113 | 3. If the form has been submitted but is invalid, the bound form instance is |
| 114 | 114 | passed on to the template. |
| 115 | 115 | |
| 116 | | .. versionchanged:: 1.0 |
| 117 | | The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases. |
| 118 | | |
| 119 | 116 | The distinction between **bound** and **unbound** forms is important. An unbound |
| 120 | 117 | form does not have any data associated with it; when rendered to the user, it |
| 121 | 118 | will be empty or will contain default values. A bound form does have submitted |
| … |
… |
|
| 343 | 340 | interaction won't alter them. However, you could easily insert some error |
| 344 | 341 | displays for those form errors, as well. |
| 345 | 342 | |
| 346 | | .. versionadded:: 1.1 |
| 347 | | The ``hidden_fields`` and ``visible_fields`` methods are new in Django |
| 348 | | 1.1. |
| 349 | | |
| 350 | 343 | Reusable form templates |
| 351 | 344 | ----------------------- |
| 352 | 345 | |
-
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
|
a
|
b
|
|
| 105 | 105 | ``widget=forms.Textarea`` |
| 106 | 106 | =============================== ======================================== |
| 107 | 107 | |
| 108 | | |
| 109 | | .. versionadded:: 1.0 |
| 110 | | The ``FloatField`` form field and ``DecimalField`` model and form fields |
| 111 | | are new in Django 1.0. |
| 112 | | |
| 113 | 108 | .. versionadded:: 1.2 |
| 114 | 109 | The ``BigIntegerField`` is new in Django 1.2. |
| 115 | 110 | |
| … |
… |
|
| 305 | 300 | |
| 306 | 301 | 2. Use the ``fields`` attribute of the ``ModelForm``'s inner ``Meta`` |
| 307 | 302 | class. This attribute, if given, should be a list of field names |
| 308 | | to include in the form. |
| 309 | | |
| 310 | | .. versionchanged:: 1.1 |
| 311 | | |
| 312 | | The form will render the fields in the same order they are specified in the |
| 313 | | ``fields`` attribute. |
| | 303 | to include in the form. The order in which the fields names are specified |
| | 304 | in that list is respected when the form renders them. |
| 314 | 305 | |
| 315 | 306 | 3. Use the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta`` |
| 316 | 307 | class. This attribute, if given, should be a list of field names |
| … |
… |
|
| 450 | 441 | Changing the order of fields |
| 451 | 442 | ---------------------------- |
| 452 | 443 | |
| 453 | | .. versionadded:: 1.1 |
| 454 | | |
| 455 | 444 | By default, a ``ModelForm`` will render fields in the same order that they are |
| 456 | 445 | defined on the model, with ``ManyToManyField`` instances appearing last. If |
| 457 | 446 | you want to change the order in which fields are rendered, you can use the |
-
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
|
a
|
b
|
|
| 4 | 4 | |
| 5 | 5 | .. currentmodule:: django.core.files |
| 6 | 6 | |
| 7 | | .. versionadded:: 1.0 |
| 8 | | |
| 9 | 7 | When Django handles a file upload, the file data ends up placed in |
| 10 | 8 | :attr:`request.FILES <django.http.HttpRequest.FILES>` (for more on the |
| 11 | 9 | ``request`` object see the documentation for :doc:`request and response objects |
-
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
|
a
|
b
|
|
| 29 | 29 | Configuring the session engine |
| 30 | 30 | ============================== |
| 31 | 31 | |
| 32 | | .. versionadded:: 1.0 |
| 33 | | |
| 34 | 32 | By default, Django stores sessions in your database (using the model |
| 35 | 33 | ``django.contrib.sessions.models.Session``). Though this is convenient, in |
| 36 | 34 | some setups it's faster to store session data elsewhere, so Django can be |
| … |
… |
|
| 50 | 48 | |
| 51 | 49 | For better performance, you may want to use a cache-based session backend. |
| 52 | 50 | |
| 53 | | .. versionchanged:: 1.1 |
| 54 | | Django 1.0 did not include the ``cached_db`` session backend. |
| 55 | | |
| 56 | 51 | To store session data using Django's cache system, you'll first need to make |
| 57 | 52 | sure you've configured your cache; see the :doc:`cache documentation |
| 58 | 53 | </topics/cache>` for details. |
| … |
… |
|
| 138 | 133 | |
| 139 | 134 | * ``clear()`` |
| 140 | 135 | |
| 141 | | .. versionadded:: 1.0 |
| 142 | | ``setdefault()`` and ``clear()`` are new in this version. |
| 143 | | |
| 144 | 136 | It also has these methods: |
| 145 | 137 | |
| 146 | 138 | * ``flush()`` |
| 147 | 139 | |
| 148 | | .. versionadded:: 1.0 |
| 149 | | |
| 150 | 140 | Delete the current session data from the session and regenerate the |
| 151 | 141 | session key value that is sent back to the user in the cookie. This is |
| 152 | 142 | used if you want to ensure that the previous session data can't be |
| … |
… |
|
| 173 | 163 | |
| 174 | 164 | * ``set_expiry(value)`` |
| 175 | 165 | |
| 176 | | .. versionadded:: 1.0 |
| 177 | | |
| 178 | 166 | Sets the expiration time for the session. You can pass a number of |
| 179 | 167 | different values: |
| 180 | 168 | |
| … |
… |
|
| 198 | 186 | |
| 199 | 187 | * ``get_expiry_age()`` |
| 200 | 188 | |
| 201 | | .. versionadded:: 1.0 |
| 202 | | |
| 203 | 189 | Returns the number of seconds until this session expires. For sessions |
| 204 | 190 | with no custom expiration (or those set to expire at browser close), this |
| 205 | 191 | will equal ``settings.SESSION_COOKIE_AGE``. |
| 206 | 192 | |
| 207 | 193 | * ``get_expiry_date()`` |
| 208 | 194 | |
| 209 | | .. versionadded:: 1.0 |
| 210 | | |
| 211 | 195 | Returns the date this session will expire. For sessions with no custom |
| 212 | 196 | expiration (or those set to expire at browser close), this will equal the |
| 213 | 197 | date ``settings.SESSION_COOKIE_AGE`` seconds from now. |
| 214 | 198 | |
| 215 | 199 | * ``get_expire_at_browser_close()`` |
| 216 | 200 | |
| 217 | | .. versionadded:: 1.0 |
| 218 | | |
| 219 | 201 | Returns either ``True`` or ``False``, depending on whether the user's |
| 220 | 202 | session cookie will expire when the user's Web browser is closed. |
| 221 | 203 | |
| … |
… |
|
| 302 | 284 | Using sessions out of views |
| 303 | 285 | =========================== |
| 304 | 286 | |
| 305 | | .. versionadded:: 1.0 |
| 306 | | |
| 307 | 287 | An API is available to manipulate session data outside of a view:: |
| 308 | 288 | |
| 309 | 289 | >>> from django.contrib.sessions.backends.db import SessionStore |
| … |
… |
|
| 384 | 364 | her browser. Use this if you want people to have to log in every time they open |
| 385 | 365 | a browser. |
| 386 | 366 | |
| 387 | | .. versionadded:: 1.0 |
| 388 | | |
| 389 | 367 | This setting is a global default and can be overwritten at a per-session level |
| 390 | 368 | by explicitly calling ``request.session.set_expiry()`` as described above in |
| 391 | 369 | `using sessions in views`_. |
| … |
… |
|
| 415 | 393 | SESSION_ENGINE |
| 416 | 394 | -------------- |
| 417 | 395 | |
| 418 | | .. versionadded:: 1.0 |
| 419 | | |
| 420 | | .. versionchanged:: 1.1 |
| 421 | | The ``cached_db`` backend was added |
| 422 | | |
| 423 | 396 | Default: ``django.contrib.sessions.backends.db`` |
| 424 | 397 | |
| 425 | 398 | Controls where Django stores session data. Valid values are: |
| … |
… |
|
| 434 | 407 | SESSION_FILE_PATH |
| 435 | 408 | ----------------- |
| 436 | 409 | |
| 437 | | .. versionadded:: 1.0 |
| 438 | | |
| 439 | 410 | Default: ``/tmp/`` |
| 440 | 411 | |
| 441 | 412 | If you're using file-based session storage, this sets the directory in |
| … |
… |
|
| 467 | 438 | SESSION_COOKIE_PATH |
| 468 | 439 | ------------------- |
| 469 | 440 | |
| 470 | | .. versionadded:: 1.0 |
| 471 | | |
| 472 | 441 | Default: ``'/'`` |
| 473 | 442 | |
| 474 | 443 | The path set on the session cookie. This should either match the URL path of |
-
diff --git a/docs/topics/http/shortcuts.txt b/docs/topics/http/shortcuts.txt
|
a
|
b
|
|
| 48 | 48 | |
| 49 | 49 | ``mimetype`` |
| 50 | 50 | |
| 51 | | .. versionadded:: 1.0 |
| 52 | | |
| 53 | 51 | The MIME type to use for the resulting document. Defaults to the value of |
| 54 | 52 | the :setting:`DEFAULT_CONTENT_TYPE` setting. |
| 55 | 53 | |
| … |
… |
|
| 83 | 81 | |
| 84 | 82 | .. function:: redirect(to[, permanent=False], *args, **kwargs) |
| 85 | 83 | |
| 86 | | .. versionadded:: 1.1 |
| 87 | | |
| 88 | 84 | Returns an HttpResponseRedirect to the apropriate URL for the arguments |
| 89 | 85 | passed. |
| 90 | 86 | |
-
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
|
a
|
b
|
|
| 223 | 223 | url |
| 224 | 224 | --- |
| 225 | 225 | |
| 226 | | .. versionadded:: 1.0 |
| 227 | | |
| 228 | 226 | .. function:: url(regex, view, kwargs=None, name=None, prefix='') |
| 229 | 227 | |
| 230 | 228 | You can use the ``url()`` function, instead of a tuple, as an argument to |
| … |
… |
|
| 283 | 281 | A function that takes a full Python import path to another URLconf module that |
| 284 | 282 | should be "included" in this place. |
| 285 | 283 | |
| 286 | | .. versionadded:: 1.1 |
| 287 | | |
| 288 | 284 | :func:`include` also accepts as an argument an iterable that returns URL |
| 289 | 285 | patterns. |
| 290 | 286 | |
| … |
… |
|
| 415 | 411 | up to that point and sends the remaining string to the included URLconf for |
| 416 | 412 | further processing. |
| 417 | 413 | |
| 418 | | .. versionadded:: 1.1 |
| 419 | | |
| 420 | 414 | Another possibility is to include additional URL patterns not by specifying the |
| 421 | 415 | URLconf Python module defining them as the `include`_ argument but by using |
| 422 | 416 | directly the pattern list as returned by `patterns`_ instead. For example:: |
| … |
… |
|
| 634 | 628 | Naming URL patterns |
| 635 | 629 | =================== |
| 636 | 630 | |
| 637 | | .. versionadded:: 1.0 |
| 638 | | |
| 639 | 631 | It's fairly common to use the same view function in multiple URL patterns in |
| 640 | 632 | your URLconf. For example, these two URL patterns both point to the ``archive`` |
| 641 | 633 | view:: |
| … |
… |
|
| 694 | 686 | URL namespaces |
| 695 | 687 | -------------- |
| 696 | 688 | |
| 697 | | .. versionadded:: 1.1 |
| 698 | | |
| 699 | 689 | Namespaced URLs are specified using the ``:`` operator. For example, the main |
| 700 | 690 | index page of the admin application is referenced using ``admin:index``. This |
| 701 | 691 | indicates a namespace of ``admin``, and a named URL of ``index``. |
| … |
… |
|
| 801 | 791 | matching against incoming URLs and sending them off to views, but you cannot |
| 802 | 792 | reverse such patterns. |
| 803 | 793 | |
| 804 | | .. versionadded:: 1.1 |
| 805 | | |
| 806 | 794 | The ``current_app`` argument allows you to provide a hint to the resolver |
| 807 | 795 | indicating the application to which the currently executing view belongs. |
| 808 | 796 | This ``current_app`` argument is used as a hint to resolve application |
-
diff --git a/docs/topics/i18n/deployment.txt b/docs/topics/i18n/deployment.txt
|
a
|
b
|
|
| 81 | 81 | |
| 82 | 82 | * Failing that, it looks for a cookie. |
| 83 | 83 | |
| 84 | | .. versionchanged:: 1.0 |
| 85 | | |
| 86 | | In Django version 0.96 and before, the cookie's name is hard-coded to |
| 87 | | ``django_language``. In Django 1,0, The cookie name is set by the |
| 88 | | ``LANGUAGE_COOKIE_NAME`` setting. (The default name is |
| 89 | | ``django_language``.) |
| | 84 | The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME`` |
| | 85 | setting. (The default name is ``django_language``.) |
| 90 | 86 | |
| 91 | 87 | * Failing that, it looks at the ``Accept-Language`` HTTP header. This |
| 92 | 88 | header is sent by your browser and tells the server which language(s) you |
-
diff --git a/docs/topics/pagination.txt b/docs/topics/pagination.txt
|
a
|
b
|
|
| 5 | 5 | .. module:: django.core.paginator |
| 6 | 6 | :synopsis: Classes to help you easily manage paginated data. |
| 7 | 7 | |
| 8 | | .. versionchanged:: 1.0 |
| 9 | | Pagination facilities have been almost fully reworked. |
| 10 | | |
| 11 | 8 | Django provides a few classes that help you manage paginated data -- that is, |
| 12 | 9 | data that's split across several pages, with "Previous/Next" links. These |
| 13 | 10 | classes live in :file:`django/core/paginator.py`. |
-
diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt
|
a
|
b
|
|
| 390 | 390 | Automatic HTML escaping |
| 391 | 391 | ======================= |
| 392 | 392 | |
| 393 | | .. versionadded:: 1.0 |
| 394 | | |
| 395 | 393 | When generating HTML from templates, there's always a risk that a variable will |
| 396 | 394 | include characters that affect the resulting HTML. For example, consider this |
| 397 | 395 | template fragment:: |
-
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
|
a
|
b
|
|
| 256 | 256 | |
| 257 | 257 | Note that we used ``animals``, not ``myproject.animals``. |
| 258 | 258 | |
| 259 | | .. versionadded:: 1.0 |
| 260 | | You can now choose which test to run. |
| 261 | | |
| 262 | 259 | You can be even *more* specific by naming an individual test case. To |
| 263 | 260 | run a single test case in an application (for example, the |
| 264 | 261 | ``AnimalTestCase`` described in the "Writing unit tests" section), add |
| … |
… |
|
| 352 | 349 | to make sure that the given user account has sufficient privileges to |
| 353 | 350 | create a new database on the system. |
| 354 | 351 | |
| 355 | | .. versionadded:: 1.0 |
| 356 | | |
| 357 | 352 | For fine-grained control over the character encoding of your test |
| 358 | 353 | database, use the :setting:`TEST_CHARSET` option. If you're using |
| 359 | 354 | MySQL, you can also use the :setting:`TEST_COLLATION` option to |
| … |
… |
|
| 626 | 621 | details view, which is a good way to test code paths that use the |
| 627 | 622 | :meth:`django.http.HttpRequest.is_ajax()` method. |
| 628 | 623 | |
| 629 | | .. versionadded:: 1.1 |
| 630 | | |
| 631 | 624 | If you already have the GET arguments in URL-encoded form, you can |
| 632 | 625 | use that encoding instead of using the data argument. For example, |
| 633 | 626 | the previous GET request could also be posed as:: |
| … |
… |
|
| 710 | 703 | |
| 711 | 704 | The ``extra`` argument acts the same as for :meth:`Client.get`. |
| 712 | 705 | |
| 713 | | .. versionchanged:: 1.1 |
| 714 | | |
| 715 | 706 | If the URL you request with a POST contains encoded parameters, these |
| 716 | 707 | parameters will be made available in the request.GET data. For example, |
| 717 | 708 | if you were to make the request:: |
| … |
… |
|
| 728 | 719 | |
| 729 | 720 | .. method:: Client.head(path, data={}, follow=False, **extra) |
| 730 | 721 | |
| 731 | | .. versionadded:: 1.1 |
| 732 | | |
| 733 | 722 | Makes a HEAD request on the provided ``path`` and returns a ``Response`` |
| 734 | 723 | object. Useful for testing RESTful interfaces. Acts just like |
| 735 | 724 | :meth:`Client.get` except it does not return a message body. |
| … |
… |
|
| 740 | 729 | |
| 741 | 730 | .. method:: Client.options(path, data={}, follow=False, **extra) |
| 742 | 731 | |
| 743 | | .. versionadded:: 1.1 |
| 744 | | |
| 745 | 732 | Makes an OPTIONS request on the provided ``path`` and returns a |
| 746 | 733 | ``Response`` object. Useful for testing RESTful interfaces. |
| 747 | 734 | |
| … |
… |
|
| 753 | 740 | |
| 754 | 741 | .. method:: Client.put(path, data={}, content_type=MULTIPART_CONTENT, follow=False, **extra) |
| 755 | 742 | |
| 756 | | .. versionadded:: 1.1 |
| 757 | | |
| 758 | 743 | Makes a PUT request on the provided ``path`` and returns a |
| 759 | 744 | ``Response`` object. Useful for testing RESTful interfaces. Acts just |
| 760 | 745 | like :meth:`Client.post` except with the PUT request method. |
| … |
… |
|
| 765 | 750 | |
| 766 | 751 | .. method:: Client.delete(path, follow=False, **extra) |
| 767 | 752 | |
| 768 | | .. versionadded:: 1.1 |
| 769 | | |
| 770 | 753 | Makes an DELETE request on the provided ``path`` and returns a |
| 771 | 754 | ``Response`` object. Useful for testing RESTful interfaces. |
| 772 | 755 | |
| … |
… |
|
| 778 | 761 | |
| 779 | 762 | .. method:: Client.login(**credentials) |
| 780 | 763 | |
| 781 | | .. versionadded:: 1.0 |
| 782 | | |
| 783 | 764 | If your site uses Django's :doc:`authentication system</topics/auth>` |
| 784 | 765 | and you deal with logging in users, you can use the test client's |
| 785 | 766 | ``login()`` method to simulate the effect of a user logging into the |
| … |
… |
|
| 824 | 805 | |
| 825 | 806 | .. method:: Client.logout() |
| 826 | 807 | |
| 827 | | .. versionadded:: 1.0 |
| 828 | | |
| 829 | 808 | If your site uses Django's :doc:`authentication system</topics/auth>`, |
| 830 | 809 | the ``logout()`` method can be used to simulate the effect of a user |
| 831 | 810 | logging out of your site. |
| … |
… |
|
| 864 | 843 | If the rendered page used multiple templates, then ``context`` will be a |
| 865 | 844 | list of ``Context`` objects, in the order in which they were rendered. |
| 866 | 845 | |
| 867 | | .. versionadded:: 1.1 |
| 868 | | |
| 869 | 846 | Regardless of the number of templates used during rendering, you can |
| 870 | 847 | retrieve context values using the ``[]`` operator. For example, the |
| 871 | 848 | context variable ``name`` could be retrieved using:: |
| … |
… |
|
| 988 | 965 | will continue to be available, but it will be augmented with some useful |
| 989 | 966 | additions. |
| 990 | 967 | |
| 991 | | .. versionadded:: 1.1 |
| 992 | | |
| 993 | 968 | .. class:: TransactionTestCase() |
| 994 | 969 | |
| 995 | 970 | Django ``TestCase`` classes make use of database transaction facilities, if |
| … |
… |
|
| 1037 | 1012 | Default test client |
| 1038 | 1013 | ~~~~~~~~~~~~~~~~~~~ |
| 1039 | 1014 | |
| 1040 | | .. versionadded:: 1.0 |
| 1041 | | |
| 1042 | 1015 | .. attribute:: TestCase.client |
| 1043 | 1016 | |
| 1044 | 1017 | Every test case in a ``django.test.TestCase`` instance has access to an |
| … |
… |
|
| 1143 | 1116 | URLconf configuration |
| 1144 | 1117 | ~~~~~~~~~~~~~~~~~~~~~ |
| 1145 | 1118 | |
| 1146 | | .. versionadded:: 1.0 |
| 1147 | | |
| 1148 | 1119 | .. attribute:: TestCase.urls |
| 1149 | 1120 | |
| 1150 | 1121 | If your application provides views, you may want to include tests that use the |
| … |
… |
|
| 1212 | 1183 | Emptying the test outbox |
| 1213 | 1184 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
| 1214 | 1185 | |
| 1215 | | .. versionadded:: 1.0 |
| 1216 | | |
| 1217 | 1186 | If you use Django's custom ``TestCase`` class, the test runner will clear the |
| 1218 | 1187 | contents of the test e-mail outbox at the start of each test case. |
| 1219 | 1188 | |
| … |
… |
|
| 1222 | 1191 | Assertions |
| 1223 | 1192 | ~~~~~~~~~~ |
| 1224 | 1193 | |
| 1225 | | .. versionadded:: 1.0 |
| 1226 | | |
| 1227 | 1194 | .. versionchanged:: 1.2 |
| 1228 | 1195 | Addded ``msg_prefix`` argument. |
| 1229 | 1196 | |
| … |
… |
|
| 1282 | 1249 | redirected to ``expected_url`` (including any GET data), and the final |
| 1283 | 1250 | page was received with ``target_status_code``. |
| 1284 | 1251 | |
| 1285 | | .. versionadded:: 1.1 |
| 1286 | | |
| 1287 | 1252 | If your request used the ``follow`` argument, the ``expected_url`` and |
| 1288 | 1253 | ``target_status_code`` will be the url and status code for the final |
| 1289 | 1254 | point of the redirect chain. |
| … |
… |
|
| 1308 | 1273 | E-mail services |
| 1309 | 1274 | --------------- |
| 1310 | 1275 | |
| 1311 | | .. versionadded:: 1.0 |
| 1312 | | |
| 1313 | 1276 | If any of your Django views send e-mail using :doc:`Django's e-mail |
| 1314 | 1277 | functionality </topics/email>`, you probably don't want to send e-mail each time |
| 1315 | 1278 | you run a test using that view. For this reason, Django's test runner |
| … |
… |
|
| 1558 | 1521 | :setting:`NAME` in :setting:`DATABASES` to match the name of the test |
| 1559 | 1522 | database. |
| 1560 | 1523 | |
| 1561 | | .. versionchanged:: 1.0 |
| 1562 | | ``create_test_db()`` now returns the name of the test database. |
| 1563 | | |
| 1564 | 1524 | .. function:: destroy_test_db(old_database_name, verbosity=1) |
| 1565 | 1525 | |
| 1566 | 1526 | Destroys the database whose name is in stored in :setting:`NAME` in the |