summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorTim Graham <timograham@gmail.com>2012-12-25 03:40:08 -0500
committerTim Graham <timograham@gmail.com>2012-12-25 04:44:09 -0500
commit9c5a6adf3341c59efee4ca6d0037f8069185e0e3 (patch)
treeafbf23a58e8732717288cb2b1837ae544659eb7a /docs
parentb70498d675bbd96849b466cdd45c1c189f227444 (diff)
downloaddjango-9c5a6adf3341c59efee4ca6d0037f8069185e0e3.tar.gz
Fixed more broken links. refs #19516
Diffstat (limited to 'docs')
-rw-r--r--docs/ref/contrib/gis/gdal.txt66
-rw-r--r--docs/ref/models/fields.txt2
-rw-r--r--docs/ref/models/options.txt6
-rw-r--r--docs/ref/models/querysets.txt2
-rw-r--r--docs/ref/settings.txt8
-rw-r--r--docs/releases/1.1-alpha-1.txt10
-rw-r--r--docs/releases/1.1.txt10
-rw-r--r--docs/releases/1.3-alpha-1.txt17
-rw-r--r--docs/releases/1.4.txt4
9 files changed, 65 insertions, 60 deletions
diff --git a/docs/ref/contrib/gis/gdal.txt b/docs/ref/contrib/gis/gdal.txt
index c4b29bead7..161efa39de 100644
--- a/docs/ref/contrib/gis/gdal.txt
+++ b/docs/ref/contrib/gis/gdal.txt
@@ -13,7 +13,7 @@ of GDAL is the `OGR`__ Simple Features Library, which specializes
in reading and writing vector geographic data in a variety of standard
formats.
-GeoDjango provides a high-level Python interface for some of the
+GeoDjango provides a high-level Python interface for some of the
capabilities of OGR, including the reading and coordinate transformation
of vector spatial data.
@@ -22,7 +22,7 @@ of vector spatial data.
Although the module is named ``gdal``, GeoDjango only supports
some of the capabilities of OGR. Thus, none of GDAL's features
with respect to raster (image) data are supported at this time.
-
+
__ http://www.gdal.org/
__ http://www.gdal.org/ogr/
@@ -68,13 +68,13 @@ each feature in that layer.
also supports a variety of more complex data sources, including
databases, that may be accessed by passing a special name string instead
of a path. For more information, see the `OGR Vector Formats`__
- documentation. The :attr:`name` property of a ``DataSource``
+ documentation. The :attr:`name` property of a ``DataSource``
instance gives the OGR name of the underlying data source that it is
using.
- Once you've created your ``DataSource``, you can find out how many
- layers of data it contains by accessing the :attr:`layer_count` property,
- or (equivalently) by using the ``len()`` function. For information on
+ Once you've created your ``DataSource``, you can find out how many
+ layers of data it contains by accessing the :attr:`layer_count` property,
+ or (equivalently) by using the ``len()`` function. For information on
accessing the layers of data themselves, see the next section::
>>> from django.contrib.gis.gdal import DataSource
@@ -105,7 +105,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
Python container of ``Layer`` objects. For example, you can access a
specific layer by its index (e.g. ``ds[0]`` to access the first
layer), or you can iterate over all the layers in the container in a
- ``for`` loop. The ``Layer`` itself acts as a container for geometric
+ ``for`` loop. The ``Layer`` itself acts as a container for geometric
features.
Typically, all the features in a given layer have the same geometry type.
@@ -120,7 +120,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
The example output is from the cities data source, loaded above, which
evidently contains one layer, called ``"cities"``, which contains three
- point features. For simplicity, the examples below assume that you've
+ point features. For simplicity, the examples below assume that you've
stored that layer in the variable ``layer``::
>>> layer = ds[0]
@@ -169,7 +169,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
>>> [ft.__name__ for ft in layer.field_types]
['OFTString', 'OFTReal', 'OFTReal', 'OFTDate']
-
+
.. attribute:: field_widths
Returns a list of the maximum field widths for each of the fields in
@@ -181,7 +181,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
.. attribute:: field_precisions
Returns a list of the numeric precisions for each of the fields in
- this layer. This is meaningless (and set to zero) for non-numeric
+ this layer. This is meaningless (and set to zero) for non-numeric
fields::
>>> layer.field_precisions
@@ -189,7 +189,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
.. attribute:: extent
- Returns the spatial extent of this layer, as an :class:`Envelope`
+ Returns the spatial extent of this layer, as an :class:`Envelope`
object::
>>> layer.extent.tuple
@@ -214,7 +214,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
Property that may be used to retrieve or set a spatial filter for this
layer. A spatial filter can only be set with an :class:`OGRGeometry`
- instance, a 4-tuple extent, or ``None``. When set with something
+ instance, a 4-tuple extent, or ``None``. When set with something
other than ``None``, only features that intersect the filter will be
returned when iterating over the layer::
@@ -258,9 +258,9 @@ __ http://www.gdal.org/ogr/ogr_formats.html
given capability (a string). Examples of valid capability strings
include: ``'RandomRead'``, ``'SequentialWrite'``, ``'RandomWrite'``,
``'FastSpatialFilter'``, ``'FastFeatureCount'``, ``'FastGetExtent'``,
- ``'CreateField'``, ``'Transactions'``, ``'DeleteFeature'``, and
+ ``'CreateField'``, ``'Transactions'``, ``'DeleteFeature'``, and
``'FastSetNextByIndex'``.
-
+
``Feature``
-----------
@@ -295,14 +295,14 @@ __ http://www.gdal.org/ogr/ogr_formats.html
Returns the type of geometry for this feature, as an :class:`OGRGeomType`
object. This will be the same for all features in a given layer, and
- is equivalent to the :attr:`Layer.geom_type` property of the
- :class:`Layer`` object the feature came from.
+ is equivalent to the :attr:`Layer.geom_type` property of the
+ :class:`Layer` object the feature came from.
.. attribute:: num_fields
Returns the number of fields of data associated with the feature.
This will be the same for all features in a given layer, and is
- equivalent to the :attr:`Layer.num_fields` property of the
+ equivalent to the :attr:`Layer.num_fields` property of the
:class:`Layer` object the feature came from.
.. attribute:: fields
@@ -350,7 +350,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html
.. attribute:: type
Returns the OGR type of this field, as an integer. The
- ``FIELD_CLASSES`` dictionary maps these values onto
+ ``FIELD_CLASSES`` dictionary maps these values onto
subclasses of ``Field``::
>>> city['Density'].type
@@ -365,8 +365,8 @@ __ http://www.gdal.org/ogr/ogr_formats.html
.. attribute:: value
- Returns the value of this field. The ``Field`` class itself
- returns the value as a string, but each subclass returns the
+ Returns the value of this field. The ``Field`` class itself
+ returns the value as a string, but each subclass returns the
value in the most appropriate form::
>>> city['Population'].value
@@ -433,10 +433,10 @@ OGR Geometries
``OGRGeometry``
---------------
-:class:`OGRGeometry` objects share similar functionality with
+:class:`OGRGeometry` objects share similar functionality with
:class:`~django.contrib.gis.geos.GEOSGeometry` objects, and are thin
-wrappers around OGR's internal geometry representation. Thus,
-they allow for more efficient access to data when using :class:`DataSource`.
+wrappers around OGR's internal geometry representation. Thus,
+they allow for more efficient access to data when using :class:`DataSource`.
Unlike its GEOS counterpart, :class:`OGRGeometry` supports spatial reference
systems and coordinate transformation::
@@ -446,10 +446,10 @@ systems and coordinate transformation::
.. class:: OGRGeometry(geom_input[, srs=None])
This object is a wrapper for the `OGR Geometry`__ class.
- These objects are instantiated directly from the given ``geom_input``
+ These objects are instantiated directly from the given ``geom_input``
parameter, which may be a string containing WKT, HEX, GeoJSON, a ``buffer``
containing WKB data, or an :class:`OGRGeomType` object. These objects
- are also returned from the :class:`Feature.geom` attribute, when
+ are also returned from the :class:`Feature.geom` attribute, when
reading vector data from :class:`Layer` (which is in turn a part of
a :class:`DataSource`).
@@ -557,14 +557,14 @@ systems and coordinate transformation::
.. attribute:: srid
- Returns or sets the spatial reference identifier corresponding to
+ Returns or sets the spatial reference identifier corresponding to
:class:`SpatialReference` of this geometry. Returns ``None`` if
there is no spatial reference information associated with this
geometry, or if an SRID cannot be determined.
.. attribute:: geos
- Returns a :class:`~django.contrib.gis.geos.GEOSGeometry` object
+ Returns a :class:`~django.contrib.gis.geos.GEOSGeometry` object
corresponding to this geometry.
.. attribute:: gml
@@ -762,9 +762,9 @@ systems and coordinate transformation::
.. attribute:: z
- Returns a list of Z coordinates in this line, or ``None`` if the
+ Returns a list of Z coordinates in this line, or ``None`` if the
line does not have Z coordinates::
-
+
>>> OGRGeometry('LINESTRING (1 2 3,4 5 6)').z
[3.0, 6.0]
@@ -885,7 +885,7 @@ Coordinate System Objects
Spatial reference objects are initialized on the given ``srs_input``,
which may be one of the following:
-
+
* OGC Well Known Text (WKT) (a string)
* EPSG code (integer or string)
* PROJ.4 string
@@ -912,7 +912,7 @@ Coordinate System Objects
.. method:: __getitem__(target)
Returns the value of the given string attribute node, ``None`` if the node
- doesn't exist. Can also take a tuple as a parameter, (target, child),
+ doesn't exist. Can also take a tuple as a parameter, (target, child),
where child is the index of the attribute in the WKT. For example::
>>> wkt = 'GEOGCS["WGS 84", DATUM["WGS_1984, ... AUTHORITY["EPSG","4326"]]')
@@ -1011,7 +1011,7 @@ Coordinate System Objects
.. attribute:: units
- Returns a 2-tuple of the units value and the units name,
+ Returns a 2-tuple of the units value and the units name,
and will automatically determines whether to return the linear
or angular units.
@@ -1073,7 +1073,7 @@ Coordinate System Objects
.. class:: CoordTransform(source, target)
-Represents a coordinate system transform. It is initialized with two
+Represents a coordinate system transform. It is initialized with two
:class:`SpatialReference`, representing the source and target coordinate
systems, respectively. These objects should be used when performing
the same coordinate transformation repeatedly on different geometries::
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index cd1185585c..a33c985e2c 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -919,7 +919,7 @@ A :class:`CharField` for a URL.
The default form widget for this field is a :class:`~django.forms.TextInput`.
Like all :class:`CharField` subclasses, :class:`URLField` takes the optional
-:attr:`~CharField.max_length`argument. If you don't specify
+:attr:`~CharField.max_length` argument. If you don't specify
:attr:`~CharField.max_length`, a default of 200 is used.
.. versionadded:: 1.5
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
index a577135271..ac20422915 100644
--- a/docs/ref/models/options.txt
+++ b/docs/ref/models/options.txt
@@ -85,14 +85,14 @@ Django quotes column and table names behind the scenes.
The name of an orderable field in the model, typically a :class:`DateField`,
:class:`DateTimeField`, or :class:`IntegerField`. This specifies the default
- field to use in your model :class:`Manager`'s :class:`~QuerySet.latest`
- method.
+ field to use in your model :class:`Manager`'s
+ :meth:`~django.db.models.query.QuerySet.latest` method.
Example::
get_latest_by = "order_date"
- See the docs for :meth:`~django.db.models.query.QuerySet.latest` for more.
+ See the :meth:`~django.db.models.query.QuerySet.latest` docs for more.
``managed``
-----------
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index 40fa2d2b2f..a19d022c58 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1637,7 +1637,7 @@ Finally, realize that ``update()`` does an update at the SQL level and, thus,
does not call any ``save()`` methods on your models, nor does it emit the
:attr:`~django.db.models.signals.pre_save` or
:attr:`~django.db.models.signals.post_save` signals (which are a consequence of
-calling :meth:`Model.save() <~django.db.models.Model.save()>`). If you want to
+calling :meth:`Model.save() <django.db.models.Model.save>`). If you want to
update a bunch of records for a model that has a custom
:meth:`~django.db.models.Model.save()` method, loop over them and call
:meth:`~django.db.models.Model.save()`, like this::
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 5ecc221039..7cb33a038d 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -159,7 +159,7 @@ The cache backend to use. The built-in cache backends are:
* ``'django.core.cache.backends.memcached.PyLibMCCache'``
You can use a cache backend that doesn't ship with Django by setting
-:setting:`BACKEND <CACHE-BACKEND>` to a fully-qualified path of a cache
+:setting:`BACKEND <CACHES-BACKEND>` to a fully-qualified path of a cache
backend class (i.e. ``mypackage.backends.whatever.WhateverCache``).
Writing a whole new cache backend from scratch is left as an exercise
to the reader; see the other backends for examples.
@@ -830,7 +830,7 @@ DEFAULT_EXCEPTION_REPORTER_FILTER
Default: :class:`django.views.debug.SafeExceptionReporterFilter`
Default exception reporter filter class to be used if none has been assigned to
-the :class:`HttpRequest` instance yet.
+the :class:`~django.http.HttpRequest` instance yet.
See :ref:`Filtering error reports<filtering-error-reports>`.
.. setting:: DEFAULT_FILE_STORAGE
@@ -1070,6 +1070,8 @@ Note that these paths should use Unix-style forward slashes, even on Windows.
See :ref:`initial-data-via-fixtures` and :ref:`topics-testing-fixtures`.
+.. setting:: FORCE_SCRIPT_NAME
+
FORCE_SCRIPT_NAME
------------------
@@ -1498,7 +1500,7 @@ PROFANITIES_LIST
Default: ``()`` (Empty tuple)
A tuple of profanities, as strings, that will be forbidden in comments when
-:setting:`COMMENTS_ALLOW_PROFANITIES` is ``False``.
+``COMMENTS_ALLOW_PROFANITIES`` is ``False``.
.. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS
diff --git a/docs/releases/1.1-alpha-1.txt b/docs/releases/1.1-alpha-1.txt
index c8ac56cf48..b20b4103b8 100644
--- a/docs/releases/1.1-alpha-1.txt
+++ b/docs/releases/1.1-alpha-1.txt
@@ -32,11 +32,13 @@ Aggregate support
It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``,
``MIN()``, etc.) from within Django's ORM. You can choose to either return the
results of the aggregate directly, or else annotate the objects in a
-:class:`QuerySet` with the results of the aggregate query.
+:class:`~django.db.models.query.QuerySet` with the results of the aggregate
+query.
-This feature is available as new :meth:`QuerySet.aggregate()`` and
-:meth:`QuerySet.annotate()`` methods, and is covered in detail in :doc:`the ORM
-aggregation documentation </topics/db/aggregation>`
+This feature is available as new
+:meth:`~django.db.models.query.QuerySet.aggregate` and
+:meth:`~django.db.models.query.QuerySet.annotate` methods, and is covered in
+detail in :doc:`the ORM aggregation documentation </topics/db/aggregation>`.
Query expressions
~~~~~~~~~~~~~~~~~
diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt
index 84af7fc1d9..595f59a52a 100644
--- a/docs/releases/1.1.txt
+++ b/docs/releases/1.1.txt
@@ -198,11 +198,13 @@ Aggregate support
It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``,
``MIN()``, etc.) from within Django's ORM. You can choose to either return the
results of the aggregate directly, or else annotate the objects in a
-:class:`QuerySet` with the results of the aggregate query.
+:class:`~django.db.models.query.QuerySet` with the results of the aggregate
+query.
-This feature is available as new :meth:`QuerySet.aggregate()`` and
-:meth:`QuerySet.annotate()`` methods, and is covered in detail in :doc:`the ORM
-aggregation documentation </topics/db/aggregation>`.
+This feature is available as new
+:meth:`~django.db.models.query.QuerySet.aggregate` and
+:meth:`~django.db.models.query.QuerySet.annotate` methods, and is covered in
+detail in :doc:`the ORM aggregation documentation </topics/db/aggregation>`.
Query expressions
~~~~~~~~~~~~~~~~~
diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt
index 2f5124e52b..dac48a4363 100644
--- a/docs/releases/1.3-alpha-1.txt
+++ b/docs/releases/1.3-alpha-1.txt
@@ -61,15 +61,14 @@ Django 1.3 ships with a new contrib app ``'django.contrib.staticfiles'``
to help developers handle the static media files (images, CSS, Javascript,
etc.) that are needed to render a complete web page.
-In previous versions of Django, it was common to place static assets in
-:setting:`MEDIA_ROOT` along with user-uploaded files, and serve them both at
-:setting:`MEDIA_URL`. Part of the purpose of introducing the ``staticfiles``
-app is to make it easier to keep static files separate from user-uploaded
-files. For this reason, you will probably want to make your
-:setting:`MEDIA_ROOT` and :setting:`MEDIA_URL` different from your
-:setting:`STATICFILES_ROOT` and :setting:`STATICFILES_URL`. You will need to
-arrange for serving of files in :setting:`MEDIA_ROOT` yourself;
-``staticfiles`` does not deal with user-uploaded media at all.
+In previous versions of Django, it was common to place static assets
+in :setting:`MEDIA_ROOT` along with user-uploaded files, and serve
+them both at :setting:`MEDIA_URL`. Part of the purpose of introducing
+the ``staticfiles`` app is to make it easier to keep static files
+separate from user-uploaded files. Static assets should now go in
+``static/`` subdirectories of your apps or in other static assets
+directories listed in :setting:`STATICFILES_DIRS`, and will be served
+at :setting:`STATIC_URL`.
See the :doc:`reference documentation of the app </ref/contrib/staticfiles>`
for more details or learn how to :doc:`manage static files
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index 01532cc04c..9ff42accc5 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -37,8 +37,8 @@ Other notable new features in Django 1.4 include:
the ability to `bulk insert <#model-objects-bulk-create-in-the-orm>`_
large datasets for improved performance, and
`QuerySet.prefetch_related`_, a method to batch-load related objects
- in areas where :meth:`~django.db.models.QuerySet.select_related` doesn't
- work.
+ in areas where :meth:`~django.db.models.query.QuerySet.select_related`
+ doesn't work.
* Some nice security additions, including `improved password hashing`_
(featuring PBKDF2_ and bcrypt_ support), new `tools for cryptographic