Documentation (and some small source code) edits from [17432] - [17537]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17540 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
9fa536dc4f
commit
7981efe04f
|
@ -283,9 +283,8 @@ def get_validation_errors(outfile, app=None):
|
||||||
# this format would be nice, but it's a little fiddly).
|
# this format would be nice, but it's a little fiddly).
|
||||||
if '__' in field_name:
|
if '__' in field_name:
|
||||||
continue
|
continue
|
||||||
# Skip ordering on pk, this is always a valid order_by field
|
# Skip ordering on pk. This is always a valid order_by field
|
||||||
# but is an alias and therefore won't be found by
|
# but is an alias and therefore won't be found by opts.get_field.
|
||||||
# opts.get_field.
|
|
||||||
if field_name == 'pk':
|
if field_name == 'pk':
|
||||||
continue
|
continue
|
||||||
try:
|
try:
|
||||||
|
|
|
@ -110,23 +110,23 @@ class CsrfViewMiddleware(object):
|
||||||
# Mechanism to turn off CSRF checks for test suite.
|
# Mechanism to turn off CSRF checks for test suite.
|
||||||
# It comes after the creation of CSRF cookies, so that
|
# It comes after the creation of CSRF cookies, so that
|
||||||
# everything else continues to work exactly the same
|
# everything else continues to work exactly the same
|
||||||
# (e.g. cookies are sent etc), but before the any
|
# (e.g. cookies are sent, etc.), but before any
|
||||||
# branches that call reject()
|
# branches that call reject().
|
||||||
return self._accept(request)
|
return self._accept(request)
|
||||||
|
|
||||||
if request.is_secure():
|
if request.is_secure():
|
||||||
# Suppose user visits http://example.com/
|
# Suppose user visits http://example.com/
|
||||||
# An active network attacker,(man-in-the-middle, MITM) sends a
|
# An active network attacker (man-in-the-middle, MITM) sends a
|
||||||
# POST form which targets https://example.com/detonate-bomb/ and
|
# POST form that targets https://example.com/detonate-bomb/ and
|
||||||
# submits it via javascript.
|
# submits it via JavaScript.
|
||||||
#
|
#
|
||||||
# The attacker will need to provide a CSRF cookie and token, but
|
# The attacker will need to provide a CSRF cookie and token, but
|
||||||
# that is no problem for a MITM and the session independent
|
# that's no problem for a MITM and the session-independent
|
||||||
# nonce we are using. So the MITM can circumvent the CSRF
|
# nonce we're using. So the MITM can circumvent the CSRF
|
||||||
# protection. This is true for any HTTP connection, but anyone
|
# protection. This is true for any HTTP connection, but anyone
|
||||||
# using HTTPS expects better! For this reason, for
|
# using HTTPS expects better! For this reason, for
|
||||||
# https://example.com/ we need additional protection that treats
|
# https://example.com/ we need additional protection that treats
|
||||||
# http://example.com/ as completely untrusted. Under HTTPS,
|
# http://example.com/ as completely untrusted. Under HTTPS,
|
||||||
# Barth et al. found that the Referer header is missing for
|
# Barth et al. found that the Referer header is missing for
|
||||||
# same-domain requests in only about 0.2% of cases or less, so
|
# same-domain requests in only about 0.2% of cases or less, so
|
||||||
# we can use strict Referer checking.
|
# we can use strict Referer checking.
|
||||||
|
@ -141,7 +141,7 @@ class CsrfViewMiddleware(object):
|
||||||
)
|
)
|
||||||
return self._reject(request, REASON_NO_REFERER)
|
return self._reject(request, REASON_NO_REFERER)
|
||||||
|
|
||||||
# Note that request.get_host() includes the port
|
# Note that request.get_host() includes the port.
|
||||||
good_referer = 'https://%s/' % request.get_host()
|
good_referer = 'https://%s/' % request.get_host()
|
||||||
if not same_origin(referer, good_referer):
|
if not same_origin(referer, good_referer):
|
||||||
reason = REASON_BAD_REFERER % (referer, good_referer)
|
reason = REASON_BAD_REFERER % (referer, good_referer)
|
||||||
|
@ -166,14 +166,14 @@ class CsrfViewMiddleware(object):
|
||||||
)
|
)
|
||||||
return self._reject(request, REASON_NO_CSRF_COOKIE)
|
return self._reject(request, REASON_NO_CSRF_COOKIE)
|
||||||
|
|
||||||
# check non-cookie token for match
|
# Check non-cookie token for match.
|
||||||
request_csrf_token = ""
|
request_csrf_token = ""
|
||||||
if request.method == "POST":
|
if request.method == "POST":
|
||||||
request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
|
request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
|
||||||
|
|
||||||
if request_csrf_token == "":
|
if request_csrf_token == "":
|
||||||
# Fall back to X-CSRFToken, to make things easier for AJAX,
|
# Fall back to X-CSRFToken, to make things easier for AJAX,
|
||||||
# and possible for PUT/DELETE
|
# and possible for PUT/DELETE.
|
||||||
request_csrf_token = request.META.get('HTTP_X_CSRFTOKEN', '')
|
request_csrf_token = request.META.get('HTTP_X_CSRFTOKEN', '')
|
||||||
|
|
||||||
if not constant_time_compare(request_csrf_token, csrf_token):
|
if not constant_time_compare(request_csrf_token, csrf_token):
|
||||||
|
|
|
@ -9,9 +9,8 @@ command for the ``polls`` application from the
|
||||||
:doc:`tutorial</intro/tutorial01>`.
|
:doc:`tutorial</intro/tutorial01>`.
|
||||||
|
|
||||||
To do this, just add a ``management/commands`` directory to the application.
|
To do this, just add a ``management/commands`` directory to the application.
|
||||||
Each Python module in that directory will be auto-discovered. Modules having
|
Django will register a ``manage.py`` command for each Python module in that
|
||||||
names not starting with an underscore will be registered as commands that can be
|
directory whose name doesn't begin with an underscore. For example::
|
||||||
executed as an action when you run ``manage.py``::
|
|
||||||
|
|
||||||
polls/
|
polls/
|
||||||
__init__.py
|
__init__.py
|
||||||
|
|
|
@ -697,8 +697,8 @@ subclass::
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The ``FieldListFilter`` API is currently considered internal and prone
|
The ``FieldListFilter`` API is considered internal and might be
|
||||||
to refactoring.
|
changed.
|
||||||
|
|
||||||
.. versionadded:: 1.4
|
.. versionadded:: 1.4
|
||||||
|
|
||||||
|
|
|
@ -44,7 +44,7 @@ Because GeoDjango is included with Django, please refer to Django's
|
||||||
|
|
||||||
.. _spatial_database:
|
.. _spatial_database:
|
||||||
|
|
||||||
Spatial Database
|
Spatial database
|
||||||
----------------
|
----------------
|
||||||
PostgreSQL (with PostGIS), MySQL, Oracle, and SQLite (with SpatiaLite) are
|
PostgreSQL (with PostGIS), MySQL, Oracle, and SQLite (with SpatiaLite) are
|
||||||
the spatial databases currently supported.
|
the spatial databases currently supported.
|
||||||
|
@ -69,7 +69,7 @@ SQLite GEOS, GDAL, PROJ.4, SpatiaLite 3.6.+ Requires
|
||||||
|
|
||||||
.. _geospatial_libs:
|
.. _geospatial_libs:
|
||||||
|
|
||||||
Geospatial Libraries
|
Geospatial libraries
|
||||||
--------------------
|
--------------------
|
||||||
GeoDjango uses and/or provides interfaces for the following open source
|
GeoDjango uses and/or provides interfaces for the following open source
|
||||||
geospatial libraries:
|
geospatial libraries:
|
||||||
|
@ -104,7 +104,7 @@ __ http://www.gaia-gis.it/spatialite/index.html
|
||||||
|
|
||||||
.. _build_from_source:
|
.. _build_from_source:
|
||||||
|
|
||||||
Building from Source
|
Building from source
|
||||||
====================
|
====================
|
||||||
|
|
||||||
When installing from source on UNIX and GNU/Linux systems, please follow
|
When installing from source on UNIX and GNU/Linux systems, please follow
|
||||||
|
@ -156,7 +156,7 @@ script, compile, and install::
|
||||||
Troubleshooting
|
Troubleshooting
|
||||||
^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
Can't find GEOS Library
|
Can't find GEOS library
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
When GeoDjango can't find GEOS, this error is raised:
|
When GeoDjango can't find GEOS, this error is raised:
|
||||||
|
@ -297,7 +297,7 @@ __ http://trac.osgeo.org/gdal/wiki/GdalOgrInPython
|
||||||
Troubleshooting
|
Troubleshooting
|
||||||
^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
Can't find GDAL Library
|
Can't find GDAL library
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
When GeoDjango can't find the GDAL library, the ``HAS_GDAL`` flag
|
When GeoDjango can't find the GDAL library, the ``HAS_GDAL`` flag
|
||||||
|
@ -410,7 +410,7 @@ __ http://www.sqlite.org/download.html
|
||||||
|
|
||||||
.. _spatialitebuild :
|
.. _spatialitebuild :
|
||||||
|
|
||||||
SpatiaLite Library (``libspatialite``) and Tools (``spatialite``)
|
SpatiaLite library (``libspatialite``) and tools (``spatialite``)
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
After SQLite has been built with the R*Tree module enabled, get the latest
|
After SQLite has been built with the R*Tree module enabled, get the latest
|
||||||
|
@ -495,12 +495,12 @@ to build and install::
|
||||||
|
|
||||||
$ sudo python setup.py install
|
$ sudo python setup.py install
|
||||||
|
|
||||||
Post-Installation
|
Post-installation
|
||||||
=================
|
=================
|
||||||
|
|
||||||
.. _spatialdb_template:
|
.. _spatialdb_template:
|
||||||
|
|
||||||
Creating a Spatial Database Template for PostGIS
|
Creating a spatial database template for PostGIS
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
Creating a spatial database with PostGIS is different than normal because
|
Creating a spatial database with PostGIS is different than normal because
|
||||||
|
@ -549,7 +549,7 @@ These commands may be placed in a shell script for later use; for convenience
|
||||||
the following scripts are available:
|
the following scripts are available:
|
||||||
|
|
||||||
=============== =============================================
|
=============== =============================================
|
||||||
PostGIS Version Bash Shell Script
|
PostGIS version Bash shell script
|
||||||
=============== =============================================
|
=============== =============================================
|
||||||
1.3 :download:`create_template_postgis-1.3.sh`
|
1.3 :download:`create_template_postgis-1.3.sh`
|
||||||
1.4 :download:`create_template_postgis-1.4.sh`
|
1.4 :download:`create_template_postgis-1.4.sh`
|
||||||
|
@ -572,44 +572,34 @@ Afterwards, you may create a spatial database by simply specifying
|
||||||
|
|
||||||
.. _create_spatialite_db:
|
.. _create_spatialite_db:
|
||||||
|
|
||||||
Creating a Spatial Database for SpatiaLite
|
Creating a spatial database for SpatiaLite
|
||||||
-------------------------------------------
|
------------------------------------------
|
||||||
|
|
||||||
After the SpatiaLite library and tools have been installed, it is now possible
|
After you've installed SpatiaLite, you'll need to create a number of spatial
|
||||||
to create a spatial database for use with GeoDjango.
|
metadata tables in your database in order to perform spatial queries.
|
||||||
|
|
||||||
For this, a number of spatial metadata tables must be created in the database
|
If you're using SpatiaLite 3.0 or newer, use the ``spatialite`` utility to
|
||||||
before any spatial query is performed against it.
|
call the ``InitSpatiaMetaData()`` function, like this::
|
||||||
|
|
||||||
If you are using SpatiaLite 3.0 or newer then use the ``spatialite`` utility to
|
|
||||||
call the ``InitSpatiaMetaData()`` function which will take care of that (you can
|
|
||||||
safely ignore the error messages shown) then you can skip the rest of this
|
|
||||||
section::
|
|
||||||
|
|
||||||
$ spatialite geodjango.db "SELECT InitSpatialMetaData();"
|
$ spatialite geodjango.db "SELECT InitSpatialMetaData();"
|
||||||
the SPATIAL_REF_SYS table already contains some row(s)
|
the SPATIAL_REF_SYS table already contains some row(s)
|
||||||
InitSpatiaMetaData ()error:"table spatial_ref_sys already exists"
|
InitSpatiaMetaData ()error:"table spatial_ref_sys already exists"
|
||||||
0
|
0
|
||||||
|
|
||||||
If you re using a version of Spatialite older than 3.0 then to achieve the same
|
You can safely ignore the error messages shown. When you've done this, you can
|
||||||
result you need to download a database initialization file and execute the SQL
|
skip the rest of this section.
|
||||||
queries it contains against your database.
|
|
||||||
|
|
||||||
First, get it from the appropiate SpatiaLite Resources page (i.e.
|
If you're using a version of SpatiaLite older than 3.0, you'll need to download
|
||||||
|
a database-initialization file and execute its SQL queries in your database.
|
||||||
|
|
||||||
|
First, get it from the appropriate SpatiaLite Resources page (
|
||||||
http://www.gaia-gis.it/spatialite-2.3.1/resources.html for 2.3 or
|
http://www.gaia-gis.it/spatialite-2.3.1/resources.html for 2.3 or
|
||||||
http://www.gaia-gis.it/spatialite-2.4.0/ for 2.4)::
|
http://www.gaia-gis.it/spatialite-2.4.0/ for 2.4)::
|
||||||
|
|
||||||
$ wget http://www.gaia-gis.it/spatialite-2.3.1/init_spatialite-2.3.sql.gz
|
$ wget http://www.gaia-gis.it/spatialite-2.3.1/init_spatialite-2.3.sql.gz
|
||||||
$ gunzip init_spatialite-2.3.sql.gz
|
$ gunzip init_spatialite-2.3.sql.gz
|
||||||
|
|
||||||
(Or, if you are using SpatiaLite 2.4 then do::
|
Then, use the ``spatialite`` command to initialize a spatial database::
|
||||||
|
|
||||||
$ wget http://www.gaia-gis.it/spatialite-2.4.0/init_spatialite-2.4.sql.gz
|
|
||||||
$ gunzip init_spatialite-2.4.sql.gz
|
|
||||||
|
|
||||||
)
|
|
||||||
|
|
||||||
Now, the ``spatialite`` command can be used to initialize a spatial database::
|
|
||||||
|
|
||||||
$ spatialite geodjango.db < init_spatialite-2.X.sql
|
$ spatialite geodjango.db < init_spatialite-2.X.sql
|
||||||
|
|
||||||
|
@ -629,15 +619,15 @@ features such as the geographic admin or KML sitemaps will not function properly
|
||||||
|
|
||||||
.. _addgoogleprojection:
|
.. _addgoogleprojection:
|
||||||
|
|
||||||
Add Google Projection to ``spatial_ref_sys`` table
|
Add Google projection to ``spatial_ref_sys`` table
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
||||||
.. versionchanged:: 1.2
|
.. versionchanged:: 1.2
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
If running PostGIS 1.4 and above, the entry is already included in the
|
If you're running PostGIS 1.4 or above, you can skip this step. The entry
|
||||||
default ``spatial_ref_sys`` table. You can skip this step.
|
is already included in the default ``spatial_ref_sys`` table.
|
||||||
|
|
||||||
In order to conduct database transformations to the so-called "Google"
|
In order to conduct database transformations to the so-called "Google"
|
||||||
projection (a spherical mercator projection used by Google Maps),
|
projection (a spherical mercator projection used by Google Maps),
|
||||||
|
@ -678,7 +668,7 @@ __ http://code.djangoproject.com/simpleticket
|
||||||
|
|
||||||
.. _libsettings:
|
.. _libsettings:
|
||||||
|
|
||||||
Library Environment Settings
|
Library environment settings
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
By far, the most common problem when installing GeoDjango is that the
|
By far, the most common problem when installing GeoDjango is that the
|
||||||
|
@ -701,7 +691,7 @@ could place the following in their bash profile::
|
||||||
|
|
||||||
export LD_LIBRARY_PATH=/usr/local/lib
|
export LD_LIBRARY_PATH=/usr/local/lib
|
||||||
|
|
||||||
Setting System Library Path
|
Setting system library path
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
On GNU/Linux systems, there is typically a file in ``/etc/ld.so.conf``, which may include
|
On GNU/Linux systems, there is typically a file in ``/etc/ld.so.conf``, which may include
|
||||||
|
@ -740,7 +730,7 @@ Similarly, on Red Hat and CentOS systems::
|
||||||
|
|
||||||
$ sudo yum install binutils
|
$ sudo yum install binutils
|
||||||
|
|
||||||
Platform Specific Instructions
|
Platform-specific instructions
|
||||||
==============================
|
==============================
|
||||||
|
|
||||||
.. _macosx:
|
.. _macosx:
|
||||||
|
@ -749,7 +739,7 @@ Mac OS X
|
||||||
--------
|
--------
|
||||||
|
|
||||||
Because of the variety of packaging systems available for OS X, users have
|
Because of the variety of packaging systems available for OS X, users have
|
||||||
several different options for installing GeoDjango. These options are:
|
several different options for installing GeoDjango. These options are:
|
||||||
|
|
||||||
* :ref:`kyngchaos`
|
* :ref:`kyngchaos`
|
||||||
* :ref:`fink`
|
* :ref:`fink`
|
||||||
|
@ -789,7 +779,7 @@ __ http://python.org/ftp/python/2.6.2/python-2.6.2-macosx2009-04-16.dmg
|
||||||
|
|
||||||
.. _kyngchaos:
|
.. _kyngchaos:
|
||||||
|
|
||||||
KyngChaos Packages
|
KyngChaos packages
|
||||||
^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
William Kyngesburye provides a number of `geospatial library binary packages`__
|
William Kyngesburye provides a number of `geospatial library binary packages`__
|
||||||
|
@ -952,9 +942,9 @@ Ubuntu & Debian GNU/Linux
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The PostGIS SQL files are not placed in the PostgreSQL share directory in
|
The PostGIS SQL files are not placed in the PostgreSQL share directory in
|
||||||
the Debian and Ubuntu packages, and are located instead in a special
|
the Debian and Ubuntu packages. Instead, they're located in a special
|
||||||
directory depending on the release. Thus, when :ref:`spatialdb_template`
|
directory depending on the release. In this case, use the
|
||||||
use the :download:`create_template_postgis-debian.sh` script instead.
|
:download:`create_template_postgis-debian.sh` script
|
||||||
|
|
||||||
.. _ubuntu:
|
.. _ubuntu:
|
||||||
|
|
||||||
|
@ -1049,10 +1039,11 @@ Debian
|
||||||
|
|
||||||
4.0 (Etch)
|
4.0 (Etch)
|
||||||
^^^^^^^^^^
|
^^^^^^^^^^
|
||||||
|
|
||||||
The situation here is the same as that of Ubuntu :ref:`heron` -- in other words,
|
The situation here is the same as that of Ubuntu :ref:`heron` -- in other words,
|
||||||
some packages must be built from source to work properly with GeoDjango.
|
some packages must be built from source to work properly with GeoDjango.
|
||||||
|
|
||||||
Binary Packages
|
Binary packages
|
||||||
~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~
|
||||||
The following command will install acceptable binary packages, as well as
|
The following command will install acceptable binary packages, as well as
|
||||||
the development tools necessary to build the rest of the requirements::
|
the development tools necessary to build the rest of the requirements::
|
||||||
|
@ -1075,7 +1066,7 @@ Optional packages:
|
||||||
|
|
||||||
* ``libgeoip``: for :ref:`GeoIP <ref-geoip>` support
|
* ``libgeoip``: for :ref:`GeoIP <ref-geoip>` support
|
||||||
|
|
||||||
Source Packages
|
Source packages
|
||||||
~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~
|
||||||
You will still have to install :ref:`geosbuild`, :ref:`proj4`,
|
You will still have to install :ref:`geosbuild`, :ref:`proj4`,
|
||||||
:ref:`postgis`, and :ref:`gdalbuild` from source. Please follow the
|
:ref:`postgis`, and :ref:`gdalbuild` from source. Please follow the
|
||||||
|
@ -1104,7 +1095,7 @@ in the above command with the appropriate PostgreSQL version.
|
||||||
|
|
||||||
.. _post_install:
|
.. _post_install:
|
||||||
|
|
||||||
Post-installation Notes
|
Post-installation notes
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
If the PostgreSQL database cluster was not initiated after installing, then it
|
If the PostgreSQL database cluster was not initiated after installing, then it
|
||||||
|
@ -1234,7 +1225,7 @@ installer.
|
||||||
|
|
||||||
.. _OSGeo4W installer: http://trac.osgeo.org/osgeo4w/
|
.. _OSGeo4W installer: http://trac.osgeo.org/osgeo4w/
|
||||||
|
|
||||||
Modify Windows Environment
|
Modify Windows environment
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
In order to use GeoDjango, you will need to add your Python and OSGeo4W
|
In order to use GeoDjango, you will need to add your Python and OSGeo4W
|
||||||
|
@ -1269,8 +1260,8 @@ script, :download:`geodjango_setup.bat`.
|
||||||
then you will need to modify the ``OSGEO4W_ROOT`` and/or ``PYTHON_ROOT``
|
then you will need to modify the ``OSGEO4W_ROOT`` and/or ``PYTHON_ROOT``
|
||||||
variables accordingly.
|
variables accordingly.
|
||||||
|
|
||||||
Install Django and Setup Database
|
Install Django and set up database
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
Finally, :ref:`install Django <installing-official-release>` on your system.
|
Finally, :ref:`install Django <installing-official-release>` on your system.
|
||||||
You do not need to create a spatial database template, as one named
|
You do not need to create a spatial database template, as one named
|
||||||
|
|
|
@ -1,11 +1,11 @@
|
||||||
======================
|
======================
|
||||||
Testing GeoDjango Apps
|
Testing GeoDjango apps
|
||||||
======================
|
======================
|
||||||
|
|
||||||
.. versionchanged:: 1.2
|
.. versionchanged:: 1.2
|
||||||
|
|
||||||
In Django 1.2, the addition of :ref:`spatial-backends` simplified the
|
In Django 1.2, the addition of :ref:`spatial-backends` simplified the
|
||||||
process of testing GeoDjango applications -- the process is now the
|
process of testing GeoDjango applications. The process is now the
|
||||||
same as :doc:`/topics/testing`.
|
same as :doc:`/topics/testing`.
|
||||||
|
|
||||||
Included in this documentation are some additional notes and settings
|
Included in this documentation are some additional notes and settings
|
||||||
|
@ -31,7 +31,7 @@ Settings
|
||||||
.. versionchanged:: 1.2
|
.. versionchanged:: 1.2
|
||||||
|
|
||||||
This setting may be used to customize the name of the PostGIS template
|
This setting may be used to customize the name of the PostGIS template
|
||||||
database to use. In Django versions 1.2 and above, it automatically
|
database to use. In Django versions 1.2 and above, it automatically
|
||||||
defaults to ``'template_postgis'`` (the same name used in the
|
defaults to ``'template_postgis'`` (the same name used in the
|
||||||
:ref:`installation documentation <spatialdb_template>`).
|
:ref:`installation documentation <spatialdb_template>`).
|
||||||
|
|
||||||
|
@ -42,25 +42,25 @@ defaults to ``'template_postgis'`` (the same name used in the
|
||||||
|
|
||||||
When GeoDjango's spatial backend initializes on PostGIS, it has to perform
|
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
|
a SQL query to determine the version in order to figure out what
|
||||||
features are available. Advanced users wishing to prevent this additional
|
features are available. Advanced users wishing to prevent this additional
|
||||||
query may set the version manually using a 3-tuple of integers specifying
|
query may set the version manually using a 3-tuple of integers specifying
|
||||||
the major, minor, and subminor version numbers for PostGIS. For example,
|
the major, minor, and subminor version numbers for PostGIS. For example,
|
||||||
to configure for PostGIS 1.5.2 you would use::
|
to configure for PostGIS 1.5.2 you would use::
|
||||||
|
|
||||||
POSTGIS_VERSION = (1, 5, 2)
|
POSTGIS_VERSION = (1, 5, 2)
|
||||||
|
|
||||||
Obtaining Sufficient Privileges
|
Obtaining sufficient privileges
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
Depending on your configuration, this section describes several methods to
|
Depending on your configuration, this section describes several methods to
|
||||||
configure a database user with sufficient privileges to run tests for
|
configure a database user with sufficient privileges to run tests for
|
||||||
GeoDjango applications on PostgreSQL. If your
|
GeoDjango applications on PostgreSQL. If your
|
||||||
:ref:`spatial database template <spatialdb_template>`
|
:ref:`spatial database template <spatialdb_template>`
|
||||||
was created like in the instructions, then your testing database user
|
was created like in the instructions, then your testing database user
|
||||||
only needs to have the ability to create databases. In other configurations,
|
only needs to have the ability to create databases. In other configurations,
|
||||||
you may be required to use a database superuser.
|
you may be required to use a database superuser.
|
||||||
|
|
||||||
Create Database User
|
Create database user
|
||||||
^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
To make database user with the ability to create databases, use the
|
To make database user with the ability to create databases, use the
|
||||||
|
@ -76,7 +76,7 @@ Alternatively, you may alter an existing user's role from the SQL shell
|
||||||
|
|
||||||
postgres# ALTER ROLE <user_name> CREATEDB NOSUPERUSER NOCREATEROLE;
|
postgres# ALTER ROLE <user_name> CREATEDB NOSUPERUSER NOCREATEROLE;
|
||||||
|
|
||||||
Create Database Superuser
|
Create database superuser
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
This may be done at the time the user is created, for example::
|
This may be done at the time the user is created, for example::
|
||||||
|
@ -89,7 +89,7 @@ is done from an existing superuser account)::
|
||||||
postgres# ALTER ROLE <user_name> SUPERUSER;
|
postgres# ALTER ROLE <user_name> SUPERUSER;
|
||||||
|
|
||||||
|
|
||||||
Create Local PostgreSQL Database
|
Create local PostgreSQL database
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
1. Initialize database: ``initdb -D /path/to/user/db``
|
1. Initialize database: ``initdb -D /path/to/user/db``
|
||||||
|
@ -114,8 +114,8 @@ spatial database entitled ``template_postgis``.
|
||||||
SpatiaLite
|
SpatiaLite
|
||||||
==========
|
==========
|
||||||
|
|
||||||
You need to make sure needed spatial tables are created in your test spatial
|
Make sure the necessary spatial tables are created in your test spatial
|
||||||
database as described in :ref:`create_spatialite_db`. Then all you have to do is::
|
database, as described in :ref:`create_spatialite_db`. Then just do this::
|
||||||
|
|
||||||
$ python manage.py test
|
$ python manage.py test
|
||||||
|
|
||||||
|
@ -127,18 +127,18 @@ Settings
|
||||||
``SPATIALITE_SQL``
|
``SPATIALITE_SQL``
|
||||||
^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
(only relevant when using a SpatiaLite version older than 3.0).
|
Only relevant when using a SpatiaLite version older than 3.0.
|
||||||
|
|
||||||
By default, the GeoDjango test runner looks for the SpatiaLite SQL in the
|
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
|
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
|
``manage.py`` is located). To use a different location, add the following to
|
||||||
you may add the following to your settings::
|
your settings::
|
||||||
|
|
||||||
SPATIALITE_SQL='/path/to/init_spatialite-2.3.sql'
|
SPATIALITE_SQL='/path/to/init_spatialite-2.3.sql'
|
||||||
|
|
||||||
.. _geodjango-tests:
|
.. _geodjango-tests:
|
||||||
|
|
||||||
GeoDjango Tests
|
GeoDjango tests
|
||||||
===============
|
===============
|
||||||
|
|
||||||
.. versionchanged:: 1.3
|
.. versionchanged:: 1.3
|
||||||
|
|
|
@ -954,10 +954,10 @@ creating the ``myapp`` app::
|
||||||
|
|
||||||
.. versionadded:: 1.4
|
.. versionadded:: 1.4
|
||||||
|
|
||||||
When Django copies the app template files, it also renders the files
|
When Django copies the app template files, it also renders certain files
|
||||||
whose extension matches those passed with the ``--extension`` option (``py``
|
through the template engine: the files whose extensions match the
|
||||||
by default) and those files which names are passed with the ``--name`` option
|
``--extension`` option (``py`` by default) and the files whose names are passed
|
||||||
using the template engine. The :class:`template context
|
with the ``--name`` option. The :class:`template context
|
||||||
<django.template.Context>` used is:
|
<django.template.Context>` used is:
|
||||||
|
|
||||||
- Any option passed to the startapp command
|
- Any option passed to the startapp command
|
||||||
|
@ -1017,10 +1017,10 @@ when creating the ``myproject`` project::
|
||||||
|
|
||||||
django-admin.py startproject --template=/Users/jezdez/Code/my_project_template myproject
|
django-admin.py startproject --template=/Users/jezdez/Code/my_project_template myproject
|
||||||
|
|
||||||
When Django copies the project template files, it will also render the files
|
When Django copies the project template files, it also renders certain files
|
||||||
whose extension matches those passed with the ``--extension`` option (``py``
|
through the template engine: the files whose extensions match the
|
||||||
by default) and those files which names are passed with the ``--name`` option
|
``--extension`` option (``py`` by default) and the files whose names are passed
|
||||||
using the template engine. The :class:`template context
|
with the ``--name`` option. The :class:`template context
|
||||||
<django.template.Context>` used is:
|
<django.template.Context>` used is:
|
||||||
|
|
||||||
- Any option passed to the startproject command
|
- Any option passed to the startproject command
|
||||||
|
|
|
@ -756,31 +756,44 @@ Default: ``False``
|
||||||
|
|
||||||
A boolean that turns on/off debug mode.
|
A boolean that turns on/off debug mode.
|
||||||
|
|
||||||
If you define custom settings, `django/views/debug.py`_ has a
|
Never deploy a site into production with :setting:`DEBUG` turned on.
|
||||||
``HIDDEN_SETTINGS`` regular expression which will hide from the DEBUG view
|
|
||||||
anything that contains ``'API'``, ``'TOKEN'``, ``'KEY'``, ``'SECRET'``,
|
Did you catch that? NEVER deploy a site into production with :setting:`DEBUG`
|
||||||
``'PASS'``, ``'PROFANITIES_LIST'``, or ``'SIGNATURE'``. This allows untrusted
|
turned on.
|
||||||
users to be able to give backtraces without seeing sensitive (or offensive)
|
|
||||||
settings.
|
One of the main features of debug mode is the display of detailed error pages.
|
||||||
|
If your app raises an exception when ``DEBUG`` is ``True``, Django will display
|
||||||
|
a detailed traceback, including a lot of metadata about your environment, such
|
||||||
|
as all the currently defined Django settings (from ``settings.py``).
|
||||||
|
|
||||||
|
As a security measure, Django will *not* include settings that might be
|
||||||
|
sensitive (or offensive), such as ``SECRET_KEY`` or ``PROFANITIES_LIST``.
|
||||||
|
Specifically, it will exclude any setting whose name includes any of the
|
||||||
|
following:
|
||||||
|
|
||||||
|
* API
|
||||||
|
* KEY
|
||||||
|
* PASS
|
||||||
|
* PROFANITIES_LIST
|
||||||
|
* SECRET
|
||||||
|
* SIGNATURE
|
||||||
|
* TOKEN
|
||||||
|
|
||||||
.. versionchanged:: 1.4
|
.. versionchanged:: 1.4
|
||||||
|
|
||||||
``'PASSWORD'`` changed to ``'PASS'``. ``'API'``, ``'TOKEN'``, ``'KEY'``
|
We changed ``'PASSWORD'`` ``'PASS'``. ``'API'``, ``'TOKEN'`` and ``'KEY'``
|
||||||
were added.
|
were added.
|
||||||
|
|
||||||
Note that due to how regular expression matching works ``'PASS'`` will also
|
Note that these are *partial* matches. ``'PASS'`` will also match PASSWORD,
|
||||||
match PASSWORD, just as ``'TOKEN'`` will also match TOKENIZED and so on.
|
just as ``'TOKEN'`` will also match TOKENIZED and so on.
|
||||||
|
|
||||||
Still, note that there are always going to be sections of your debug output
|
Still, note that there are always going to be sections of your debug output
|
||||||
that are inappropriate for public consumption. File paths, configuration
|
that are inappropriate for public consumption. File paths, configuration
|
||||||
options, and the like all give attackers extra information about your server.
|
options and the like all give attackers extra information about your server.
|
||||||
|
|
||||||
It is also important to remember that when running with :setting:`DEBUG`
|
It is also important to remember that when running with :setting:`DEBUG`
|
||||||
turned on, Django will remember every SQL query it executes. This is useful
|
turned on, Django will remember every SQL query it executes. This is useful
|
||||||
when you are debugging, but on a production server, it will rapidly consume
|
when you're debugging, but it'll rapidly consume memory on a production server.
|
||||||
memory.
|
|
||||||
|
|
||||||
Never deploy a site into production with :setting:`DEBUG` turned on.
|
|
||||||
|
|
||||||
.. _django/views/debug.py: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py
|
.. _django/views/debug.py: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py
|
||||||
|
|
||||||
|
|
|
@ -171,13 +171,12 @@ Django 1.4 introduces a cookie-based session backend that uses the tools for
|
||||||
:doc:`cryptographic signing </topics/signing>` to store the session data in
|
:doc:`cryptographic signing </topics/signing>` to store the session data in
|
||||||
the client's browser.
|
the client's browser.
|
||||||
|
|
||||||
+.. warning::
|
.. warning::
|
||||||
+
|
|
||||||
+ Session data is signed and validated by the server, but is not
|
Session data is signed and validated by the server, but it's not
|
||||||
+ encrypted. This means that a user can view any data stored in the
|
encrypted. This means a user can view any data stored in the
|
||||||
+ session, but cannot change it. Please read the documentation for
|
session but cannot change it. Please read the documentation for
|
||||||
+ further clarification before using this backend.
|
further clarification before using this backend.
|
||||||
+
|
|
||||||
|
|
||||||
See the :ref:`cookie-based session backend <cookie-session-backend>` docs for
|
See the :ref:`cookie-based session backend <cookie-session-backend>` docs for
|
||||||
more information.
|
more information.
|
||||||
|
@ -1027,9 +1026,10 @@ Output of :djadmin:`manage.py help <help>`
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
:djadmin:`manage.py help <help>` now groups available commands by application.
|
:djadmin:`manage.py help <help>` now groups available commands by application.
|
||||||
If you depended on its output, for instance if you parsed it, you must update
|
If you depended on the output of this command -- if you parsed it, for example
|
||||||
your scripts. To obtain the list of all available management commands in a
|
-- then you'll need to update your code. To get a list of all available
|
||||||
script, you can use :djadmin:`manage.py help --commands <help>` instead.
|
management commands in a script, use
|
||||||
|
:djadmin:`manage.py help --commands <help>` instead.
|
||||||
|
|
||||||
Features deprecated in 1.4
|
Features deprecated in 1.4
|
||||||
==========================
|
==========================
|
||||||
|
@ -1185,17 +1185,14 @@ This attribute was confusingly named ``HttpRequest.raw_post_data``, but it
|
||||||
actually provided the body of the HTTP request. It's been renamed to
|
actually provided the body of the HTTP request. It's been renamed to
|
||||||
``HttpRequest.body``, and ``HttpRequest.raw_post_data`` has been deprecated.
|
``HttpRequest.body``, and ``HttpRequest.raw_post_data`` has been deprecated.
|
||||||
|
|
||||||
``django.contrib.sitemaps`` bugfix with potential performance implications
|
``django.contrib.sitemaps`` bug fix with potential performance implications
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
In previous versions the Paginator objects used in sitemap classes were
|
In previous versions, ``Paginator`` objects used in sitemap classes were
|
||||||
cached and could result in stale sitemap indexes. Removing this cache causes
|
cached, which could result in stale site maps. We've removed the caching, so
|
||||||
new Paginator objects to be created and the
|
each request to a site map now creates a new Paginator object and calls the
|
||||||
:attr:`~django.contrib.sitemaps.Sitemap.items()` method of the
|
:attr:`~django.contrib.sitemaps.Sitemap.items()` method of the
|
||||||
:class:`~django.contrib.sitemaps.Sitemap` subclass to be called during every
|
:class:`~django.contrib.sitemaps.Sitemap` subclass. Depending on what your
|
||||||
sitemap-related request.
|
``items()`` method is doing, this may have a negative performance impact.
|
||||||
|
To mitigate the performance impact, consider using the :doc:`caching
|
||||||
If the :attr:`django.contrib.sitemaps.Sitemap.items()` method returns a
|
framework </topics/cache>` within your ``Sitemap`` subclass.
|
||||||
``QuerySet`` its length will be evaluated which may lead to extra database
|
|
||||||
queries. To mitigate the performance impact consider using the :doc:`caching
|
|
||||||
framework </topics/cache>`.
|
|
||||||
|
|
|
@ -440,7 +440,7 @@ Including other URLconfs
|
||||||
At any point, your ``urlpatterns`` can "include" other URLconf modules. This
|
At any point, your ``urlpatterns`` can "include" other URLconf modules. This
|
||||||
essentially "roots" a set of URLs below other ones.
|
essentially "roots" a set of URLs below other ones.
|
||||||
|
|
||||||
For example, here's an except of the URLconf for the `Django Web site`_
|
For example, here's an excerpt of the URLconf for the `Django Web site`_
|
||||||
itself. It includes a number of other URLconfs::
|
itself. It includes a number of other URLconfs::
|
||||||
|
|
||||||
from django.conf.urls import patterns, url, include
|
from django.conf.urls import patterns, url, include
|
||||||
|
@ -849,7 +849,7 @@ This ``current_app`` argument is used as a hint to resolve application
|
||||||
namespaces into URLs on specific application instances, according to the
|
namespaces into URLs on specific application instances, according to the
|
||||||
:ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`.
|
:ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`.
|
||||||
|
|
||||||
You can use ``kwargs`` instead of ``args``, for example::
|
You can use ``kwargs`` instead of ``args``. For example::
|
||||||
|
|
||||||
>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
|
>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
|
||||||
'/admin/auth/'
|
'/admin/auth/'
|
||||||
|
@ -976,7 +976,7 @@ A :class:`ResolverMatch` object can also be assigned to a triple::
|
||||||
information it provides) is not available in earlier Django releases.
|
information it provides) is not available in earlier Django releases.
|
||||||
|
|
||||||
One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
|
One possible use of :func:`~django.core.urlresolvers.resolve` would be to test
|
||||||
if a view would raise a ``Http404`` error before redirecting to it::
|
whether a view would raise a ``Http404`` error before redirecting to it::
|
||||||
|
|
||||||
from urlparse import urlparse
|
from urlparse import urlparse
|
||||||
from django.core.urlresolvers import resolve
|
from django.core.urlresolvers import resolve
|
||||||
|
|
|
@ -186,16 +186,15 @@ instead of the default for English, a comma.
|
||||||
Limitations of the provided locale formats
|
Limitations of the provided locale formats
|
||||||
==========================================
|
==========================================
|
||||||
|
|
||||||
Some locales use context-sensitive formats for numbers, which Djangos
|
Some locales use context-sensitive formats for numbers, which Django's
|
||||||
localization system cannot handle automatically.
|
localization system cannot handle automatically.
|
||||||
|
|
||||||
|
|
||||||
Switzerland (German)
|
Switzerland (German)
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
The Swiss number formatting depends on the type of number that is being
|
The Swiss number formatting depends on the type of number that is being
|
||||||
formatted. For monetary values, a comma is used as the thousand separator and
|
formatted. For monetary values, a comma is used as the thousand separator and
|
||||||
a decimal point for the decimal separator, for all other numbers, a comma is
|
a decimal point for the decimal separator. For all other numbers, a comma is
|
||||||
used as decimal separator and a space as thousand separator. The locale format
|
used as decimal separator and a space as thousand separator. The locale format
|
||||||
provided by Django uses the generic separators, a comma for decimal and a space
|
provided by Django uses the generic separators, a comma for decimal and a space
|
||||||
for thousand separators.
|
for thousand separators.
|
||||||
|
|
|
@ -297,7 +297,7 @@ Lazy translation
|
||||||
Use the lazy versions of translation functions in
|
Use the lazy versions of translation functions in
|
||||||
:mod:`django.utils.translation` (easily recognizable by the ``lazy`` suffix in
|
:mod:`django.utils.translation` (easily recognizable by the ``lazy`` suffix in
|
||||||
their names) to translate strings lazily -- when the value is accessed rather
|
their names) to translate strings lazily -- when the value is accessed rather
|
||||||
than when they are called.
|
than when they're called.
|
||||||
|
|
||||||
These functions store a lazy reference to the string -- not the actual
|
These functions store a lazy reference to the string -- not the actual
|
||||||
translation. The translation itself will be done when the string is used in a
|
translation. The translation itself will be done when the string is used in a
|
||||||
|
@ -306,10 +306,10 @@ string context, such as in template rendering.
|
||||||
This is essential when calls to these functions are located in code paths that
|
This is essential when calls to these functions are located in code paths that
|
||||||
are executed at module load time.
|
are executed at module load time.
|
||||||
|
|
||||||
As this is something that can easily happen when defining models, forms and
|
This is something that can easily happen when defining models, forms and
|
||||||
model forms (the declarative notation Django offers for them is implemented in a
|
model forms, because Django implements these such that their fields are
|
||||||
way such that their fields are actually class level attributes) this means you
|
actually class-level attributes. For that reason, make sure to use lazy
|
||||||
need to make sure to use lazy translations in the following cases:
|
translations in the following cases:
|
||||||
|
|
||||||
Model fields and relationships ``verbose_name`` and ``help_text`` option values
|
Model fields and relationships ``verbose_name`` and ``help_text`` option values
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
Loading…
Reference in New Issue