Fixed #14000 - remove versionadded/changed tags for Django 1.0 and 1.1
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15055 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
00c554f89e
commit
2ea93f9327
|
@ -2,8 +2,6 @@
|
|||
Writing custom django-admin commands
|
||||
====================================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Applications can register their own actions with ``manage.py``. For example,
|
||||
you might want to add a ``manage.py`` action for a Django app that you're
|
||||
distributing. In this document, we will be building a custom ``closepoll``
|
||||
|
|
|
@ -2,7 +2,6 @@
|
|||
Writing custom model fields
|
||||
===========================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
.. currentmodule:: django.db.models
|
||||
|
||||
Introduction
|
||||
|
|
|
@ -155,8 +155,6 @@ will use the function's name as the filter name.
|
|||
Filters and auto-escaping
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When writing a custom filter, give some thought to how the filter will interact
|
||||
with Django's auto-escaping behavior. Note that three types of strings can be
|
||||
passed around inside the template code:
|
||||
|
@ -426,8 +424,6 @@ without having to be parsed multiple times.
|
|||
Auto-escaping considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The output from template tags is **not** automatically run through the
|
||||
auto-escaping filters. However, there are still a couple of things you should
|
||||
keep in mind when writing a template tag.
|
||||
|
@ -605,10 +601,6 @@ Now your tag should begin to look like this::
|
|||
raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name
|
||||
return FormatTimeNode(date_to_be_formatted, format_string[1:-1])
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Variable resolution has changed in the 1.0 release of Django. ``template.resolve_variable()``
|
||||
has been deprecated in favor of a new ``template.Variable`` class.
|
||||
|
||||
You also have to change the renderer to retrieve the actual contents of the
|
||||
``date_updated`` property of the ``blog_entry`` object. This can be
|
||||
accomplished by using the ``Variable()`` class in ``django.template``.
|
||||
|
|
|
@ -64,9 +64,6 @@ This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the
|
|||
Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE
|
||||
<django-settings-module>` so mod_python knows which settings to use.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``PythonOption django.root ...`` is new in this version.
|
||||
|
||||
Because mod_python does not know we are serving this site from underneath the
|
||||
``/mysite/`` prefix, this value needs to be passed through to the mod_python
|
||||
handler in Django, via the ``PythonOption django.root ...`` line. The value set
|
||||
|
|
|
@ -38,9 +38,6 @@ activate the admin site for your installation, do these three things:
|
|||
need to know is that it maps URL roots to applications. In the end, you
|
||||
should have a ``urls.py`` file that looks like this:
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The method for adding admin urls has changed in Django 1.1.
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
from django.conf.urls.defaults import *
|
||||
|
|
|
@ -26,8 +26,6 @@ The following backends are available in :mod:`django.contrib.auth.backends`:
|
|||
|
||||
.. class:: RemoteUserBackend
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Use this backend to take advantage of external-to-Django-handled
|
||||
authentication. It authenticates using usernames passed in
|
||||
:attr:`request.META['REMOTE_USER'] <django.http.HttpRequest.META>`. See
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Admin actions
|
||||
=============
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. currentmodule:: django.contrib.admin
|
||||
|
||||
The basic workflow of Django's admin is, in a nutshell, "select an object,
|
||||
|
|
|
@ -434,8 +434,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.list_editable
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Set ``list_editable`` to a list of field names on the model which will
|
||||
allow editing on the change list page. That is, fields listed in
|
||||
``list_editable`` will be displayed as form widgets on the change list
|
||||
|
@ -678,8 +676,6 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.formfield_overrides
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
This provides a quick-and-dirty way to override some of the
|
||||
:class:`~django.forms.Field` options for use in the admin.
|
||||
``formfield_overrides`` is a dictionary mapping a field class to a dict of
|
||||
|
@ -722,16 +718,12 @@ subclass::
|
|||
|
||||
.. attribute:: ModelAdmin.actions
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
A list of actions to make available on the change list page. See
|
||||
:doc:`/ref/contrib/admin/actions` for details.
|
||||
|
||||
.. attribute:: ModelAdmin.actions_on_top
|
||||
.. attribute:: ModelAdmin.actions_on_bottom
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Controls where on the page the actions bar appears. By default, the admin
|
||||
changelist displays actions at the top of the page (``actions_on_top = True;
|
||||
actions_on_bottom = False``).
|
||||
|
@ -843,8 +835,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.get_urls(self)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for
|
||||
that ModelAdmin in the same way as a URLconf. Therefore you can extend
|
||||
them as documented in :doc:`/topics/http/urls`::
|
||||
|
@ -903,8 +893,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.formfield_for_foreignkey(self, db_field, request, **kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
The ``formfield_for_foreignkey`` method on a ``ModelAdmin`` allows you to
|
||||
override the default formfield for a foreign key field. For example, to
|
||||
return a subset of objects for this foreign key field based on the user::
|
||||
|
@ -920,8 +908,6 @@ templates used by the :class:`ModelAdmin` views:
|
|||
|
||||
.. method:: ModelAdmin.formfield_for_manytomany(self, db_field, request, **kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Like the ``formfield_for_foreignkey`` method, the
|
||||
``formfield_for_manytomany`` method can be overridden to change the
|
||||
default formfield for a many to many field. For example, if an owner can
|
||||
|
@ -1119,9 +1105,6 @@ adds some of its own (the shared features are actually defined in the
|
|||
- :attr:`~ModelAdmin.prepopulated_fields`
|
||||
- :attr:`~ModelAdmin.radio_fields`
|
||||
- :attr:`~InlineModelAdmin.raw_id_fields`
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
- :meth:`~ModelAdmin.formfield_for_foreignkey`
|
||||
- :meth:`~ModelAdmin.formfield_for_manytomany`
|
||||
|
||||
|
@ -1512,8 +1495,6 @@ creating your own ``AdminSite`` instance (see below), and changing the
|
|||
Python class), and register your models and ``ModelAdmin`` subclasses
|
||||
with it instead of using the default.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
When constructing an instance of an ``AdminSite``, you are able to provide
|
||||
a unique instance name using the ``name`` argument to the constructor. This
|
||||
instance name is used to identify the instance, especially when
|
||||
|
@ -1607,10 +1588,6 @@ It's easy to create multiple instances of the admin site on the same
|
|||
Django-powered Web site. Just create multiple instances of ``AdminSite`` and
|
||||
root each one at a different URL.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The method for hooking ``AdminSite`` instances into urls has changed in
|
||||
Django 1.1.
|
||||
|
||||
In this example, the URLs ``/basic-admin/`` and ``/advanced-admin/`` feature
|
||||
separate versions of the admin site -- using the ``AdminSite`` instances
|
||||
``myproject.admin.basic_site`` and ``myproject.admin.advanced_site``,
|
||||
|
@ -1633,8 +1610,6 @@ is only necessary if you are using more than one ``AdminSite``.
|
|||
Adding views to admin sites
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Just like :class:`ModelAdmin`, :class:`AdminSite` provides a
|
||||
:meth:`~django.contrib.admin.ModelAdmin.get_urls()` method
|
||||
that can be overridden to define additional views for the site. To add
|
||||
|
@ -1654,8 +1629,6 @@ a pattern for your new view.
|
|||
Reversing Admin URLs
|
||||
====================
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
When an :class:`AdminSite` is deployed, the views provided by that site are
|
||||
accessible using Django's :ref:`URL reversing system <naming-url-patterns>`.
|
||||
|
||||
|
|
|
@ -241,7 +241,6 @@ it.
|
|||
Exceptions
|
||||
----------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
.. versionchanged:: 1.2
|
||||
Import paths for the decorators below were changed.
|
||||
|
||||
|
|
|
@ -17,8 +17,6 @@ custom Django application.
|
|||
A flatpage can use a custom template or a default, systemwide flatpage
|
||||
template. It can be associated with one, or multiple, sites.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The content field may optionally be left blank if you prefer to put your
|
||||
content in a custom template.
|
||||
|
||||
|
|
|
@ -5,8 +5,6 @@ Form wizard
|
|||
.. module:: django.contrib.formtools.wizard
|
||||
:synopsis: Splits forms across multiple Web pages.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Django comes with an optional "form wizard" application that splits
|
||||
:doc:`forms </topics/forms/index>` across multiple Web pages. It maintains
|
||||
state in hashed HTML :samp:`<input type="hidden">` fields, and the data isn't
|
||||
|
|
|
@ -459,8 +459,6 @@ systems and coordinate transformation::
|
|||
|
||||
.. classmethod:: from_bbox(bbox)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Constructs a :class:`Polygon` from the given bounding-box (a 4-tuple).
|
||||
|
||||
.. method:: __len__
|
||||
|
@ -601,8 +599,6 @@ systems and coordinate transformation::
|
|||
|
||||
.. attribute:: kml
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Returns a string representation of this geometry in KML format.
|
||||
|
||||
.. attribute:: wkb_size
|
||||
|
@ -889,8 +885,6 @@ systems and coordinate transformation::
|
|||
|
||||
.. method:: expand_to_include(self, *args)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Coordinate System Objects
|
||||
=========================
|
||||
|
||||
|
@ -992,8 +986,6 @@ Coordinate System Objects
|
|||
Import spatial reference from PROJ.4 string.
|
||||
|
||||
.. method:: import_user_input(user_input)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. method:: import_wkt(wkt)
|
||||
|
||||
|
|
|
@ -835,8 +835,6 @@ Reverse the coordinate order of the geometry field, and attaches as a
|
|||
|
||||
.. method:: GeoQuerySet.snap_to_grid(*args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Snap all points of the input geometry to the grid. How the
|
||||
geometry is snapped to the grid depends on how many numeric
|
||||
(either float, integer, or long) arguments are given.
|
||||
|
@ -957,8 +955,6 @@ __ http://geohash.org/
|
|||
|
||||
.. method:: GeoQuerySet.geojson(**kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
*Availability*: PostGIS
|
||||
|
||||
Attaches a ``geojson`` attribute to every model in the queryset that contains the
|
||||
|
@ -1102,7 +1098,6 @@ the ``GeoQuerySet``; otherwise sets with ``None``.
|
|||
|
||||
Spatial Aggregates
|
||||
==================
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Aggregate Methods
|
||||
-----------------
|
||||
|
@ -1112,8 +1107,6 @@ Aggregate Methods
|
|||
|
||||
.. method:: GeoQuerySet.collect(**kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
*Availability*: PostGIS
|
||||
|
||||
Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry
|
||||
|
|
|
@ -33,10 +33,10 @@ features include:
|
|||
* A BSD-licensed interface to the GEOS geometry routines, implemented purely
|
||||
in Python using ``ctypes``.
|
||||
* Loosely-coupled to GeoDjango. For example, :class:`GEOSGeometry` objects
|
||||
may be used outside of a django project/application. In other words,
|
||||
may be used outside of a django project/application. In other words,
|
||||
no need to have ``DJANGO_SETTINGS_MODULE`` set or use a database, etc.
|
||||
* Mutability: :class:`GEOSGeometry` objects may be modified.
|
||||
* Cross-platform and tested; compatible with Windows, Linux, Solaris, and Mac
|
||||
* Cross-platform and tested; compatible with Windows, Linux, Solaris, and Mac
|
||||
OS X platforms.
|
||||
|
||||
.. _geos-tutorial:
|
||||
|
@ -44,7 +44,7 @@ features include:
|
|||
Tutorial
|
||||
========
|
||||
|
||||
This section contains a brief introduction and tutorial to using
|
||||
This section contains a brief introduction and tutorial to using
|
||||
:class:`GEOSGeometry` objects.
|
||||
|
||||
Creating a Geometry
|
||||
|
@ -75,7 +75,7 @@ return a :class:`GEOSGeometry` object from an input string or a file::
|
|||
>>> pnt = fromfile('/path/to/pnt.wkt')
|
||||
>>> pnt = fromfile(open('/path/to/pnt.wkt'))
|
||||
|
||||
Geometries are Pythonic
|
||||
Geometries are Pythonic
|
||||
-----------------------
|
||||
:class:`GEOSGeometry` objects are 'Pythonic', in other words components may
|
||||
be accessed, modified, and iterated over using standard Python conventions.
|
||||
|
@ -146,7 +146,7 @@ are accepted:
|
|||
============= ======================
|
||||
Format Input Type
|
||||
============= ======================
|
||||
WKT / EWKT ``str`` or ``unicode``
|
||||
WKT / EWKT ``str`` or ``unicode``
|
||||
HEX / HEXEWKB ``str`` or ``unicode``
|
||||
WKB / EWKB ``buffer``
|
||||
GeoJSON ``str`` or ``unicode``
|
||||
|
@ -161,7 +161,7 @@ Returns the coordinates of the geometry as a tuple.
|
|||
|
||||
.. attribute:: GEOSGeometry.empty
|
||||
|
||||
Returns whether or not the set of points in the geometry is empty.
|
||||
Returns whether or not the set of points in the geometry is empty.
|
||||
|
||||
.. attribute:: GEOSGeometry.geom_type
|
||||
|
||||
|
@ -219,11 +219,11 @@ definition.
|
|||
|
||||
Returns a boolean indicating whether the geometry is valid.
|
||||
|
||||
.. attribute:: GEOSGeometry.valid_reason
|
||||
.. attribute:: GEOSGeometry.valid_reason
|
||||
|
||||
.. versionadded:: 1.3
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Returns a string describing the reason why a geometry is invalid.
|
||||
Returns a string describing the reason why a geometry is invalid.
|
||||
|
||||
.. attribute:: GEOSGeometry.srid
|
||||
|
||||
|
@ -248,27 +248,27 @@ another object.
|
|||
|
||||
Returns the "extended" Well-Known Text of the geometry. This representation
|
||||
is specific to PostGIS and is a super set of the OGC WKT standard. [#fnogc]_
|
||||
Essentially the SRID is prepended to the WKT representation, for example
|
||||
``SRID=4326;POINT(5 23)``.
|
||||
Essentially the SRID is prepended to the WKT representation, for example
|
||||
``SRID=4326;POINT(5 23)``.
|
||||
|
||||
.. note::
|
||||
|
||||
The output from this property does not include the 3dm, 3dz, and 4d
|
||||
The output from this property does not include the 3dm, 3dz, and 4d
|
||||
information that PostGIS supports in its EWKT representations.
|
||||
|
||||
.. attribute:: GEOSGeometry.hex
|
||||
|
||||
Returns the WKB of this Geometry in hexadecimal form. Please note
|
||||
that the SRID and Z values are not included in this representation
|
||||
because it is not a part of the OGC specification (use the
|
||||
because it is not a part of the OGC specification (use the
|
||||
:attr:`GEOSGeometry.hexewkb` property instead).
|
||||
|
||||
.. 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
|
||||
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.
|
||||
|
||||
.. note::
|
||||
|
@ -290,12 +290,12 @@ Alias for :attr:`GEOSGeometry.json`.
|
|||
.. attribute:: GEOSGeometry.kml
|
||||
|
||||
Returns a `KML`__ (Keyhole Markup Language) representation of the
|
||||
geometry. This should only be used for geometries with an SRID of
|
||||
geometry. This should only be used for geometries with an SRID of
|
||||
4326 (WGS84), but this restriction is not enforced.
|
||||
|
||||
.. attribute:: GEOSGeometry.ogr
|
||||
|
||||
Returns an :class:`~django.contrib.gis.gdal.OGRGeometry` object
|
||||
Returns an :class:`~django.contrib.gis.gdal.OGRGeometry` object
|
||||
correspondg to the GEOS geometry.
|
||||
|
||||
.. note::
|
||||
|
@ -344,7 +344,7 @@ Returns ``True`` if :meth:`GEOSGeometry.within` is ``False``.
|
|||
.. method:: GEOSGeometry.crosses(other)
|
||||
|
||||
Returns ``True`` if the DE-9IM intersection matrix for the two Geometries
|
||||
is ``T*T******`` (for a point and a curve,a point and an area or a line
|
||||
is ``T*T******`` (for a point and a curve,a point and an area or a line
|
||||
and an area) ``0********`` (for two curves).
|
||||
|
||||
.. method:: GEOSGeometry.disjoint(other)
|
||||
|
@ -354,7 +354,7 @@ is ``FF*FF****``.
|
|||
|
||||
.. method:: GEOSGeometry.equals(other)
|
||||
|
||||
Returns ``True`` if the DE-9IM intersection matrix for the two geometries
|
||||
Returns ``True`` if the DE-9IM intersection matrix for the two geometries
|
||||
is ``T*F**FFF*``.
|
||||
|
||||
.. method:: GEOSGeometry.equals_exact(other, tolerance=0)
|
||||
|
@ -377,8 +377,8 @@ is ``T*T***T**`` (for two points or two surfaces) ``1*T***T**``
|
|||
|
||||
.. method:: GEOSGeometry.relate_pattern(other, pattern)
|
||||
|
||||
Returns ``True`` if the elements in the DE-9IM intersection matrix
|
||||
for this geometry and the other matches the given ``pattern`` --
|
||||
Returns ``True`` if the elements in the DE-9IM intersection matrix
|
||||
for this geometry and the other matches the given ``pattern`` --
|
||||
a string of nine characters from the alphabet: {``T``, ``F``, ``*``, ``0``}.
|
||||
|
||||
.. method:: GEOSGeometry.touches(other)
|
||||
|
@ -397,8 +397,8 @@ Topological Methods
|
|||
.. method:: GEOSGeometry.buffer(width, quadsegs=8)
|
||||
|
||||
Returns a :class:`GEOSGeometry` that represents all points whose distance
|
||||
from this geometry is less than or equal to the given ``width``. The optional
|
||||
``quadsegs`` keyword sets the number of segments used to approximate a
|
||||
from this geometry is less than or equal to the given ``width``. The optional
|
||||
``quadsegs`` keyword sets the number of segments used to approximate a
|
||||
quarter circle (defaults is 8).
|
||||
|
||||
.. method:: GEOSGeometry.difference(other)
|
||||
|
@ -423,21 +423,21 @@ algorithm to the specified tolerance. A higher tolerance value implies
|
|||
less points in the output. If no tolerance is tolerance provided,
|
||||
it defaults to 0.
|
||||
|
||||
By default, this function does not preserve topology - e.g.,
|
||||
By default, this function does not preserve topology - e.g.,
|
||||
:class:`Polygon` objects can be split, collapsed into lines or disappear.
|
||||
:class:`Polygon` holes can be created or disappear, and lines can cross.
|
||||
By specifying ``preserve_topology=True``, the result will have the same
|
||||
dimension and number of components as the input, however, this is
|
||||
significantly slower.
|
||||
dimension and number of components as the input, however, this is
|
||||
significantly slower.
|
||||
|
||||
.. method:: GEOSGeometry.sym_difference(other)
|
||||
|
||||
Returns a :class:`GEOSGeometry` combining the points in this geometry
|
||||
Returns a :class:`GEOSGeometry` combining the points in this geometry
|
||||
not in other, and the points in other not in this geometry.
|
||||
|
||||
.. method:: GEOSGeometry.union(other)
|
||||
|
||||
Returns a :class:`GEOSGeometry` representing all the points in this
|
||||
Returns a :class:`GEOSGeometry` representing all the points in this
|
||||
geometry and the other.
|
||||
|
||||
Topological Properties
|
||||
|
@ -477,7 +477,7 @@ This property returns the area of the Geometry.
|
|||
|
||||
.. attribute:: GEOSGeometry.extent
|
||||
|
||||
This property returns the extent of this geometry as a 4-tuple,
|
||||
This property returns the extent of this geometry as a 4-tuple,
|
||||
consisting of (xmin, ymin, xmax, ymax).
|
||||
|
||||
.. method:: GEOSGeometry.clone()
|
||||
|
@ -492,24 +492,22 @@ Returns the distance between the closest points on this geometry and the given
|
|||
.. note::
|
||||
|
||||
GEOS distance calculations are linear -- in other words, GEOS does not
|
||||
perform a spherical calculation even if the SRID specifies a geographic
|
||||
perform a spherical calculation even if the SRID specifies a geographic
|
||||
coordinate system.
|
||||
|
||||
.. attribute:: GEOSGeometry.length
|
||||
|
||||
Returns the length of this geometry (e.g., 0 for a :class:`Point`,
|
||||
the length of a :class:`LineString`, or the circumference of
|
||||
Returns the length of this geometry (e.g., 0 for a :class:`Point`,
|
||||
the length of a :class:`LineString`, or the circumference of
|
||||
a :class:`Polygon`).
|
||||
|
||||
.. attribute:: GEOSGeometry.prepared
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. note::
|
||||
|
||||
Support for prepared geometries requires GEOS 3.1.
|
||||
|
||||
Returns a GEOS ``PreparedGeometry`` for the contents of this geometry.
|
||||
Returns a GEOS ``PreparedGeometry`` for the contents of this geometry.
|
||||
``PreparedGeometry`` objects are optimized for the contains, intersects,
|
||||
and covers operations. Refer to the :ref:`prepared-geometries` documentation
|
||||
for more information.
|
||||
|
@ -529,7 +527,7 @@ corresponding to the SRID of the geometry or ``None``.
|
|||
|
||||
Transforms the geometry according to the given coordinate transformation paramter
|
||||
(``ct``), which may be an integer SRID, spatial reference WKT string,
|
||||
a PROJ.4 string, a :class:`~django.contrib.gis.gdal.SpatialReference` object, or a
|
||||
a PROJ.4 string, a :class:`~django.contrib.gis.gdal.SpatialReference` object, or a
|
||||
:class:`~django.contrib.gis.gdal.CoordTransform` object. By default, the geometry
|
||||
is transformed in-place and nothing is returned. However if the ``clone`` keyword
|
||||
is set, then the geometry is not modified and a transformed clone of the geometry
|
||||
|
@ -611,8 +609,6 @@ is returned instead.
|
|||
|
||||
.. classmethod:: from_bbox(bbox)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Returns a polygon object from the given bounding-box, a 4-tuple
|
||||
comprising (xmin, ymin, xmax, ymax).
|
||||
|
||||
|
@ -651,11 +647,9 @@ Geometry Collections
|
|||
|
||||
.. attribute:: merged
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Returns a :class:`LineString` representing the line merge of
|
||||
all the components in this ``MultiLineString``.
|
||||
|
||||
|
||||
|
||||
``MultiPolygon``
|
||||
----------------
|
||||
|
@ -673,8 +667,6 @@ Geometry Collections
|
|||
|
||||
.. attribute:: cascaded_union
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Returns a :class:`Polygon` that is the union of all of the component
|
||||
polygons in this collection. The algorithm employed is significantly
|
||||
more efficient (faster) than trying to union the geometries together
|
||||
|
@ -702,13 +694,11 @@ Geometry Collections
|
|||
Prepared Geometries
|
||||
===================
|
||||
|
||||
.. versionadded: 1.1
|
||||
|
||||
In order to obtain a prepared geometry, just access the
|
||||
:attr:`GEOSGeometry.prepared` property. Once you have a
|
||||
``PreparedGeometry`` instance its spatial predicate methods, listed below,
|
||||
may be used with other ``GEOSGeometry`` objects. An operation with a prepared
|
||||
geometry can be orders of magnitude faster -- the more complex the geometry
|
||||
geometry can be orders of magnitude faster -- the more complex the geometry
|
||||
that is prepared, the larger the speedup in the operation. For more information,
|
||||
please consult the `GEOS wiki page on prepared geometries <http://trac.osgeo.org/geos/wiki/PreparedGeometry>`_.
|
||||
|
||||
|
@ -770,8 +760,6 @@ Example::
|
|||
I/O Objects
|
||||
===========
|
||||
|
||||
.. versionadded: 1.1
|
||||
|
||||
Reader Objects
|
||||
--------------
|
||||
|
||||
|
@ -807,7 +795,7 @@ include the SRID and 3D values (in other words, EWKB).
|
|||
.. class:: WKBWriter
|
||||
|
||||
``WKBWriter`` provides the most control over its output. By default it
|
||||
returns OGC-compliant WKB when it's ``write`` method is called. However,
|
||||
returns OGC-compliant WKB when it's ``write`` method is called. However,
|
||||
it has properties that allow for the creation of EWKB, a superset of the
|
||||
WKB standard that includes additional information.
|
||||
|
||||
|
@ -925,5 +913,5 @@ location (e.g., ``/home/bob/lib/libgeos_c.so``).
|
|||
|
||||
.. note::
|
||||
|
||||
The setting must be the *full* path to the **C** shared library; in
|
||||
The setting must be the *full* path to the **C** shared library; in
|
||||
other words you want to use ``libgeos_c.so``, not ``libgeos.so``.
|
||||
|
|
|
@ -4,8 +4,6 @@
|
|||
GeoDjango
|
||||
=========
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. module:: django.contrib.gis
|
||||
:synopsis: Geographic Information System (GIS) extensions for Django
|
||||
|
||||
|
|
|
@ -357,7 +357,6 @@ file::
|
|||
|
||||
SpatiaLite
|
||||
----------
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
@ -28,8 +28,6 @@ Settings
|
|||
``POSTGIS_TEMPLATE``
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
This setting may be used to customize the name of the PostGIS template
|
||||
|
@ -42,8 +40,6 @@ defaults to ``'template_postgis'`` (the same name used in the
|
|||
``POSTGIS_VERSION``
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
When GeoDjango's spatial backend initializes on PostGIS, it has to perform
|
||||
a SQL query to determine the version in order to figure out what
|
||||
features are available. Advanced users wishing to prevent this additional
|
||||
|
@ -118,8 +114,6 @@ spatial database entitled ``template_postgis``.
|
|||
SpatiaLite
|
||||
==========
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
You will need to download the `initialization SQL`__ script for SpatiaLite::
|
||||
|
||||
$ wget http://www.gaia-gis.it/spatialite/init_spatialite-2.3.zip
|
||||
|
@ -138,8 +132,6 @@ Settings
|
|||
``SPATIALITE_SQL``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
By default, the GeoDjango test runner looks for the SpatiaLite SQL in the
|
||||
same directory where it was invoked (by default the same directory where
|
||||
``manage.py`` is located). If you want to use a different location, then
|
||||
|
@ -201,7 +193,7 @@ all of the databases in the settings file must be using one of the
|
|||
|
||||
.. warning::
|
||||
|
||||
Do not change the :setting:`TEST_RUNNER` setting
|
||||
Do not change the :setting:`TEST_RUNNER` setting
|
||||
when running the GeoDjango tests with ``runtests.py``.
|
||||
|
||||
Example
|
||||
|
|
|
@ -68,8 +68,6 @@ You can pass in either an integer or a string representation of an integer.
|
|||
naturalday
|
||||
----------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
For dates that are the current day or within one day, return "today",
|
||||
"tomorrow" or "yesterday", as appropriate. Otherwise, format the date using
|
||||
the passed in format string.
|
||||
|
|
|
@ -61,10 +61,6 @@ See :doc:`/topics/auth`.
|
|||
comments
|
||||
========
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The comments application has been rewriten. See :doc:`/ref/contrib/comments/upgrade`
|
||||
for information on howto upgrade.
|
||||
|
||||
A simple yet flexible comments system. See :doc:`/ref/contrib/comments/index`.
|
||||
|
||||
contenttypes
|
||||
|
|
|
@ -365,8 +365,6 @@ Pinging Google via `manage.py`
|
|||
|
||||
.. django-admin:: ping_google
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Once the sitemaps application is added to your project, you may also
|
||||
ping Google using the ``ping_google`` management command::
|
||||
|
||||
|
|
|
@ -240,8 +240,6 @@ To do this, you can use the sites framework. A simple example::
|
|||
Caching the current ``Site`` object
|
||||
===================================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
As the current site is stored in the database, each call to
|
||||
``Site.objects.get_current()`` could result in a database query. But Django is a
|
||||
little cleverer than that: on the first request, the current site is cached, and
|
||||
|
@ -395,8 +393,6 @@ Here's how Django uses the sites framework:
|
|||
|
||||
.. _requestsite-objects:
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Some :doc:`django.contrib </ref/contrib/index>` applications take advantage of
|
||||
the sites framework but are architected in a way that doesn't *require* the
|
||||
sites framework to be installed in your database. (Some people don't want to, or
|
||||
|
|
|
@ -58,8 +58,6 @@ as any other Django backend in this respect.
|
|||
Autocommit mode
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
If your application is particularly read-heavy and doesn't make many
|
||||
database writes, the overhead of a constantly open transaction can
|
||||
sometimes be noticeable. For those situations, if you're using the
|
||||
|
@ -101,8 +99,6 @@ protection for multi-call operations.
|
|||
Indexes for ``varchar`` and ``text`` columns
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.1.2
|
||||
|
||||
When specifying ``db_index=True`` on your model fields, Django typically
|
||||
outputs a single ``CREATE INDEX`` statement. However, if the database type
|
||||
for the field is either ``varchar`` or ``text`` (e.g., used by ``CharField``,
|
||||
|
@ -454,8 +450,6 @@ version of SQLite.
|
|||
Using newer versions of the SQLite DB-API 2.0 driver
|
||||
----------------------------------------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
For versions of Python 2.5 or newer that include ``sqlite3`` in the standard
|
||||
library Django will now use a ``pysqlite2`` interface in preference to
|
||||
``sqlite3`` if it finds one is available.
|
||||
|
@ -637,8 +631,6 @@ many-to-many table would be stored in the ``indexes`` tablespace. The ``data``
|
|||
field would also generate an index, but no tablespace for it is specified, so
|
||||
it would be stored in the model tablespace ``tables`` by default.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Use the :setting:`DEFAULT_TABLESPACE` and :setting:`DEFAULT_INDEX_TABLESPACE`
|
||||
settings to specify default values for the db_tablespace options.
|
||||
These are useful for setting a tablespace for the built-in Django apps and
|
||||
|
|
|
@ -88,8 +88,6 @@ cleanup
|
|||
|
||||
.. django-admin:: cleanup
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Can be run as a cronjob or directly to clean out old data from the database
|
||||
(only expired sessions at the moment).
|
||||
|
||||
|
@ -98,9 +96,6 @@ compilemessages
|
|||
|
||||
.. django-admin:: compilemessages
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Before 1.0 this was the "bin/compile-messages.py" command.
|
||||
|
||||
Compiles .po files created with ``makemessages`` to .mo files for use with
|
||||
the builtin gettext support. See :doc:`/topics/i18n/index`.
|
||||
|
||||
|
@ -197,8 +192,6 @@ By default, ``dumpdata`` will output all data on a single line. This isn't
|
|||
easy for humans to read, so you can use the ``--indent`` option to
|
||||
pretty-print the output with a number of indentation spaces.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The :djadminopt:`--exclude` option may be provided to prevent specific
|
||||
applications from being dumped.
|
||||
|
||||
|
@ -207,8 +200,6 @@ applications from being dumped.
|
|||
The :djadminopt:`--exclude` option may also be provided to prevent specific
|
||||
models (specified as in the form of ``appname.ModelName``) from being dumped.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
In addition to specifying application names, you can provide a list of
|
||||
individual models, in the form of ``appname.Model``. If you specify a model
|
||||
name to ``dumpdata``, the dumped output will be restricted to that model,
|
||||
|
@ -406,9 +397,6 @@ makemessages
|
|||
|
||||
.. django-admin:: makemessages
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Before 1.0 this was the ``bin/make-messages.py`` command.
|
||||
|
||||
Runs over the entire source tree of the current directory and pulls out all
|
||||
strings marked for translation. It creates (or updates) a message file in the
|
||||
conf/locale (in the django tree) or locale (for project and application)
|
||||
|
@ -963,8 +951,6 @@ testserver <fixture fixture ...>
|
|||
|
||||
.. django-admin:: testserver
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Runs a Django development server (as in ``runserver``) using data from the
|
||||
given fixture(s).
|
||||
|
||||
|
@ -1067,8 +1053,6 @@ createsuperuser
|
|||
|
||||
.. django-admin:: createsuperuser
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This command is only available if Django's :doc:`authentication system
|
||||
</topics/auth>` (``django.contrib.auth``) is installed.
|
||||
|
||||
|
|
|
@ -195,9 +195,6 @@ it, you can access the clean data via its ``cleaned_data`` attribute::
|
|||
>>> f.cleaned_data
|
||||
{'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases.
|
||||
|
||||
Note that any text-based field -- such as ``CharField`` or ``EmailField`` --
|
||||
always cleans the input into a Unicode string. We'll cover the encoding
|
||||
implications later in this document.
|
||||
|
@ -680,8 +677,6 @@ by a ``Widget``::
|
|||
Binding uploaded files to a form
|
||||
--------------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Dealing with forms that have ``FileField`` and ``ImageField`` fields
|
||||
is a little more complicated than a normal form.
|
||||
|
||||
|
|
|
@ -230,8 +230,6 @@ fields. We've specified ``auto_id=False`` to simplify the output::
|
|||
``error_messages``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: Field.error_messages
|
||||
|
||||
The ``error_messages`` argument lets you override the default messages that the
|
||||
|
@ -303,11 +301,6 @@ For each field, we describe the default widget used if you don't specify
|
|||
the field has ``required=True``.
|
||||
* Error message keys: ``required``
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The empty value for a ``CheckboxInput`` (and hence the standard
|
||||
``BooleanField``) has changed to return ``False`` instead of ``None`` in
|
||||
the Django 1.0.
|
||||
|
||||
.. note::
|
||||
|
||||
Since all ``Field`` subclasses have ``required=True`` by default, the
|
||||
|
@ -411,10 +404,6 @@ If no ``input_formats`` argument is provided, the default input formats are::
|
|||
'%B %d %Y', '%B %d, %Y', # 'October 25 2006', 'October 25, 2006'
|
||||
'%d %B %Y', '%d %B, %Y', # '25 October 2006', '25 October, 2006'
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``DateField`` previously used a ``TextInput`` widget by default. It now
|
||||
uses a ``DateInput`` widget.
|
||||
|
||||
``DateTimeField``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -446,14 +435,9 @@ If no ``input_formats`` argument is provided, the default input formats are::
|
|||
'%m/%d/%y %H:%M', # '10/25/06 14:30'
|
||||
'%m/%d/%y', # '10/25/06'
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The ``DateTimeField`` used to use a ``TextInput`` widget by default. This has now changed.
|
||||
|
||||
``DecimalField``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: DecimalField(**kwargs)
|
||||
|
||||
* Default widget: ``TextInput``
|
||||
|
@ -506,8 +490,6 @@ given length.
|
|||
``FileField``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: FileField(**kwargs)
|
||||
|
||||
* Default widget: ``ClearableFileInput``
|
||||
|
@ -526,8 +508,6 @@ When you use a ``FileField`` in a form, you must also remember to
|
|||
``FilePathField``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: FilePathField(**kwargs)
|
||||
|
||||
* Default widget: ``Select``
|
||||
|
@ -572,8 +552,6 @@ These control the range of values permitted in the field.
|
|||
``ImageField``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: ImageField(**kwargs)
|
||||
|
||||
* Default widget: ``ClearableFileInput``
|
||||
|
@ -855,11 +833,6 @@ for ``DateField`` are used.
|
|||
If no ``input_time_formats`` argument is provided, the default input formats
|
||||
for ``TimeField`` are used.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``SplitDateTimeField`` previously used two ``TextInput`` widgets by
|
||||
default. The ``input_date_formats`` and ``input_time_formats`` arguments
|
||||
are also new.
|
||||
|
||||
Fields which handle relationships
|
||||
---------------------------------
|
||||
|
||||
|
|
|
@ -56,8 +56,6 @@ commonly used groups of widgets:
|
|||
|
||||
.. class:: DateInput
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Date input as a simple text box: ``<input type='text' ...>``
|
||||
|
||||
Takes one optional argument:
|
||||
|
@ -70,8 +68,6 @@ commonly used groups of widgets:
|
|||
|
||||
.. class:: DateTimeInput
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Date/time input as a simple text box: ``<input type='text' ...>``
|
||||
|
||||
Takes one optional argument:
|
||||
|
@ -95,9 +91,6 @@ commonly used groups of widgets:
|
|||
|
||||
If no ``format`` argument is provided, the default format is ``'%H:%M:%S'``.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``format`` argument was not supported in Django 1.0.
|
||||
|
||||
.. class:: Textarea
|
||||
|
||||
Text area: ``<textarea>...</textarea>``
|
||||
|
@ -167,9 +160,6 @@ commonly used groups of widgets:
|
|||
Takes two optional arguments, ``date_format`` and ``time_format``, which
|
||||
work just like the ``format`` argument for ``DateInput`` and ``TimeInput``.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``date_format`` and ``time_format`` arguments were not supported in Django 1.0.
|
||||
|
||||
.. class:: SelectDateWidget
|
||||
|
||||
Wrapper around three select widgets: one each for month, day, and year.
|
||||
|
|
|
@ -93,9 +93,6 @@ If the given URL is ``None``, Django will return an ``HttpResponseGone`` (410).
|
|||
to the URL. If ``False``, then the query string is discarded. By
|
||||
default, ``query_string`` is ``False``.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
The ``permanent`` keyword argument is new in Django 1.1.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
The ``query_string`` keyword argument is new in Django 1.3.
|
||||
|
||||
|
@ -184,8 +181,6 @@ a date in the *future* are not included unless you set ``allow_future`` to
|
|||
specified in ``date_field`` is greater than the current date/time. By
|
||||
default, this is ``False``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
* ``template_object_name``: Designates the name of the template variable
|
||||
to use in the template context. By default, this is ``'latest'``.
|
||||
|
||||
|
@ -210,9 +205,6 @@ In addition to ``extra_context``, the template's context will be:
|
|||
``datetime.datetime`` objects. These are ordered in reverse. This is
|
||||
equivalent to ``queryset.dates(date_field, 'year')[::-1]``.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The behaviour depending on ``template_object_name`` is new in this version.
|
||||
|
||||
* ``latest``: The ``num_latest`` objects in the system, ordered descending
|
||||
by ``date_field``. For example, if ``num_latest`` is ``10``, then
|
||||
``latest`` will be a list of the latest 10 objects in ``queryset``.
|
||||
|
@ -729,9 +721,6 @@ If ``template_name`` isn't specified, this view will use the template
|
|||
|
||||
**Template context:**
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``paginator`` and ``page_obj`` context variables are new.
|
||||
|
||||
In addition to ``extra_context``, the template's context will be:
|
||||
|
||||
* ``object_list``: The list of objects. This variable's name depends on the
|
||||
|
@ -775,8 +764,6 @@ represented as page ``1``.
|
|||
For more on pagination, read the :doc:`pagination documentation
|
||||
</topics/pagination>`.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
As a special case, you are also permitted to use ``last`` as a value for
|
||||
``page``::
|
||||
|
||||
|
@ -861,12 +848,6 @@ Create/update/delete generic views
|
|||
The ``django.views.generic.create_update`` module contains a set of functions
|
||||
for creating, editing and deleting objects.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
``django.views.generic.create_update.create_object`` and
|
||||
``django.views.generic.create_update.update_object`` now use the new :doc:`forms
|
||||
library </topics/forms/index>` to build and display the form.
|
||||
|
||||
``django.views.generic.create_update.create_object``
|
||||
----------------------------------------------------
|
||||
|
||||
|
|
|
@ -52,11 +52,6 @@ Adds a few conveniences for perfectionists:
|
|||
you don't have a valid URL pattern for ``foo.com/bar`` but *do* have a
|
||||
valid pattern for ``foo.com/bar/``.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The behavior of :setting:`APPEND_SLASH` has changed slightly in this
|
||||
version. It didn't used to check whether the pattern was matched in
|
||||
the URLconf.
|
||||
|
||||
If :setting:`PREPEND_WWW` is ``True``, URLs that lack a leading "www."
|
||||
will be redirected to the same URL with a leading "www."
|
||||
|
||||
|
@ -123,8 +118,6 @@ Reverse proxy middleware
|
|||
|
||||
.. class:: SetRemoteAddrFromForwardedFor
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
|
||||
This middleware was removed in Django 1.1. See :ref:`the release notes
|
||||
<removed-setremoteaddrfromforwardedfor-middleware>` for details.
|
||||
|
||||
|
@ -186,8 +179,6 @@ CSRF protection middleware
|
|||
|
||||
.. class:: CsrfMiddleware
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Adds protection against Cross Site Request Forgeries by adding hidden form
|
||||
fields to POST forms and checking requests for the correct value. See the
|
||||
:doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`.
|
||||
|
|
|
@ -173,8 +173,6 @@ If ``True``, djadmin:`django-admin.py sqlindexes <sqlindexes>` will output a
|
|||
|
||||
.. attribute:: Field.db_tablespace
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The name of the database tablespace to use for this field's index, if this field
|
||||
is indexed. The default is the project's :setting:`DEFAULT_INDEX_TABLESPACE`
|
||||
setting, if set, or the :attr:`~Field.db_tablespace` of the model, if any. If
|
||||
|
@ -432,8 +430,6 @@ JavaScript shortcuts.
|
|||
``DecimalField``
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: DecimalField(max_digits=None, decimal_places=None, [**options])
|
||||
|
||||
A fixed-precision decimal number, represented in Python by a
|
||||
|
@ -489,8 +485,6 @@ Has one **required** argument:
|
|||
date/time of the file upload (so that uploaded files don't fill up the given
|
||||
directory).
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
This may also be a callable, such as a function, which will be called to
|
||||
obtain the upload path, including the filename. This callable must be able
|
||||
to accept two arguments, and return a Unix-style path (with forward slashes)
|
||||
|
@ -519,8 +513,6 @@ Also has one optional argument:
|
|||
|
||||
.. attribute:: FileField.storage
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Optional. A storage object, which handles the storage and retrieval of your
|
||||
files. See :doc:`/topics/files` for details on how to provide this object.
|
||||
|
||||
|
@ -567,9 +559,6 @@ without validation, to a directory that's within your Web server's document
|
|||
root, then somebody could upload a CGI or PHP script and execute that script by
|
||||
visiting its URL on your site. Don't allow that.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``max_length`` argument was added in this version.
|
||||
|
||||
By default, :class:`FileField` instances are
|
||||
created as ``varchar(100)`` columns in your database. As with other fields, you
|
||||
can change the maximum length using the :attr:`~CharField.max_length` argument.
|
||||
|
@ -652,9 +641,6 @@ base filename, not the full path. So, this example::
|
|||
because the :attr:`~FilePathField.match` applies to the base filename
|
||||
(``foo.gif`` and ``bar.gif``).
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``max_length`` argument was added in this version.
|
||||
|
||||
By default, :class:`FilePathField` instances are
|
||||
created as ``varchar(100)`` columns in your database. As with other fields, you
|
||||
can change the maximum length using the :attr:`~CharField.max_length` argument.
|
||||
|
@ -664,8 +650,6 @@ can change the maximum length using the :attr:`~CharField.max_length` argument.
|
|||
|
||||
.. class:: FloatField([**options])
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
A floating-point number represented in Python by a ``float`` instance.
|
||||
|
||||
The admin represents this as an ``<input type="text">`` (a single-line input).
|
||||
|
@ -699,9 +683,6 @@ Requires the `Python Imaging Library`_.
|
|||
|
||||
.. _Python Imaging Library: http://www.pythonware.com/products/pil/
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``max_length`` argument was added in this version.
|
||||
|
||||
By default, :class:`ImageField` instances are created as ``varchar(100)``
|
||||
columns in your database. As with other fields, you can change the maximum
|
||||
length using the :attr:`~CharField.max_length` argument.
|
||||
|
@ -874,8 +855,6 @@ you can use the name of the model, rather than the model object itself::
|
|||
class Manufacturer(models.Model):
|
||||
# ...
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
To refer to models defined in another application, you can explicitly specify
|
||||
a model with the full application label. For example, if the ``Manufacturer``
|
||||
model above is defined in another application called ``production``, you'd
|
||||
|
|
|
@ -133,9 +133,6 @@ To save an object back to the database, call ``save()``:
|
|||
|
||||
.. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS])
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``force_insert`` and ``force_update`` arguments were added.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``using`` argument was added.
|
||||
|
||||
|
@ -168,8 +165,6 @@ documentation for ``AutoField`` for more details.
|
|||
The ``pk`` property
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: Model.pk
|
||||
|
||||
Regardless of whether you define a primary key field yourself, or let Django
|
||||
|
@ -278,8 +273,6 @@ auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below.
|
|||
Forcing an INSERT or UPDATE
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
In some rare circumstances, it's necessary to be able to force the ``save()``
|
||||
method to perform an SQL ``INSERT`` and not fall back to doing an ``UPDATE``.
|
||||
Or vice-versa: update, if possible, but not insert a new row. In these cases
|
||||
|
|
|
@ -65,8 +65,6 @@ Django quotes column and table names behind the scenes.
|
|||
|
||||
.. attribute:: Options.db_tablespace
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The name of the database tablespace to use for the model. If the backend doesn't
|
||||
support tablespaces, this option is ignored.
|
||||
|
||||
|
@ -90,8 +88,6 @@ See the docs for :meth:`~django.db.models.QuerySet.latest` for more.
|
|||
|
||||
.. attribute:: Options.managed
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Defaults to ``True``, meaning Django will create the appropriate database
|
||||
tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`reset`
|
||||
management command. That is, Django *manages* the database tables' lifecycles.
|
||||
|
@ -219,8 +215,6 @@ human_readable_permission_name)``.
|
|||
|
||||
.. attribute:: Options.proxy
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
If set to ``True``, a model which subclasses another model will be treated as
|
||||
a :ref:`proxy model <proxy-models>`.
|
||||
|
||||
|
@ -238,8 +232,6 @@ It's used in the Django admin and is enforced at the database level (i.e., the
|
|||
appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE``
|
||||
statement).
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
For convenience, unique_together can be a single list when dealing with a single
|
||||
set of fields::
|
||||
|
||||
|
|
|
@ -186,8 +186,6 @@ annotate
|
|||
|
||||
.. method:: annotate(*args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Annotates each object in the ``QuerySet`` with the provided list of
|
||||
aggregate values (averages, sums, etc) that have been computed over
|
||||
the objects that are related to the objects in the ``QuerySet``.
|
||||
|
@ -279,13 +277,6 @@ ordering piece of data for each of the main items you are selecting, the
|
|||
ordering may well be exactly what you want to do. Use ordering on multi-valued
|
||||
fields with care and make sure the results are what you expect.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The syntax for ordering across related models has changed. See the `Django 0.96
|
||||
documentation`_ for the old behaviour.
|
||||
|
||||
.. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield
|
||||
|
||||
There's no way to specify whether ordering should be case sensitive. With
|
||||
respect to case-sensitivity, Django will order results however your database
|
||||
backend normally orders them.
|
||||
|
@ -293,8 +284,6 @@ backend normally orders them.
|
|||
If you don't want any ordering to be applied to a query, not even the default
|
||||
ordering, call ``order_by()`` with no parameters.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
You can tell if a query is ordered or not by checking the
|
||||
:attr:`QuerySet.ordered` attribute, which will be ``True`` if the
|
||||
``QuerySet`` has been ordered in any way.
|
||||
|
@ -304,8 +293,6 @@ reverse
|
|||
|
||||
.. method:: reverse()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Use the ``reverse()`` method to reverse the order in which a queryset's
|
||||
elements are returned. Calling ``reverse()`` a second time restores the
|
||||
ordering back to the normal direction.
|
||||
|
@ -429,11 +416,6 @@ A few subtleties that are worth mentioning:
|
|||
if the ``extra()`` clause is used after the ``values()``, the
|
||||
fields added by the select will be included automatically.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Previously, it was not possible to pass ``blog_id`` to ``values()`` in the above
|
||||
example, only ``blog``.
|
||||
|
||||
A ``ValuesQuerySet`` is useful when you know you're only going to need values
|
||||
from a small number of the available fields and you won't need the
|
||||
functionality of a model instance object. It's more efficient to select only
|
||||
|
@ -478,8 +460,6 @@ values_list
|
|||
|
||||
.. method:: values_list(*fields)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This is similar to ``values()`` except that instead of returning dictionaries,
|
||||
it returns tuples when iterated over. Each tuple contains the value from the
|
||||
respective field passed into the ``values_list()`` call -- so the first item is
|
||||
|
@ -544,8 +524,6 @@ none
|
|||
|
||||
.. method:: none()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to
|
||||
an empty list. This can be used in cases where you know that you should
|
||||
return an empty result set and your caller is expecting a ``QuerySet``
|
||||
|
@ -561,8 +539,6 @@ all
|
|||
|
||||
.. method:: all()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns a *copy* of the current ``QuerySet`` (or ``QuerySet`` subclass you
|
||||
pass in). This can be useful in some situations where you might want to pass
|
||||
in either a model manager or a ``QuerySet`` and do further filtering on the
|
||||
|
@ -676,11 +652,6 @@ call). It's an error to use both a list of fields and the ``depth``
|
|||
parameter in the same ``select_related()`` call, since they are
|
||||
conflicting options.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Both the ``depth`` argument and the ability to specify field names in the call
|
||||
to ``select_related()`` are new in Django version 1.0.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
You can also refer to the reverse direction of a ``OneToOneFields`` in
|
||||
|
@ -753,8 +724,6 @@ of the arguments is required, but you should use at least one of them.
|
|||
some database backends, such as some MySQL versions, don't support
|
||||
subqueries.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
In some rare cases, you might wish to pass parameters to the SQL fragments
|
||||
in ``extra(select=...)``. For this purpose, use the ``select_params``
|
||||
parameter. Since ``select_params`` is a sequence and the ``select``
|
||||
|
@ -860,8 +829,6 @@ defer
|
|||
|
||||
.. method:: defer(*fields)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
In some complex data-modeling situations, your models might contain a lot of
|
||||
fields, some of which could contain a lot of data (for example, text fields),
|
||||
or require expensive processing to convert them to Python objects. If you are
|
||||
|
@ -922,8 +889,6 @@ only
|
|||
|
||||
.. method:: only(*fields)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
The ``only()`` method is more or less the opposite of ``defer()``. You
|
||||
call it with the fields that should *not* be deferred when retrieving a model.
|
||||
If you have a model where almost all the fields need to be deferred, using
|
||||
|
@ -1198,8 +1163,6 @@ aggregate
|
|||
|
||||
.. method:: aggregate(*args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Returns a dictionary of aggregate values (averages, sums, etc) calculated
|
||||
over the ``QuerySet``. Each argument to ``aggregate()`` specifies
|
||||
a value that will be included in the dictionary that is returned.
|
||||
|
@ -1253,7 +1216,7 @@ the number of rows affected. The ``update()`` method is applied instantly and
|
|||
the only restriction on the :class:`QuerySet` that is updated is that it can
|
||||
only update columns in the model's main table. Filtering based on related
|
||||
fields is still possible. You cannot call ``update()`` on a
|
||||
:class:`QuerySet` that has had a slice taken or can otherwise no longer be
|
||||
:class:`QuerySet` that has had a slice taken or can otherwise no longer be
|
||||
filtered.
|
||||
|
||||
For example, if you wanted to update all the entries in a particular blog
|
||||
|
@ -1334,12 +1297,6 @@ SQL equivalents::
|
|||
SELECT ... WHERE id = 14;
|
||||
SELECT ... WHERE id IS NULL;
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The semantics of ``id__exact=None`` have changed in Django 1.0. Previously,
|
||||
it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level,
|
||||
which would never match anything. It has now been changed to behave the
|
||||
same as ``id__isnull=True``.
|
||||
|
||||
.. admonition:: MySQL comparisons
|
||||
|
||||
In MySQL, a database table's "collation" setting determines whether
|
||||
|
@ -1446,10 +1403,6 @@ The above code fragment could also be written as follows::
|
|||
inner_q = Blog.objects.filter(name__contains='Cheddar').values('pk').query
|
||||
entries = Entry.objects.filter(blog__in=inner_q)
|
||||
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
In Django 1.0, only the latter piece of code is valid.
|
||||
|
||||
This second form is a bit less readable and unnatural to write, since it
|
||||
accesses the internal ``query`` attribute and requires a ``ValuesQuerySet``.
|
||||
If your code doesn't require compatibility with Django 1.0, use the first
|
||||
|
@ -1687,8 +1640,6 @@ such as January 3, July 3, etc.
|
|||
week_day
|
||||
~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
For date/datetime fields, a 'day of the week' match.
|
||||
|
||||
Takes an integer value representing the day of week from 1 (Sunday) to 7
|
||||
|
@ -1748,8 +1699,6 @@ full text searches. `See the MySQL documentation for additional details.
|
|||
regex
|
||||
~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Case-sensitive regular expression match.
|
||||
|
||||
The regular expression syntax is that of the database backend in use.
|
||||
|
@ -1779,8 +1728,6 @@ regular expression syntax is recommended.
|
|||
iregex
|
||||
~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Case-insensitive regular expression match.
|
||||
|
||||
Example::
|
||||
|
@ -1802,8 +1749,6 @@ SQL equivalents::
|
|||
Aggregation Functions
|
||||
---------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Django provides the following aggregation functions in the
|
||||
``django.db.models`` module. For details on how to use these
|
||||
aggregate functions, see
|
||||
|
|
|
@ -117,16 +117,6 @@ All attributes except ``session`` should be considered read-only.
|
|||
``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank
|
||||
dictionary-like object.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
In previous versions of Django, ``request.FILES`` contained simple ``dict``
|
||||
objects representing uploaded files. This is no longer true -- files are
|
||||
represented by :class:`UploadedFile` objects.
|
||||
|
||||
These :class:`UploadedFile` objects will emulate the old-style ``dict``
|
||||
interface, but this is deprecated and will be removed in the next release
|
||||
of Django.
|
||||
|
||||
.. attribute:: HttpRequest.META
|
||||
|
||||
A standard Python dictionary containing all available HTTP headers.
|
||||
|
@ -522,8 +512,6 @@ To set or remove a header in your response, treat it like a dictionary::
|
|||
Note that unlike a dictionary, ``del`` doesn't raise ``KeyError`` if the header
|
||||
doesn't exist.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
HTTP headers cannot contain newlines. An attempt to set a header containing a
|
||||
newline character (CR or LF) will raise ``BadHeaderError``
|
||||
|
||||
|
|
|
@ -699,8 +699,6 @@ Never deploy a site into production with ``DEBUG`` turned on.
|
|||
DEBUG_PROPAGATE_EXCEPTIONS
|
||||
--------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``False``
|
||||
|
||||
If set to True, Django's normal exception handling of view functions
|
||||
|
@ -766,8 +764,6 @@ site manager(s).
|
|||
DEFAULT_INDEX_TABLESPACE
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``''`` (Empty string)
|
||||
|
||||
Default tablespace to use for indexes on fields that don't specify
|
||||
|
@ -778,8 +774,6 @@ one, if the backend supports it.
|
|||
DEFAULT_TABLESPACE
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``''`` (Empty string)
|
||||
|
||||
Default tablespace to use for models that don't specify one, if the
|
||||
|
@ -882,8 +876,6 @@ trailing space.
|
|||
EMAIL_USE_TLS
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to use a TLS (secure) connection when talking to the SMTP server.
|
||||
|
@ -893,8 +885,6 @@ Whether to use a TLS (secure) connection when talking to the SMTP server.
|
|||
FILE_CHARSET
|
||||
------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'utf-8'``
|
||||
|
||||
The character encoding used to decode any files read from disk. This includes
|
||||
|
@ -905,8 +895,6 @@ template files and initial SQL data files.
|
|||
FILE_UPLOAD_HANDLERS
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default::
|
||||
|
||||
("django.core.files.uploadhandler.MemoryFileUploadHandler",
|
||||
|
@ -919,8 +907,6 @@ A tuple of handlers to use for uploading. See :doc:`/topics/files` for details.
|
|||
FILE_UPLOAD_MAX_MEMORY_SIZE
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``2621440`` (i.e. 2.5 MB).
|
||||
|
||||
The maximum size (in bytes) that an upload will be before it gets streamed to
|
||||
|
@ -959,8 +945,6 @@ system's standard umask.
|
|||
FILE_UPLOAD_TEMP_DIR
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``None``
|
||||
|
||||
The directory to store data temporarily while uploading files. If ``None``,
|
||||
|
@ -1106,8 +1090,6 @@ standard :term:`language format<language code>`. For example, U.S. English is
|
|||
LANGUAGE_COOKIE_NAME
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'django_language'``
|
||||
|
||||
The name of the cookie to use for the language cookie. This can be whatever you
|
||||
|
@ -1206,8 +1188,6 @@ configuration process will be skipped.
|
|||
LOGIN_REDIRECT_URL
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/accounts/profile/'``
|
||||
|
||||
The URL where requests are redirected after login when the
|
||||
|
@ -1221,8 +1201,6 @@ decorator, for example.
|
|||
LOGIN_URL
|
||||
---------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/accounts/login/'``
|
||||
|
||||
The URL where requests are redirected for login, especially when using the
|
||||
|
@ -1233,8 +1211,6 @@ The URL where requests are redirected for login, especially when using the
|
|||
LOGOUT_URL
|
||||
----------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/accounts/logout/'``
|
||||
|
||||
LOGIN_URL counterpart.
|
||||
|
@ -1531,8 +1507,6 @@ should be different from ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/s
|
|||
SESSION_COOKIE_PATH
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/'``
|
||||
|
||||
The path set on the session cookie. This should either match the URL path of your
|
||||
|
@ -1559,11 +1533,6 @@ See the :doc:`/topics/http/sessions`.
|
|||
SESSION_ENGINE
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``cached_db`` backend was added
|
||||
|
||||
Default: ``django.contrib.sessions.backends.db``
|
||||
|
||||
Controls where Django stores session data. Valid values are:
|
||||
|
@ -1590,8 +1559,6 @@ See the :doc:`/topics/http/sessions`.
|
|||
SESSION_FILE_PATH
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``None``
|
||||
|
||||
If you're using file-based session storage, this sets the directory in
|
||||
|
|
|
@ -474,8 +474,6 @@ connection_created
|
|||
.. data:: django.db.backends.signals.connection_created
|
||||
:module:
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The connection argument was added
|
||||
|
||||
|
|
|
@ -459,8 +459,6 @@ See :doc:`/topics/i18n/index` for more.
|
|||
django.core.context_processors.media
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
|
||||
``RequestContext`` will contain a variable ``MEDIA_URL``, providing the
|
||||
value of the :setting:`MEDIA_URL` setting.
|
||||
|
|
|
@ -19,8 +19,6 @@ Built-in tag reference
|
|||
autoescape
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Control the current auto-escaping behavior. This tag takes either ``on`` or
|
||||
``off`` as an argument and that determines whether auto-escaping is in effect
|
||||
inside the block. The block is closed with an ``endautoescape`` ending tag.
|
||||
|
@ -60,8 +58,6 @@ Ignore everything between ``{% comment %}`` and ``{% endcomment %}``
|
|||
csrf_token
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.1.2
|
||||
|
||||
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
|
||||
|
@ -72,8 +68,7 @@ Forgeries </ref/contrib/csrf>`.
|
|||
cycle
|
||||
~~~~~
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Cycle among the given strings or variables each time this tag is encountered.
|
||||
Cycle among the given strings or variables each time this tag is encountered.
|
||||
|
||||
Within a loop, cycles among the given strings each time through the
|
||||
loop::
|
||||
|
@ -259,8 +254,6 @@ provided in ``athlete_list``::
|
|||
|
||||
You can loop over a list in reverse by using ``{% for obj in list reversed %}``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you need to loop over a list of lists, you can unpack the values
|
||||
in each sub-list into individual variables. For example, if your context
|
||||
contains a list of (x,y) coordinates called ``points``, you could use the
|
||||
|
@ -298,8 +291,6 @@ The for loop sets a number of variables available within the loop:
|
|||
for ... empty
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
The ``for`` tag can take an optional ``{% empty %}`` clause that will be
|
||||
displayed if the given array is empty or could not be found::
|
||||
|
||||
|
@ -954,8 +945,6 @@ such as this:
|
|||
|
||||
The template tag will output the string ``/clients/client/123/``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you're using :ref:`named URL patterns <naming-url-patterns>`, you can
|
||||
refer to the name of the pattern in the ``url`` tag instead of using the
|
||||
path to the view.
|
||||
|
@ -964,8 +953,6 @@ Note that if the URL you're reversing doesn't exist, you'll get an
|
|||
:exc:`NoReverseMatch` exception raised, which will cause your site to display an
|
||||
error page.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you'd like to retrieve a URL without displaying it, you can use a slightly
|
||||
different call::
|
||||
|
||||
|
@ -982,8 +969,6 @@ missing. In practice you'll use this to link to views that are optional::
|
|||
<a href="{{ the_url }}">Link to optional stuff</a>
|
||||
{% endif %}
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
If you'd like to retrieve a namespaced URL, specify the fully qualified name::
|
||||
|
||||
{% url myapp:view-name %}
|
||||
|
@ -1054,8 +1039,6 @@ which is rounded up to 88).
|
|||
with
|
||||
~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
New keyword argument format and multiple variable assignments.
|
||||
|
||||
|
@ -1390,18 +1373,11 @@ applied to the result will only result in one round of escaping being done. So
|
|||
it is safe to use this function even in auto-escaping environments. If you want
|
||||
multiple escaping passes to be applied, use the ``force_escape`` filter.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Due to auto-escaping, the behavior of this filter has changed slightly.
|
||||
The replacements are only made once, after
|
||||
all other filters are applied -- including filters before and after it.
|
||||
|
||||
.. templatefilter:: escapejs
|
||||
|
||||
escapejs
|
||||
~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Escapes characters for use in JavaScript strings. This does *not* make the
|
||||
string safe for use in HTML, but does protect you from syntax errors when using
|
||||
templates to generate JavaScript/JSON.
|
||||
|
@ -1445,8 +1421,9 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be ``'a'``.
|
|||
fix_ampersands
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
This is rarely useful as ampersands are now automatically escaped. See escape_ for more information.
|
||||
..note::
|
||||
|
||||
This is rarely useful as ampersands are automatically escaped. See escape_ for more information.
|
||||
|
||||
Replaces ampersands with ``&`` entities.
|
||||
|
||||
|
@ -1503,8 +1480,6 @@ with an argument of ``-1``.
|
|||
force_escape
|
||||
~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Applies HTML escaping to a string (see the ``escape`` filter for details).
|
||||
This filter is applied *immediately* and returns a new, escaped string. This
|
||||
is useful in the rare cases where you need multiple escaping or want to apply
|
||||
|
@ -1564,8 +1539,6 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be the string
|
|||
last
|
||||
~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns the last item in a list.
|
||||
|
||||
For example::
|
||||
|
@ -2035,9 +2008,6 @@ unordered_list
|
|||
Recursively takes a self-nested list and returns an HTML unordered list --
|
||||
WITHOUT opening and closing <ul> tags.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The format accepted by ``unordered_list`` has changed to be easier to understand.
|
||||
|
||||
The list is assumed to be in the proper format. For example, if ``var`` contains
|
||||
``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then
|
||||
``{{ var|unordered_list }}`` would return::
|
||||
|
@ -2054,7 +2024,7 @@ The list is assumed to be in the proper format. For example, if ``var`` contains
|
|||
</ul>
|
||||
</li>
|
||||
|
||||
Note: the previous more restrictive and verbose format is still supported:
|
||||
Note: An older, more restrictive and verbose input format is also supported:
|
||||
``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``,
|
||||
|
||||
.. templatefilter:: upper
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Unicode data
|
||||
============
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Django natively supports Unicode data everywhere. Providing your database can
|
||||
somehow store the data, you can safely pass around Unicode strings to
|
||||
templates, models and the database.
|
||||
|
|
|
@ -191,8 +191,6 @@ Methods
|
|||
|
||||
.. method:: models.User.set_unusable_password()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Marks the user as having no password set. This isn't the same as
|
||||
having a blank string for a password.
|
||||
:meth:`~django.contrib.auth.models.User.check_password()` for this user
|
||||
|
@ -204,8 +202,6 @@ Methods
|
|||
|
||||
.. method:: models.User.has_usable_password()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns ``False`` if
|
||||
:meth:`~django.contrib.auth.models.User.set_unusable_password()` has
|
||||
been called for this user.
|
||||
|
@ -396,9 +392,6 @@ to salt the raw password to create the hash. Note that the ``crypt`` method is
|
|||
only supported on platforms that have the standard Python ``crypt`` module
|
||||
available.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
Support for the ``crypt`` module is new in Django 1.0.
|
||||
|
||||
For example::
|
||||
|
||||
sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
|
||||
|
@ -451,9 +444,6 @@ they're used by Web requests, as explained in the next section.
|
|||
Creating superusers
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``manage.py createsuperuser`` command is new.
|
||||
|
||||
:djadmin:`manage.py syncdb <syncdb>` prompts you to create a superuser the
|
||||
first time you run it after adding ``'django.contrib.auth'`` to your
|
||||
:setting:`INSTALLED_APPS`. If you need to create a superuser at a later date,
|
||||
|
@ -654,9 +644,6 @@ How to log a user out
|
|||
Note that :func:`~django.contrib.auth.logout()` doesn't throw any errors if
|
||||
the user wasn't logged in.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Calling ``logout()`` now cleans session data.
|
||||
|
||||
When you call :func:`~django.contrib.auth.logout()`, the session data for
|
||||
the current request is completely cleaned out. All existing data is
|
||||
removed. This is to prevent another person from using the same Web browser
|
||||
|
|
|
@ -317,8 +317,6 @@ activate dummy caching, set :setting:`BACKEND <CACHES-BACKEND>` like so::
|
|||
Using a custom cache backend
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
While Django includes support for a number of cache backends out-of-the-box,
|
||||
sometimes you might want to use a customized cache backend. To use an external
|
||||
cache backend with Django, use the Python import path as the
|
||||
|
@ -416,10 +414,6 @@ arguments.
|
|||
The per-site cache
|
||||
==================
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
(previous versions of Django only provided a single ``CacheMiddleware`` instead
|
||||
of the two pieces described below).
|
||||
|
||||
Once the cache is set up, the simplest way to use caching is to cache your
|
||||
entire site. You'll need to add
|
||||
``'django.middleware.cache.UpdateCacheMiddleware'`` and
|
||||
|
@ -473,8 +467,6 @@ Additionally, the cache middleware automatically sets a few headers in each
|
|||
|
||||
See :doc:`/topics/http/middleware` for more on middleware.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in
|
||||
its ``Cache-Control`` header) then the page will be cached until the expiry
|
||||
time, rather than :setting:`CACHE_MIDDLEWARE_SECONDS`. Using the decorators in
|
||||
|
@ -586,8 +578,6 @@ URLconf.
|
|||
Template fragment caching
|
||||
=========================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you're after even more control, you can also cache template fragments using
|
||||
the ``cache`` template tag. To give your template access to this tag, put
|
||||
``{% load cache %}`` near the top of your template.
|
||||
|
@ -705,8 +695,6 @@ return if the object doesn't exist in the cache::
|
|||
>>> cache.get('my_key', 'has expired')
|
||||
'has expired'
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
To add a key only if it doesn't already exist, use the ``add()`` method.
|
||||
It takes the same parameters as ``set()``, but it will not attempt to
|
||||
update the cache if the key specified is already present::
|
||||
|
@ -761,8 +749,6 @@ from the cache, not just the keys set by your application. ::
|
|||
|
||||
>>> cache.clear()
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
You can also increment or decrement a key that already exists using the
|
||||
``incr()`` or ``decr()`` methods, respectively. By default, the existing cache
|
||||
value will incremented or decremented by 1. Other increment/decrement values
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Conditional View Processing
|
||||
===========================
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
HTTP clients can send a number of headers to tell the server about copies of a
|
||||
resource that they have already seen. This is commonly used when retrieving a
|
||||
Web page (using an HTTP ``GET`` request) to avoid sending all the data for
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Aggregation
|
||||
===========
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. currentmodule:: django.db.models
|
||||
|
||||
The topic guide on :doc:`Django's database-abstraction API </topics/db/queries>`
|
||||
|
|
|
@ -387,8 +387,6 @@ work; all are optional.
|
|||
Extra fields on many-to-many relationships
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When you're only dealing with simple many-to-many relationships such as
|
||||
mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes
|
||||
you may need to associate data with the relationship between two models.
|
||||
|
@ -553,8 +551,6 @@ can be made; see :ref:`the model field reference <ref-onetoone>` for details.
|
|||
|
||||
.. _One-to-one relationship model example: http://www.djangoproject.com/documentation/models/one_to_one/
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
:class:`~django.db.models.OneToOneField` fields also accept one optional argument
|
||||
described in the :ref:`model field reference <ref-onetoone>`.
|
||||
|
||||
|
@ -606,8 +602,6 @@ particular database engine.
|
|||
Custom field types
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If one of the existing model fields cannot be used to fit your purposes, or if
|
||||
you wish to take advantage of some less common database column types, you can
|
||||
create your own field class. Full coverage of creating your own fields is
|
||||
|
@ -769,8 +763,6 @@ on :doc:`using raw SQL</topics/db/sql>`.
|
|||
Model inheritance
|
||||
=================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Model inheritance in Django works almost identically to the way normal
|
||||
class inheritance works in Python. The only decision you have to make
|
||||
is whether you want the parent models to be models in their own right
|
||||
|
@ -1026,8 +1018,6 @@ to indicate that your field is the link back to the parent class.
|
|||
Proxy models
|
||||
------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
When using :ref:`multi-table inheritance <multi-table-inheritance>`, a new
|
||||
database table is created for each subclass of a model. This is usually the
|
||||
desired behavior, since the subclass needs a place to store any additional
|
||||
|
|
|
@ -475,8 +475,6 @@ those latter objects, you could write::
|
|||
Spanning multi-valued relationships
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When you are filtering an object based on a ``ManyToManyField`` or a reverse
|
||||
``ForeignKey``, there are two different sorts of filter you may be
|
||||
interested in. Consider the ``Blog``/``Entry`` relationship (``Blog`` to
|
||||
|
@ -532,8 +530,6 @@ filtering on different linked objects.
|
|||
Filters can reference fields on the model
|
||||
-----------------------------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
In the examples given so far, we have constructed filters that compare
|
||||
the value of a model field with a constant. But what if you want to compare
|
||||
the value of a model field with another field on the same model?
|
||||
|
@ -818,8 +814,6 @@ complete query set::
|
|||
Updating multiple objects at once
|
||||
=================================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Sometimes you want to set a field to a particular value for all the objects in
|
||||
a ``QuerySet``. You can do this with the ``update()`` method. For example::
|
||||
|
||||
|
@ -858,8 +852,6 @@ Just loop over them and call ``save()``::
|
|||
for item in my_queryset:
|
||||
item.save()
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Calls to update can also use :ref:`F() objects <query-expressions>` to update
|
||||
one field based on the value of another field in the model. This is especially
|
||||
useful for incrementing counters based upon their current value. For example, to
|
||||
|
|
|
@ -338,8 +338,6 @@ In this example, ``a.save()`` will not be undone in the case where
|
|||
Database-level autocommit
|
||||
-------------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
With PostgreSQL 8.2 or later, there is an advanced option to run PostgreSQL
|
||||
with :doc:`database-level autocommit </ref/databases>`. If you use this option,
|
||||
there is no constantly open transaction, so it is always possible to continue
|
||||
|
|
|
@ -201,8 +201,6 @@ from the request's POST data, sends that to admin@example.com and redirects to
|
|||
The EmailMessage class
|
||||
======================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Django's :meth:`~django.core.mail.send_mail()` and
|
||||
:meth:`~django.core.mail.send_mass_mail()` functions are actually thin
|
||||
wrappers that make use of the :class:`~django.core.mail.EmailMessage` class.
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Managing files
|
||||
==============
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This document describes Django's file access APIs.
|
||||
|
||||
By default, Django stores files locally, using the :setting:`MEDIA_ROOT` and
|
||||
|
|
|
@ -176,8 +176,6 @@ itself. When rendering a formset in a template, you can include all
|
|||
the management data by rendering ``{{ my_formset.management_form }}``
|
||||
(substituting the name of your formset as appropriate).
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
``total_form_count`` and ``initial_form_count``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
@ -114,9 +114,6 @@ There are three code paths here:
|
|||
3. If the form has been submitted but is invalid, the bound form instance is
|
||||
passed on to the template.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases.
|
||||
|
||||
The distinction between **bound** and **unbound** forms is important. An unbound
|
||||
form does not have any data associated with it; when rendered to the user, it
|
||||
will be empty or will contain default values. A bound form does have submitted
|
||||
|
@ -345,10 +342,6 @@ error in a hidden field is a sign of form tampering, since normal form
|
|||
interaction won't alter them. However, you could easily insert some error
|
||||
displays for those form errors, as well.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
The ``hidden_fields`` and ``visible_fields`` methods are new in Django
|
||||
1.1.
|
||||
|
||||
Reusable form templates
|
||||
-----------------------
|
||||
|
||||
|
|
|
@ -111,11 +111,6 @@ the full list of conversions:
|
|||
``widget=forms.Textarea``
|
||||
=============================== ========================================
|
||||
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``FloatField`` form field and ``DecimalField`` model and form fields
|
||||
are new in Django 1.0.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``BigIntegerField`` is new in Django 1.2.
|
||||
|
||||
|
@ -311,12 +306,8 @@ model fields:
|
|||
|
||||
2. Use the ``fields`` attribute of the ``ModelForm``'s inner ``Meta``
|
||||
class. This attribute, if given, should be a list of field names
|
||||
to include in the form.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
|
||||
The form will render the fields in the same order they are specified in the
|
||||
``fields`` attribute.
|
||||
to include in the form. The order in which the fields names are specified
|
||||
in that list is respected when the form renders them.
|
||||
|
||||
3. Use the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta``
|
||||
class. This attribute, if given, should be a list of field names
|
||||
|
@ -456,8 +447,6 @@ parameter when declaring the form field::
|
|||
Changing the order of fields
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
By default, a ``ModelForm`` will render fields in the same order that they are
|
||||
defined on the model, with ``ManyToManyField`` instances appearing last. If
|
||||
you want to change the order in which fields are rendered, you can use the
|
||||
|
|
|
@ -4,8 +4,6 @@ File Uploads
|
|||
|
||||
.. currentmodule:: django.core.files
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When Django handles a file upload, the file data ends up placed in
|
||||
:attr:`request.FILES <django.http.HttpRequest.FILES>` (for more on the
|
||||
``request`` object see the documentation for :doc:`request and response objects
|
||||
|
|
|
@ -29,8 +29,6 @@ from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
|
|||
Configuring the session engine
|
||||
==============================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
By default, Django stores sessions in your database (using the model
|
||||
``django.contrib.sessions.models.Session``). Though this is convenient, in
|
||||
some setups it's faster to store session data elsewhere, so Django can be
|
||||
|
@ -50,9 +48,6 @@ Using cached sessions
|
|||
|
||||
For better performance, you may want to use a cache-based session backend.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
Django 1.0 did not include the ``cached_db`` session backend.
|
||||
|
||||
To store session data using Django's cache system, you'll first need to make
|
||||
sure you've configured your cache; see the :doc:`cache documentation
|
||||
</topics/cache>` for details.
|
||||
|
@ -138,15 +133,10 @@ A session object has the following standard dictionary methods:
|
|||
|
||||
* ``clear()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
``setdefault()`` and ``clear()`` are new in this version.
|
||||
|
||||
It also has these methods:
|
||||
|
||||
* ``flush()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Delete the current session data from the session and regenerate the
|
||||
session key value that is sent back to the user in the cookie. This is
|
||||
used if you want to ensure that the previous session data can't be
|
||||
|
@ -173,8 +163,6 @@ It also has these methods:
|
|||
|
||||
* ``set_expiry(value)``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Sets the expiration time for the session. You can pass a number of
|
||||
different values:
|
||||
|
||||
|
@ -198,24 +186,18 @@ It also has these methods:
|
|||
|
||||
* ``get_expiry_age()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns the number of seconds until this session expires. For sessions
|
||||
with no custom expiration (or those set to expire at browser close), this
|
||||
will equal ``settings.SESSION_COOKIE_AGE``.
|
||||
|
||||
* ``get_expiry_date()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns the date this session will expire. For sessions with no custom
|
||||
expiration (or those set to expire at browser close), this will equal the
|
||||
date ``settings.SESSION_COOKIE_AGE`` seconds from now.
|
||||
|
||||
* ``get_expire_at_browser_close()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns either ``True`` or ``False``, depending on whether the user's
|
||||
session cookie will expire when the user's Web browser is closed.
|
||||
|
||||
|
@ -302,8 +284,6 @@ Here's a typical usage example::
|
|||
Using sessions out of views
|
||||
===========================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
An API is available to manipulate session data outside of a view::
|
||||
|
||||
>>> from django.contrib.sessions.backends.db import SessionStore
|
||||
|
@ -393,8 +373,6 @@ browser-length cookies -- cookies that expire as soon as the user closes his or
|
|||
her browser. Use this if you want people to have to log in every time they open
|
||||
a browser.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This setting is a global default and can be overwritten at a per-session level
|
||||
by explicitly calling ``request.session.set_expiry()`` as described above in
|
||||
`using sessions in views`_.
|
||||
|
@ -424,11 +402,6 @@ A few :doc:`Django settings </ref/settings>` give you control over session behav
|
|||
SESSION_ENGINE
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``cached_db`` backend was added
|
||||
|
||||
Default: ``django.contrib.sessions.backends.db``
|
||||
|
||||
Controls where Django stores session data. Valid values are:
|
||||
|
@ -443,8 +416,6 @@ See `configuring the session engine`_ for more details.
|
|||
SESSION_FILE_PATH
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``/tmp/``
|
||||
|
||||
If you're using file-based session storage, this sets the directory in
|
||||
|
@ -493,8 +464,6 @@ The name of the cookie to use for sessions. This can be whatever you want.
|
|||
SESSION_COOKIE_PATH
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/'``
|
||||
|
||||
The path set on the session cookie. This should either match the URL path of
|
||||
|
|
|
@ -152,8 +152,6 @@ This example is equivalent to::
|
|||
|
||||
.. function:: redirect(to[, permanent=False], *args, **kwargs)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Returns an :class:`~django.http.HttpResponseRedirect` to the appropriate URL
|
||||
for the arguments passed.
|
||||
|
||||
|
|
|
@ -225,8 +225,6 @@ The remaining arguments should be tuples in this format::
|
|||
url
|
||||
---
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. function:: url(regex, view, kwargs=None, name=None, prefix='')
|
||||
|
||||
You can use the ``url()`` function, instead of a tuple, as an argument to
|
||||
|
@ -285,8 +283,6 @@ include
|
|||
A function that takes a full Python import path to another URLconf module that
|
||||
should be "included" in this place.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
:func:`include` also accepts as an argument an iterable that returns URL
|
||||
patterns.
|
||||
|
||||
|
@ -417,8 +413,6 @@ Django encounters ``include()``, it chops off whatever part of the URL matched
|
|||
up to that point and sends the remaining string to the included URLconf for
|
||||
further processing.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Another possibility is to include additional URL patterns not by specifying the
|
||||
URLconf Python module defining them as the `include`_ argument but by using
|
||||
directly the pattern list as returned by `patterns`_ instead. For example::
|
||||
|
@ -637,8 +631,6 @@ the view prefix (as explained in "The view prefix" above) will have no effect.
|
|||
Naming URL patterns
|
||||
===================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
It's fairly common to use the same view function in multiple URL patterns in
|
||||
your URLconf. For example, these two URL patterns both point to the ``archive``
|
||||
view::
|
||||
|
@ -697,8 +689,6 @@ not restricted to valid Python names.
|
|||
URL namespaces
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Namespaced URLs are specified using the ``:`` operator. For example, the main
|
||||
index page of the admin application is referenced using ``admin:index``. This
|
||||
indicates a namespace of ``admin``, and a named URL of ``index``.
|
||||
|
@ -804,8 +794,6 @@ vertical bar (``"|"``) character. You can quite happily use such patterns for
|
|||
matching against incoming URLs and sending them off to views, but you cannot
|
||||
reverse such patterns.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
The ``current_app`` argument allows you to provide a hint to the resolver
|
||||
indicating the application to which the currently executing view belongs.
|
||||
This ``current_app`` argument is used as a hint to resolve application
|
||||
|
@ -935,8 +923,6 @@ get_script_prefix()
|
|||
|
||||
.. function:: get_script_prefix()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
|
||||
:func:`~django.db.models.permalink` to define URLs within your application.
|
||||
However, if your application constructs part of the URL hierarchy itself, you
|
||||
|
|
|
@ -81,12 +81,8 @@ following this algorithm:
|
|||
|
||||
* Failing that, it looks for a cookie.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
In Django version 0.96 and before, the cookie's name is hard-coded to
|
||||
``django_language``. In Django 1,0, The cookie name is set by the
|
||||
``LANGUAGE_COOKIE_NAME`` setting. (The default name is
|
||||
``django_language``.)
|
||||
The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME``
|
||||
setting. (The default name is ``django_language``.)
|
||||
|
||||
* Failing that, it looks at the ``Accept-Language`` HTTP header. This
|
||||
header is sent by your browser and tells the server which language(s) you
|
||||
|
|
|
@ -5,9 +5,6 @@ Pagination
|
|||
.. module:: django.core.paginator
|
||||
:synopsis: Classes to help you easily manage paginated data.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Pagination facilities have been almost fully reworked.
|
||||
|
||||
Django provides a few classes that help you manage paginated data -- that is,
|
||||
data that's split across several pages, with "Previous/Next" links. These
|
||||
classes live in :file:`django/core/paginator.py`.
|
||||
|
|
|
@ -403,8 +403,6 @@ wouldn't know which one of the blocks' content to use.
|
|||
Automatic HTML escaping
|
||||
=======================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When generating HTML from templates, there's always a risk that a variable will
|
||||
include characters that affect the resulting HTML. For example, consider this
|
||||
template fragment::
|
||||
|
|
|
@ -288,9 +288,6 @@ with this command::
|
|||
|
||||
Note that we used ``animals``, not ``myproject.animals``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
You can now choose which test to run.
|
||||
|
||||
You can be even *more* specific by naming an individual test case. To
|
||||
run a single test case in an application (for example, the
|
||||
``AnimalTestCase`` described in the "Writing unit tests" section), add
|
||||
|
@ -393,8 +390,6 @@ database is created by the user specified by ``USER``, so you'll need
|
|||
to make sure that the given user account has sufficient privileges to
|
||||
create a new database on the system.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
For fine-grained control over the character encoding of your test
|
||||
database, use the :setting:`TEST_CHARSET` option. If you're using
|
||||
MySQL, you can also use the :setting:`TEST_COLLATION` option to
|
||||
|
@ -718,8 +713,6 @@ arguments at time of construction:
|
|||
details view, which is a good way to test code paths that use the
|
||||
:meth:`django.http.HttpRequest.is_ajax()` method.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
If you already have the GET arguments in URL-encoded form, you can
|
||||
use that encoding instead of using the data argument. For example,
|
||||
the previous GET request could also be posed as::
|
||||
|
@ -802,8 +795,6 @@ arguments at time of construction:
|
|||
|
||||
The ``extra`` argument acts the same as for :meth:`Client.get`.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
|
||||
If the URL you request with a POST contains encoded parameters, these
|
||||
parameters will be made available in the request.GET data. For example,
|
||||
if you were to make the request::
|
||||
|
@ -820,8 +811,6 @@ arguments at time of construction:
|
|||
|
||||
.. method:: Client.head(path, data={}, follow=False, **extra)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Makes a HEAD request on the provided ``path`` and returns a ``Response``
|
||||
object. Useful for testing RESTful interfaces. Acts just like
|
||||
:meth:`Client.get` except it does not return a message body.
|
||||
|
@ -832,8 +821,6 @@ arguments at time of construction:
|
|||
|
||||
.. method:: Client.options(path, data={}, follow=False, **extra)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Makes an OPTIONS request on the provided ``path`` and returns a
|
||||
``Response`` object. Useful for testing RESTful interfaces.
|
||||
|
||||
|
@ -845,8 +832,6 @@ arguments at time of construction:
|
|||
|
||||
.. method:: Client.put(path, data={}, content_type=MULTIPART_CONTENT, follow=False, **extra)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Makes a PUT request on the provided ``path`` and returns a
|
||||
``Response`` object. Useful for testing RESTful interfaces. Acts just
|
||||
like :meth:`Client.post` except with the PUT request method.
|
||||
|
@ -857,8 +842,6 @@ arguments at time of construction:
|
|||
|
||||
.. method:: Client.delete(path, follow=False, **extra)
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Makes an DELETE request on the provided ``path`` and returns a
|
||||
``Response`` object. Useful for testing RESTful interfaces.
|
||||
|
||||
|
@ -870,8 +853,6 @@ arguments at time of construction:
|
|||
|
||||
.. method:: Client.login(**credentials)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If your site uses Django's :doc:`authentication system</topics/auth>`
|
||||
and you deal with logging in users, you can use the test client's
|
||||
``login()`` method to simulate the effect of a user logging into the
|
||||
|
@ -916,8 +897,6 @@ arguments at time of construction:
|
|||
|
||||
.. method:: Client.logout()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If your site uses Django's :doc:`authentication system</topics/auth>`,
|
||||
the ``logout()`` method can be used to simulate the effect of a user
|
||||
logging out of your site.
|
||||
|
@ -956,8 +935,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
If the rendered page used multiple templates, then ``context`` will be a
|
||||
list of ``Context`` objects, in the order in which they were rendered.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
Regardless of the number of templates used during rendering, you can
|
||||
retrieve context values using the ``[]`` operator. For example, the
|
||||
context variable ``name`` could be retrieved using::
|
||||
|
@ -1127,8 +1104,6 @@ just change the base class of your test from ``unittest.TestCase`` to
|
|||
will continue to be available, but it will be augmented with some useful
|
||||
additions.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. class:: TransactionTestCase()
|
||||
|
||||
Django ``TestCase`` classes make use of database transaction facilities, if
|
||||
|
@ -1176,8 +1151,6 @@ by truncating tables and reloading initial data.
|
|||
Default test client
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: TestCase.client
|
||||
|
||||
Every test case in a ``django.test.TestCase`` instance has access to an
|
||||
|
@ -1305,8 +1278,6 @@ or by the order of test execution.
|
|||
URLconf configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: TestCase.urls
|
||||
|
||||
If your application provides views, you may want to include tests that use the
|
||||
|
@ -1374,8 +1345,6 @@ This test case will flush *all* the test databases before running
|
|||
Emptying the test outbox
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you use Django's custom ``TestCase`` class, the test runner will clear the
|
||||
contents of the test e-mail outbox at the start of each test case.
|
||||
|
||||
|
@ -1384,8 +1353,6 @@ For more detail on e-mail services during tests, see `E-mail services`_.
|
|||
Assertions
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Addded ``msg_prefix`` argument.
|
||||
|
||||
|
@ -1444,8 +1411,6 @@ cause of an failure in your test suite.
|
|||
redirected to ``expected_url`` (including any GET data), and the final
|
||||
page was received with ``target_status_code``.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
If your request used the ``follow`` argument, the ``expected_url`` and
|
||||
``target_status_code`` will be the url and status code for the final
|
||||
point of the redirect chain.
|
||||
|
@ -1496,8 +1461,6 @@ cause of an failure in your test suite.
|
|||
E-mail services
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If any of your Django views send e-mail using :doc:`Django's e-mail
|
||||
functionality </topics/email>`, you probably don't want to send e-mail each time
|
||||
you run a test using that view. For this reason, Django's test runner
|
||||
|
@ -1801,9 +1764,6 @@ also provides some utilities that can be useful during testing.
|
|||
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
|
||||
database.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
``create_test_db()`` now returns the name of the test database.
|
||||
|
||||
.. function:: destroy_test_db(old_database_name, verbosity=1)
|
||||
|
||||
Destroys the database whose name is in stored in :setting:`NAME` in the
|
||||
|
|
Loading…
Reference in New Issue