mirror of
https://github.com/django/django.git
synced 2025-08-03 18:38:50 +00:00
Removed references to changes made in 1.2.
Thanks Florian Apolloner for the patch.
This commit is contained in:
parent
6492e8e5e6
commit
c28e700c7e
46 changed files with 22 additions and 474 deletions
|
@ -115,8 +115,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.actions_selection_counter
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Controls whether a selection counter is display next to the action dropdown.
|
||||
By default, the admin changelist will display it
|
||||
(``actions_selection_counter = True``).
|
||||
|
@ -177,12 +175,9 @@ subclass::
|
|||
fields = ('url', 'title', 'content')
|
||||
|
||||
In the above example, only the fields ``url``, ``title`` and ``content``
|
||||
will be displayed, sequentially, in the form.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
``fields`` can contain values defined in :attr:`ModelAdmin.readonly_fields`
|
||||
to be displayed as read-only.
|
||||
will be displayed, sequentially, in the form. ``fields`` can contain
|
||||
values defined in :attr:`ModelAdmin.readonly_fields` to be displayed as
|
||||
read-only.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
|
@ -262,8 +257,6 @@ subclass::
|
|||
'fields': (('first_name', 'last_name'), 'address', 'city', 'state'),
|
||||
}
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
``fields`` can contain values defined in
|
||||
:attr:`~ModelAdmin.readonly_fields` to be displayed as read-only.
|
||||
|
||||
|
@ -380,8 +373,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.get_changelist
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
Returns the Changelist class to be used for listing. By default,
|
||||
``django.contrib.admin.views.main.ChangeList`` is used. By inheriting this
|
||||
class you can change the behavior of the listing.
|
||||
|
@ -819,8 +810,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.readonly_fields
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
By default the admin shows all fields as editable. Any fields in this
|
||||
option (which should be a ``list`` or ``tuple``) will display its data
|
||||
as-is and non-editable. This option behaves nearly identical to
|
||||
|
@ -928,8 +917,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. attribute:: ModelAdmin.add_form_template
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Path to a custom template, used by :meth:`add_view`.
|
||||
|
||||
.. attribute:: ModelAdmin.change_form_template
|
||||
|
@ -947,8 +934,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. attribute:: ModelAdmin.delete_selected_confirmation_template
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Path to a custom template, used by the :meth:`delete_selected`
|
||||
action method for displaying a confirmation page when deleting one
|
||||
or more objects. See the :doc:`actions
|
||||
|
@ -1035,8 +1020,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_readonly_fields(self, request, obj=None)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The ``get_readonly_fields`` method is given the ``HttpRequest`` and the
|
||||
``obj`` being edited (or ``None`` on an add form) and is expected to return
|
||||
a ``list`` or ``tuple`` of field names that will be displayed as read-only,
|
||||
|
@ -1405,20 +1388,17 @@ adds some of its own (the shared features are actually defined in the
|
|||
- :attr:`~InlineModelAdmin.form`
|
||||
- :attr:`~ModelAdmin.fieldsets`
|
||||
- :attr:`~ModelAdmin.fields`
|
||||
- :attr:`~ModelAdmin.formfield_overrides`
|
||||
- :attr:`~ModelAdmin.exclude`
|
||||
- :attr:`~ModelAdmin.filter_horizontal`
|
||||
- :attr:`~ModelAdmin.filter_vertical`
|
||||
- :attr:`~ModelAdmin.prepopulated_fields`
|
||||
- :attr:`~ModelAdmin.radio_fields`
|
||||
- :attr:`~ModelAdmin.readonly_fields`
|
||||
- :attr:`~InlineModelAdmin.raw_id_fields`
|
||||
- :meth:`~ModelAdmin.formfield_for_foreignkey`
|
||||
- :meth:`~ModelAdmin.formfield_for_manytomany`
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
- :attr:`~ModelAdmin.readonly_fields`
|
||||
- :attr:`~ModelAdmin.formfield_overrides`
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
- :attr:`~ModelAdmin.ordering`
|
||||
|
@ -1463,8 +1443,6 @@ The ``InlineModelAdmin`` class adds:
|
|||
:doc:`formsets documentation </topics/forms/formsets>` for more
|
||||
information.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
For users with JavaScript-enabled browsers, an "Add another" link is
|
||||
provided to enable any number of additional inlines to be added in addition
|
||||
to those provided as a result of the ``extra`` argument.
|
||||
|
@ -1541,8 +1519,6 @@ automatically::
|
|||
Working with many-to-many models
|
||||
--------------------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
By default, admin widgets for many-to-many relations will be displayed
|
||||
on whichever model contains the actual reference to the
|
||||
:class:`~django.db.models.ManyToManyField`. Depending on your ``ModelAdmin``
|
||||
|
@ -1842,21 +1818,15 @@ Templates can override or extend base admin templates as described in
|
|||
|
||||
.. attribute:: AdminSite.logout_template
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Path to a custom template that will be used by the admin site logout view.
|
||||
|
||||
.. attribute:: AdminSite.password_change_template
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Path to a custom template that will be used by the admin site password
|
||||
change view.
|
||||
|
||||
.. attribute:: AdminSite.password_change_done_template
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Path to a custom template that will be used by the admin site password
|
||||
change done view.
|
||||
|
||||
|
|
|
@ -37,8 +37,6 @@ available in the context, then you can refer to it directly::
|
|||
{% get_comment_count for entry as comment_count %}
|
||||
<p>{{ comment_count }} comments have been posted.</p>
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Next, we can use the :ttag:`render_comment_list` tag, to render all comments
|
||||
to the given instance (``entry``) by using the ``comments/list.html`` template::
|
||||
|
||||
|
|
|
@ -130,8 +130,6 @@ details.
|
|||
Linking to comments
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
To provide a permalink to a specific comment, use :ttag:`get_comment_permalink`::
|
||||
|
||||
{% get_comment_permalink comment_obj [format_string] %}
|
||||
|
|
|
@ -434,8 +434,6 @@ A number of settings can be used to control Django's CSRF behavior.
|
|||
CSRF_COOKIE_DOMAIN
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``None``
|
||||
|
||||
The domain to be used when setting the CSRF cookie. This can be useful for
|
||||
|
@ -450,8 +448,6 @@ mechanism is not safe against cross-subdomain attacks -- see `Limitations`_.
|
|||
CSRF_COOKIE_NAME
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'csrftoken'``
|
||||
|
||||
The name of the cookie to use for the CSRF authentication token. This can be
|
||||
|
@ -485,8 +481,6 @@ cookie is only sent under an HTTPS connection.
|
|||
CSRF_FAILURE_VIEW
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'django.views.csrf.csrf_failure'``
|
||||
|
||||
A dotted path to the view function to be used when an incoming request
|
||||
|
|
|
@ -110,8 +110,6 @@ default templates.
|
|||
Advanced ``FormPreview`` methods
|
||||
================================
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. method:: FormPreview.process_preview
|
||||
|
||||
Given a validated form, performs any extra processing before displaying the
|
||||
|
|
|
@ -12,11 +12,7 @@ GeoDjango Database API
|
|||
Spatial Backends
|
||||
================
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
In Django 1.2, support for :doc:`multiple databases </topics/db/multi-db>` was
|
||||
introduced. In order to support multiple databases, GeoDjango has segregated
|
||||
its functionality into full-fledged spatial database backends:
|
||||
GeoDjango currently provides the following spatial database backends:
|
||||
|
||||
* :mod:`django.contrib.gis.db.backends.postgis`
|
||||
* :mod:`django.contrib.gis.db.backends.mysql`
|
||||
|
|
|
@ -212,8 +212,6 @@ __ http://www.gdal.org/ogr/ogr_formats.html
|
|||
|
||||
.. attribute:: spatial_filter
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Property that may be used to retrieve or set a spatial filter for this
|
||||
layer. A spatial filter can only be set with an :class:`OGRGeometry`
|
||||
instance, a 4-tuple extent, or ``None``. When set with something
|
||||
|
@ -490,15 +488,9 @@ systems and coordinate transformation::
|
|||
|
||||
.. attribute:: coord_dim
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
Returns or sets the coordinate dimension of this geometry. For
|
||||
example, the value would be 2 for two-dimensional geometries.
|
||||
|
||||
.. note::
|
||||
|
||||
Setting this property is only available in versions 1.2 and above.
|
||||
|
||||
.. attribute:: geom_count
|
||||
|
||||
Returns the number of elements in this geometry::
|
||||
|
@ -619,8 +611,6 @@ systems and coordinate transformation::
|
|||
|
||||
.. attribute:: ewkt
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Returns the EWKT representation of this geometry.
|
||||
|
||||
.. method:: clone()
|
||||
|
|
|
@ -117,8 +117,6 @@ SpatiaLite ``Contains(poly, geom)``
|
|||
contains_properly
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
*Availability*: PostGIS
|
||||
|
||||
Returns true if the lookup geometry intersects the interior of the
|
||||
|
@ -803,8 +801,6 @@ Geometry Editors
|
|||
|
||||
.. method:: GeoQuerySet.force_rhr(**kwargs)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
*Availability*: PostGIS
|
||||
|
||||
Returns a modified version of the polygon/multipolygon in which all
|
||||
|
@ -816,8 +812,6 @@ of the vertices follow the Right-Hand-Rule, and attaches as a
|
|||
|
||||
.. method:: GeoQuerySet.reverse_geom(**kwargs)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
*Availability*: PostGIS, Oracle
|
||||
|
||||
Reverse the coordinate order of the geometry field, and attaches as a
|
||||
|
@ -943,8 +937,6 @@ of the geometry field in each model converted to the requested output format.
|
|||
|
||||
.. method:: GeoQuerySet.geohash(precision=20, **kwargs)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Attaches a ``geohash`` attribute to every model the queryset
|
||||
containing the `GeoHash`__ representation of the geometry.
|
||||
|
||||
|
@ -1136,8 +1128,6 @@ Example::
|
|||
|
||||
.. method:: GeoQuerySet.extent3d(**kwargs)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
*Availability*: PostGIS
|
||||
|
||||
Returns the 3D extent of the ``GeoQuerySet`` as a six-tuple, comprising
|
||||
|
@ -1224,8 +1214,6 @@ Returns the same as the :meth:`GeoQuerySet.extent` aggregate method.
|
|||
|
||||
.. class:: Extent3D(geo_field)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Returns the same as the :meth:`GeoQuerySet.extent3d` aggregate method.
|
||||
|
||||
``MakeLine``
|
||||
|
|
|
@ -265,8 +265,6 @@ because it is not a part of the OGC specification (use the
|
|||
|
||||
.. attribute:: GEOSGeometry.hexewkb
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Returns the EWKB of this Geometry in hexadecimal form. This is an
|
||||
extension of the WKB specification that includes SRID and Z values
|
||||
that are a part of this geometry.
|
||||
|
@ -314,8 +312,6 @@ as a Python buffer. SRID and Z values are not included, use the
|
|||
|
||||
.. attribute:: GEOSGeometry.ewkb
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Return the EWKB representation of this Geometry as a Python buffer.
|
||||
This is an extension of the WKB specification that includes any SRID
|
||||
and Z values that are a part of this geometry.
|
||||
|
|
|
@ -624,8 +624,6 @@ features such as the geographic admin or KML sitemaps will not function properly
|
|||
Add Google projection to ``spatial_ref_sys`` table
|
||||
--------------------------------------------------
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
.. note::
|
||||
|
||||
If you're running PostGIS 1.4 or above, you can skip this step. The entry
|
||||
|
|
|
@ -163,8 +163,6 @@ field.
|
|||
``dim``
|
||||
-------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. attribute:: GeometryField.dim
|
||||
|
||||
This option may be used for customizing the coordinate dimension of the
|
||||
|
@ -180,8 +178,6 @@ three-dimensonal support.
|
|||
``geography``
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. attribute:: GeometryField.geography
|
||||
|
||||
If set to ``True``, this option will create a database column of
|
||||
|
|
|
@ -2,12 +2,6 @@
|
|||
Testing GeoDjango apps
|
||||
======================
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
In Django 1.2, the addition of :ref:`spatial-backends` simplified the
|
||||
process of testing GeoDjango applications. The process is now the
|
||||
same as :doc:`/topics/testing`.
|
||||
|
||||
Included in this documentation are some additional notes and settings
|
||||
for :ref:`testing-postgis` and :ref:`testing-spatialite` users.
|
||||
|
||||
|
@ -28,11 +22,9 @@ Settings
|
|||
``POSTGIS_TEMPLATE``
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
This setting may be used to customize the name of the PostGIS template
|
||||
database to use. In Django versions 1.2 and above, it automatically
|
||||
defaults to ``'template_postgis'`` (the same name used in the
|
||||
database to use. It automatically defaults to ``'template_postgis'``
|
||||
(the same name used in the
|
||||
:ref:`installation documentation <spatialdb_template>`).
|
||||
|
||||
.. setting:: POSTGIS_VERSION
|
||||
|
|
|
@ -142,9 +142,6 @@ See the :doc:`markup documentation </ref/contrib/markup>`.
|
|||
messages
|
||||
========
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The messages framework was added.
|
||||
|
||||
A framework for storing and retrieving temporary cookie- or session-based
|
||||
messages
|
||||
|
||||
|
|
|
@ -12,9 +12,6 @@ in a subsequent request (usually the next one). Every message is tagged
|
|||
with a specific ``level`` that determines its priority (e.g., ``info``,
|
||||
``warning``, or ``error``).
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The messages framework was added.
|
||||
|
||||
Enabling messages
|
||||
=================
|
||||
|
||||
|
|
|
@ -22,10 +22,6 @@ lower-level way.
|
|||
The high-level framework
|
||||
========================
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The high-level feeds framework was refactored in Django 1.2. The
|
||||
pre-1.2 interface has been removed in Django 1.4.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
|
@ -176,9 +172,6 @@ These can be matched with a :doc:`URLconf </topics/http/urls>` line such as::
|
|||
Like a view, the arguments in the URL are passed to the ``get_object()``
|
||||
method along with the request object.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Prior to version 1.2, ``get_object()`` only accepted a ``bits`` argument.
|
||||
|
||||
Here's the code for these beat-specific feeds::
|
||||
|
||||
from django.contrib.syndication.views import FeedDoesNotExist
|
||||
|
|
|
@ -373,15 +373,6 @@ these methods in no-op's based in the results of such detection.
|
|||
Notes on specific fields
|
||||
------------------------
|
||||
|
||||
Boolean fields
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
In previous versions of Django when running under MySQL ``BooleanFields`` would
|
||||
return their data as ``ints``, instead of true ``bools``. See the release
|
||||
notes for a complete description of the change.
|
||||
|
||||
Character fields
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
@ -119,8 +119,6 @@ createcachetable
|
|||
Creates a cache table named ``tablename`` for use with the database cache
|
||||
backend. See :doc:`/topics/cache` for more information.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database
|
||||
onto which the cachetable will be installed.
|
||||
|
||||
|
@ -142,8 +140,6 @@ the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
|
|||
the right place. There's no way to specify the location of the program
|
||||
manually.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database
|
||||
onto which to open a shell.
|
||||
|
||||
|
@ -212,15 +208,11 @@ name to ``dumpdata``, the dumped output will be restricted to that model,
|
|||
rather than the entire application. You can also mix application names and
|
||||
model names.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database
|
||||
from which data will be dumped.
|
||||
|
||||
.. django-admin-option:: --natural
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Use :ref:`natural keys <topics-serialization-natural-keys>` to represent
|
||||
any foreign key and many-to-many relationship with a model that provides
|
||||
a natural key definition. If you are dumping ``contrib.auth`` ``Permission``
|
||||
|
@ -240,8 +232,6 @@ fixture will be re-installed.
|
|||
The :djadminopt:`--noinput` option may be provided to suppress all user
|
||||
prompts.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option may be used to specify the database
|
||||
to flush.
|
||||
|
||||
|
@ -296,8 +286,6 @@ needed.
|
|||
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
|
||||
only works in PostgreSQL and with certain types of MySQL tables.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option may be used to specify the
|
||||
database to introspect.
|
||||
|
||||
|
@ -308,8 +296,6 @@ loaddata <fixture fixture ...>
|
|||
|
||||
Searches for and loads the contents of the named fixture into the database.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database
|
||||
onto which the data will be loaded.
|
||||
|
||||
|
@ -452,8 +438,6 @@ Currently supported:
|
|||
|
||||
.. django-admin-option:: --symlinks
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Use the ``--symlinks`` or ``-s`` option to follow symlinks to directories when
|
||||
looking for new translation strings.
|
||||
|
||||
|
@ -768,8 +752,6 @@ sql <appname appname ...>
|
|||
|
||||
Prints the CREATE TABLE SQL statements for the given app name(s).
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -783,8 +765,6 @@ Prints the CREATE TABLE and initial-data SQL statements for the given app name(s
|
|||
Refer to the description of ``sqlcustom`` for an explanation of how to
|
||||
specify initial data.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -795,8 +775,6 @@ sqlclear <appname appname ...>
|
|||
|
||||
Prints the DROP TABLE SQL statements for the given app name(s).
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -821,8 +799,6 @@ table modifications, or insert any SQL functions into the database.
|
|||
|
||||
Note that the order in which the SQL files are processed is undefined.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -834,8 +810,6 @@ sqlflush
|
|||
Prints the SQL statements that would be executed for the :djadmin:`flush`
|
||||
command.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -846,8 +820,6 @@ sqlindexes <appname appname ...>
|
|||
|
||||
Prints the CREATE INDEX SQL statements for the given app name(s).
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -864,8 +836,6 @@ number for automatically incremented fields.
|
|||
Use this command to generate SQL which will fix cases where a sequence is out
|
||||
of sync with its automatically incremented field data.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database for
|
||||
which to print the SQL.
|
||||
|
||||
|
@ -1027,8 +997,6 @@ data files.
|
|||
The :djadminopt:`--noinput` option may be provided to suppress all user
|
||||
prompts.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The :djadminopt:`--database` option can be used to specify the database to
|
||||
synchronize.
|
||||
|
||||
|
@ -1047,7 +1015,6 @@ test <app or test identifier>
|
|||
Runs tests for all installed models. See :doc:`/topics/testing` for more
|
||||
information.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
.. django-admin-option:: --failfast
|
||||
|
||||
The ``--failfast`` option can be used to stop running tests and report the
|
||||
|
@ -1155,8 +1122,6 @@ changepassword
|
|||
|
||||
.. django-admin:: changepassword
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
This command is only available if Django's :doc:`authentication system
|
||||
</topics/auth>` (``django.contrib.auth``) is installed.
|
||||
|
||||
|
@ -1317,8 +1282,6 @@ to a number of commands.
|
|||
|
||||
.. django-admin-option:: --database
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Used to specify the database on which a command will operate. If not
|
||||
specified, this option will default to an alias of ``default``.
|
||||
|
||||
|
|
|
@ -377,8 +377,6 @@ a form object, and each rendering method returns a Unicode object.
|
|||
Styling required or erroneous form rows
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
It's pretty common to style form rows and fields that are required or have
|
||||
errors. For example, you might want to present required form rows in bold and
|
||||
highlight errors in red.
|
||||
|
@ -638,8 +636,6 @@ For a field's list of errors, access the field's ``errors`` attribute.
|
|||
|
||||
.. method:: BoundField.css_classes()
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
When you use Django's rendering shortcuts, CSS classes are used to
|
||||
indicate required form fields or fields that contain errors. If you're
|
||||
manually rendering a form, you can access these CSS classes using the
|
||||
|
|
|
@ -256,8 +256,6 @@ error message keys it uses.
|
|||
``validators``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. attribute:: Field.validators
|
||||
|
||||
The ``validators`` argument lets you provide a list of validation functions
|
||||
|
@ -268,8 +266,6 @@ See the :doc:`validators documentation </ref/validators>` for more information.
|
|||
``localize``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. attribute:: Field.localize
|
||||
|
||||
The ``localize`` argument enables the localization of form data, input as well
|
||||
|
@ -492,11 +488,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
If provided, these arguments ensure that the string is at most or at least the
|
||||
given length.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The EmailField previously did not recognize email addresses as valid that
|
||||
contained an IDN (Internationalized Domain Name; a domain containing
|
||||
unicode characters) domain part. This has now been corrected.
|
||||
|
||||
``FileField``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
|
@ -815,11 +806,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
|
||||
These are the same as ``CharField.max_length`` and ``CharField.min_length``.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The URLField previously did not recognize URLs as valid that contained an IDN
|
||||
(Internationalized Domain Name; a domain name containing unicode characters)
|
||||
domain name. This has now been corrected.
|
||||
|
||||
|
||||
Slightly complex built-in ``Field`` classes
|
||||
-------------------------------------------
|
||||
|
|
|
@ -1,8 +1,6 @@
|
|||
Form and field validation
|
||||
=========================
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
Form validation happens when the data is cleaned. If you want to customize
|
||||
this process, there are various places you can change, each one serving a
|
||||
different purpose. Three types of cleaning methods are run during form
|
||||
|
@ -175,7 +173,6 @@ previous features.
|
|||
|
||||
Using validators
|
||||
~~~~~~~~~~~~~~~~
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Django's form (and model) fields support use of simple utility functions and
|
||||
classes known as validators. These can be passed to a field's constructor, via
|
||||
|
|
|
@ -156,9 +156,6 @@ Message middleware
|
|||
|
||||
.. class:: MessageMiddleware
|
||||
|
||||
.. versionadded:: 1.2
|
||||
``MessageMiddleware`` was added.
|
||||
|
||||
Enables cookie- and session-based message support. See the
|
||||
:doc:`messages documentation </ref/contrib/messages>`.
|
||||
|
||||
|
|
|
@ -208,8 +208,6 @@ automatically generated from the model class. Default is ``True``.
|
|||
``error_messages``
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. attribute:: Field.error_messages
|
||||
|
||||
The ``error_messages`` argument lets you override the default messages that the
|
||||
|
@ -309,8 +307,6 @@ underscores to spaces. See :ref:`Verbose field names <verbose-field-names>`.
|
|||
``validators``
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. attribute:: Field.validators
|
||||
|
||||
A list of validators to run for this field. See the :doc:`validators
|
||||
|
@ -336,8 +332,6 @@ otherwise. See :ref:`automatic-primary-key-fields`.
|
|||
``BigIntegerField``
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. class:: BigIntegerField([**options])
|
||||
|
||||
A 64 bit integer, much like an :class:`IntegerField` except that it is
|
||||
|
@ -357,11 +351,6 @@ The admin represents this as a checkbox.
|
|||
If you need to accept :attr:`~Field.null` values then use
|
||||
:class:`NullBooleanField` instead.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
In previous versions of Django when running under MySQL ``BooleanFields``
|
||||
would return their data as ``ints``, instead of true ``bools``. See the
|
||||
release notes for a complete description of the change.
|
||||
|
||||
``CharField``
|
||||
-------------
|
||||
|
||||
|
|
|
@ -30,8 +30,6 @@ that, you need to :meth:`~Model.save()`.
|
|||
Validating objects
|
||||
==================
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
There are three steps involved in validating a model:
|
||||
|
||||
1. Validate the model fields
|
||||
|
@ -137,9 +135,6 @@ To save an object back to the database, call ``save()``:
|
|||
|
||||
.. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None])
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``using`` argument was added.
|
||||
|
||||
If you want customized saving behavior, you can override this ``save()``
|
||||
method. See :ref:`overriding-model-methods` for more details.
|
||||
|
||||
|
@ -361,9 +356,6 @@ Deleting objects
|
|||
|
||||
.. method:: Model.delete([using=DEFAULT_DB_ALIAS])
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``using`` argument was added.
|
||||
|
||||
Issues a SQL ``DELETE`` for the object. This only deletes the object in the
|
||||
database; the Python instance will still exist and will still have data in
|
||||
its fields.
|
||||
|
|
|
@ -727,8 +727,6 @@ passed to ``select_related()``. This includes foreign keys that have
|
|||
It's an error to use both a list of fields and the ``depth`` parameter in the
|
||||
same ``select_related()`` call; they are conflicting options.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
You can also refer to the reverse direction of a
|
||||
:class:`~django.db.models.OneToOneField` in the list of fields passed to
|
||||
``select_related`` — that is, you can traverse a
|
||||
|
@ -1156,8 +1154,6 @@ using
|
|||
|
||||
.. method:: using(alias)
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
This method is for controlling which database the ``QuerySet`` will be
|
||||
evaluated against if you are using more than one database. The only argument
|
||||
this method takes is the alias of a database, as defined in
|
||||
|
@ -1512,8 +1508,6 @@ exists
|
|||
|
||||
.. method:: exists()
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Returns ``True`` if the :class:`.QuerySet` contains any results, and ``False``
|
||||
if not. This tries to perform the query in the simplest and fastest way
|
||||
possible, but it *does* execute nearly the same query. This means that calling
|
||||
|
|
|
@ -307,8 +307,6 @@ See :doc:`/topics/cache`.
|
|||
CSRF_COOKIE_DOMAIN
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``None``
|
||||
|
||||
The domain to be used when setting the CSRF cookie. This can be useful for
|
||||
|
@ -326,8 +324,6 @@ protection is safe from cross-subdomain attacks by default - please see the
|
|||
CSRF_COOKIE_NAME
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'csrftoken'``
|
||||
|
||||
The name of the cookie to use for the CSRF authentication token. This can be whatever you
|
||||
|
@ -367,8 +363,6 @@ cookie is only sent under an HTTPS connection.
|
|||
CSRF_FAILURE_VIEW
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'django.views.csrf.csrf_failure'``
|
||||
|
||||
A dotted path to the view function to be used when an incoming request
|
||||
|
@ -386,8 +380,6 @@ end users) indicating the reason the request was rejected. See
|
|||
DATABASES
|
||||
---------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``{}`` (Empty dictionary)
|
||||
|
||||
A dictionary containing the settings for all databases to be used with
|
||||
|
@ -430,12 +422,6 @@ You can use a database backend that doesn't ship with Django by setting
|
|||
scratch is left as an exercise to the reader; see the other backends for
|
||||
examples.
|
||||
|
||||
.. note::
|
||||
Prior to Django 1.2, you could use a short version of the backend name
|
||||
to reference the built-in database backends (e.g., you could use
|
||||
``'sqlite3'`` to refer to the SQLite backend). This format has been
|
||||
deprecated, and will be removed in Django 1.4.
|
||||
|
||||
.. setting:: HOST
|
||||
|
||||
HOST
|
||||
|
@ -664,8 +650,6 @@ not provided, Django will use ``'test_' + NAME + '_temp'``.
|
|||
DATABASE_ROUTERS
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``[]`` (Empty list)
|
||||
|
||||
The list of routers that will be used to determine which database
|
||||
|
@ -686,9 +670,6 @@ system. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|||
locale-dictated format has higher precedence and will be applied instead. See
|
||||
:tfilter:`allowed date format strings <date>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.
|
||||
|
||||
See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
||||
|
||||
.. setting:: DATE_INPUT_FORMATS
|
||||
|
@ -696,8 +677,6 @@ See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_
|
|||
DATE_INPUT_FORMATS
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default::
|
||||
|
||||
('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y',
|
||||
|
@ -728,9 +707,6 @@ system. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|||
locale-dictated format has higher precedence and will be applied instead. See
|
||||
:tfilter:`allowed date format strings <date>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.
|
||||
|
||||
See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
||||
|
||||
.. setting:: DATETIME_INPUT_FORMATS
|
||||
|
@ -738,8 +714,6 @@ See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE
|
|||
DATETIME_INPUT_FORMATS
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default::
|
||||
|
||||
('%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M', '%Y-%m-%d',
|
||||
|
@ -823,8 +797,6 @@ site.
|
|||
DECIMAL_SEPARATOR
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'.'`` (Dot)
|
||||
|
||||
Default decimal separator used when formatting decimal numbers.
|
||||
|
@ -926,8 +898,6 @@ This is only used if ``CommonMiddleware`` is installed (see
|
|||
EMAIL_BACKEND
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'django.core.mail.backends.smtp.EmailBackend'``
|
||||
|
||||
The backend to use for sending emails. For the list of available backends see
|
||||
|
@ -938,8 +908,6 @@ The backend to use for sending emails. For the list of available backends see
|
|||
EMAIL_FILE_PATH
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: Not defined
|
||||
|
||||
The directory used by the ``file`` email backend to store output files.
|
||||
|
@ -1086,8 +1054,6 @@ See :doc:`/topics/files` for details.
|
|||
FIRST_DAY_OF_WEEK
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``0`` (Sunday)
|
||||
|
||||
Number representing the first day of the week. This is especially useful
|
||||
|
@ -1127,8 +1093,6 @@ of the preferred value or not supplied at all.
|
|||
FORMAT_MODULE_PATH
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``None``
|
||||
|
||||
A full Python path to a Python package that contains format definitions for
|
||||
|
@ -1426,8 +1390,6 @@ Example: ``"http://media.example.com/"``
|
|||
MESSAGE_LEVEL
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: `messages.INFO`
|
||||
|
||||
Sets the minimum message level that will be recorded by the messages
|
||||
|
@ -1437,8 +1399,6 @@ more details.
|
|||
MESSAGE_STORAGE
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'``
|
||||
|
||||
Controls where Django stores message data. See the
|
||||
|
@ -1447,8 +1407,6 @@ Controls where Django stores message data. See the
|
|||
MESSAGE_TAGS
|
||||
------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default::
|
||||
|
||||
{messages.DEBUG: 'debug',
|
||||
|
@ -1475,11 +1433,6 @@ Default::
|
|||
|
||||
A tuple of middleware classes to use. See :doc:`/topics/http/middleware`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
``'django.contrib.messages.middleware.MessageMiddleware'`` was added to the
|
||||
default. For more information, see the :doc:`messages documentation
|
||||
</ref/contrib/messages>`.
|
||||
|
||||
.. setting:: MONTH_DAY_FORMAT
|
||||
|
||||
MONTH_DAY_FORMAT
|
||||
|
@ -1505,8 +1458,6 @@ See :tfilter:`allowed date format strings <date>`. See also
|
|||
NUMBER_GROUPING
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``0``
|
||||
|
||||
Number of digits grouped together on the integer part of a number.
|
||||
|
@ -1820,8 +1771,6 @@ Whether to save the session data on every request. See
|
|||
SHORT_DATE_FORMAT
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``m/d/Y`` (e.g. ``12/31/2003``)
|
||||
|
||||
An available formatting that can be used for displaying date fields on
|
||||
|
@ -1836,8 +1785,6 @@ See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
|||
SHORT_DATETIME_FORMAT
|
||||
---------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``m/d/Y P`` (e.g. ``12/31/2003 4 p.m.``)
|
||||
|
||||
An available formatting that can be used for displaying datetime fields on
|
||||
|
@ -1944,16 +1891,6 @@ A tuple of callables that are used to populate the context in ``RequestContext``
|
|||
These callables take a request object as their argument and return a dictionary
|
||||
of items to be merged into the context.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
``django.contrib.messages.context_processors.messages`` was added to the
|
||||
default. For more information, see the :doc:`messages documentation
|
||||
</ref/contrib/messages>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The auth context processor was moved in this release from its old location
|
||||
``django.core.context_processors.auth`` to
|
||||
``django.contrib.auth.context_processors.auth``.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
The ``django.core.context_processors.static`` context processor
|
||||
was added in this release.
|
||||
|
@ -2009,12 +1946,6 @@ used instead of a string. The first item in the tuple should be the ``Loader``'s
|
|||
module, subsequent items are passed to the ``Loader`` during initialization. See
|
||||
:doc:`/ref/templates/api`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The class-based API for template loaders was introduced in Django 1.2
|
||||
although the :setting:`TEMPLATE_LOADERS` setting will accept strings
|
||||
that specify function-based loaders until compatibility with them is
|
||||
completely removed in Django 1.4.
|
||||
|
||||
.. setting:: TEMPLATE_STRING_IF_INVALID
|
||||
|
||||
TEMPLATE_STRING_IF_INVALID
|
||||
|
@ -2032,9 +1963,6 @@ TEST_RUNNER
|
|||
|
||||
Default: ``'django.test.simple.DjangoTestSuiteRunner'``
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Prior to 1.2, test runners were a function, not a class.
|
||||
|
||||
The name of the class to use for starting the test suite. See
|
||||
:doc:`/topics/testing`.
|
||||
|
||||
|
@ -2045,8 +1973,6 @@ The name of the class to use for starting the test suite. See
|
|||
THOUSAND_SEPARATOR
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``,`` (Comma)
|
||||
|
||||
Default thousand separator used when formatting numbers. This setting is
|
||||
|
@ -2071,9 +1997,6 @@ system. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|||
locale-dictated format has higher precedence and will be applied instead. See
|
||||
:tfilter:`allowed date format strings <date>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.
|
||||
|
||||
See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`.
|
||||
|
||||
.. setting:: TIME_INPUT_FORMATS
|
||||
|
@ -2081,8 +2004,6 @@ See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`.
|
|||
TIME_INPUT_FORMATS
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``('%H:%M:%S', '%H:%M')``
|
||||
|
||||
A tuple of formats that will be accepted when inputting data on a time field.
|
||||
|
@ -2104,9 +2025,6 @@ TIME_ZONE
|
|||
|
||||
Default: ``'America/Chicago'``
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
``None`` was added as an allowed value.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
The meaning of this setting now depends on the value of :setting:`USE_TZ`.
|
||||
|
||||
|
@ -2183,8 +2101,6 @@ See also :setting:`LANGUAGE_CODE`, :setting:`USE_L10N` and :setting:`USE_TZ`.
|
|||
USE_L10N
|
||||
--------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies if localized formatting of data will be enabled by
|
||||
|
@ -2203,8 +2119,6 @@ See also :setting:`LANGUAGE_CODE`, :setting:`USE_I18N` and :setting:`USE_TZ`.
|
|||
USE_THOUSAND_SEPARATOR
|
||||
----------------------
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies whether to display numbers using a thousand separator.
|
||||
|
|
|
@ -220,8 +220,6 @@ m2m_changed
|
|||
.. data:: django.db.models.signals.m2m_changed
|
||||
:module:
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Sent when a :class:`ManyToManyField` is changed on a model instance.
|
||||
Strictly speaking, this is not a model signal since it is sent by the
|
||||
:class:`ManyToManyField`, but since it complements the
|
||||
|
@ -544,9 +542,6 @@ connection_created
|
|||
.. data:: django.db.backends.signals.connection_created
|
||||
:module:
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The connection argument was added
|
||||
|
||||
Sent when the database wrapper makes the initial connection to the
|
||||
database. This is particularly useful if you'd like to send any post
|
||||
connection commands to the SQL backend.
|
||||
|
|
|
@ -372,21 +372,11 @@ and return a dictionary of items to be merged into the context. By default,
|
|||
"django.core.context_processors.static",
|
||||
"django.contrib.messages.context_processors.messages")
|
||||
|
||||
.. versionadded:: 1.2
|
||||
In addition to these, ``RequestContext`` always uses
|
||||
``django.core.context_processors.csrf``. This is a security
|
||||
related context processor required by the admin and other contrib apps, and,
|
||||
in case of accidental misconfiguration, it is deliberately hardcoded in and
|
||||
cannot be turned off by the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``'messages'`` context processor was added. For more information, see
|
||||
the :doc:`messages documentation </ref/contrib/messages>`.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The auth context processor was moved in this release from its old location
|
||||
``django.core.context_processors.auth`` to
|
||||
``django.contrib.auth.context_processors.auth``.
|
||||
In addition to these, ``RequestContext`` always uses
|
||||
``django.core.context_processors.csrf``. This is a security
|
||||
related context processor required by the admin and other contrib apps, and,
|
||||
in case of accidental misconfiguration, it is deliberately hardcoded in and
|
||||
cannot be turned off by the :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting.
|
||||
|
||||
Each processor is applied in order. That means, if one processor adds a
|
||||
variable to the context and a second processor adds a variable with the same
|
||||
|
@ -447,10 +437,6 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
|
|||
``django.contrib.auth.context_processors.PermWrapper``, representing the
|
||||
permissions that the currently logged-in user has.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
This context processor was moved in this release from
|
||||
``django.core.context_processors.auth`` to its current location.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Prior to version 1.3, ``PermWrapper`` was located in
|
||||
``django.contrib.auth.context_processors``.
|
||||
|
@ -503,8 +489,6 @@ value of the :setting:`STATIC_URL` setting.
|
|||
django.core.context_processors.csrf
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
This processor adds a token that is needed by the :ttag:`csrf_token` template
|
||||
tag for protection against :doc:`Cross Site Request Forgeries
|
||||
</ref/contrib/csrf>`.
|
||||
|
@ -527,15 +511,6 @@ If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
|
|||
via the user model (using ``user.message_set.create``) or through
|
||||
the :doc:`messages framework </ref/contrib/messages>`.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
This template context variable was previously supplied by the ``'auth'``
|
||||
context processor. For backwards compatibility the ``'auth'`` context
|
||||
processor will continue to supply the ``messages`` variable until Django
|
||||
1.4. If you use the ``messages`` variable, your project will work with
|
||||
either (or both) context processors, but it is recommended to add
|
||||
``django.contrib.messages.context_processors.messages`` so your project
|
||||
will be prepared for the future upgrade.
|
||||
|
||||
Writing your own context processors
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -657,11 +632,6 @@ by editing your :setting:`TEMPLATE_LOADERS` setting. :setting:`TEMPLATE_LOADERS`
|
|||
should be a tuple of strings, where each string represents a template loader
|
||||
class. Here are the template loaders that come with Django:
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Template loaders were based on callables (usually functions) before Django
|
||||
1.2, starting with the 1.2 release there is a new class-based API, all the
|
||||
loaders described below implement this new API.
|
||||
|
||||
``django.template.loaders.filesystem.Loader``
|
||||
Loads templates from the filesystem, according to :setting:`TEMPLATE_DIRS`.
|
||||
This loader is enabled by default.
|
||||
|
@ -800,8 +770,6 @@ and any setting starting with ``TEMPLATE_`` is of obvious interest.
|
|||
Using an alternative template language
|
||||
======================================
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The Django ``Template`` and ``Loader`` classes implement a simple API for
|
||||
loading and rendering templates. By providing some simple wrapper classes that
|
||||
implement this API we can use third party template systems like `Jinja2
|
||||
|
|
|
@ -58,10 +58,8 @@ Ignores everything between ``{% comment %}`` and ``{% endcomment %}``.
|
|||
csrf_token
|
||||
^^^^^^^^^^
|
||||
|
||||
In the Django 1.1.X series, this is a no-op tag that returns an empty string
|
||||
for future compatibility purposes. In Django 1.2 and later, it is used for
|
||||
CSRF protection, as described in the documentation for :doc:`Cross Site Request
|
||||
Forgeries </ref/contrib/csrf>`.
|
||||
This tag is used for CSRF protection, as described in the documentation for
|
||||
:doc:`Cross Site Request Forgeries </ref/contrib/csrf>`.
|
||||
|
||||
.. templatetag:: cycle
|
||||
|
||||
|
@ -410,8 +408,6 @@ variables or to negate a given variable::
|
|||
There are some athletes and absolutely no coaches.
|
||||
{% endif %}
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
Use of both ``and`` and ``or`` clauses within the same tag is allowed, with
|
||||
``and`` having higher precedence than ``or`` e.g.::
|
||||
|
||||
|
@ -426,9 +422,6 @@ will be interpreted like:
|
|||
Use of actual brackets in the :ttag:`if` tag is invalid syntax. If you need
|
||||
them to indicate precedence, you should use nested :ttag:`if` tags.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
|
||||
:ttag:`if` tags may also use the operators ``==``, ``!=``, ``<``, ``>``,
|
||||
``<=``, ``>=`` and ``in`` which work as follows:
|
||||
|
||||
|
@ -637,9 +630,8 @@ You cannot check for equality with Python objects such as ``True`` or
|
|||
``False``. If you need to test if something is true or false, use the
|
||||
:ttag:`if` tag instead.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
An alternative to the ``ifequal`` tag is to use the :ttag:`if` tag and the
|
||||
``==`` operator.
|
||||
An alternative to the ``ifequal`` tag is to use the :ttag:`if` tag and the
|
||||
``==`` operator.
|
||||
|
||||
.. templatetag:: ifnotequal
|
||||
|
||||
|
@ -649,9 +641,8 @@ ifnotequal
|
|||
Just like :ttag:`ifequal`, except it tests that the two arguments are not
|
||||
equal.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
An alternative to the ``ifnotequal`` tag is to use the :ttag:`if` tag and
|
||||
the ``!=`` operator.
|
||||
An alternative to the ``ifnotequal`` tag is to use the :ttag:`if` tag and
|
||||
the ``!=`` operator.
|
||||
|
||||
.. templatetag:: include
|
||||
|
||||
|
@ -1127,9 +1118,6 @@ For example::
|
|||
|
||||
If ``value`` is ``4``, then the output will be ``6``.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The following behavior didn't exist in previous Django versions.
|
||||
|
||||
This filter will first try to coerce both values to integers. If this fails,
|
||||
it'll attempt to add the values together anyway. This will work on some data
|
||||
types (strings, list, etc.) and fail on others. If it fails, the result will
|
||||
|
@ -1289,10 +1277,6 @@ Z Time zone offset in seconds. The ``-43200`` to ``4320
|
|||
UTC is always positive.
|
||||
================ ======================================== =====================
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The ``c`` and ``u`` format specification characters were added in Django 1.2.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
The ``e`` and ``o`` format specification characters were added in Django 1.4.
|
||||
|
@ -1326,9 +1310,6 @@ When used without a format string::
|
|||
...the formatting string defined in the :setting:`DATE_FORMAT` setting will be
|
||||
used, without applying any localization.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Predefined formats can now be influenced by the current locale.
|
||||
|
||||
.. templatefilter:: default
|
||||
|
||||
default
|
||||
|
@ -1985,9 +1966,6 @@ When used without a format string::
|
|||
...the formatting string defined in the :setting:`TIME_FORMAT` setting will be
|
||||
used, without applying any localization.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Predefined formats can now be influenced by the current locale.
|
||||
|
||||
.. templatefilter:: timesince
|
||||
|
||||
timesince
|
||||
|
|
|
@ -2,7 +2,6 @@
|
|||
Validators
|
||||
==========
|
||||
|
||||
.. versionadded:: 1.2
|
||||
.. module:: django.core.validators
|
||||
:synopsis: Validation utilities and base classes
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue