mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-03 18:38:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fixed #19516 - Fixed remaining broken links.

Browse source 
Added -n to sphinx builds to catch issues going forward.
This commit is contained in:
Tim Graham 2013-01-01 08:12:42 -05:00
parent 3f890f8dc7
commit 9b5f64cc6e
83 changed files with 727 additions and 611 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/ref/contrib/admin/admindocs.txt
View file

@ -24,7 +24,7 @@ the following:
* Add :mod:`django.contrib.admindocs` to your :setting:`INSTALLED_APPS`.
* Add ``(r'^admin/doc/', include('django.contrib.admindocs.urls'))`` to
your :data:`urlpatterns`. Make sure it's included *before* the
your ``urlpatterns``. Make sure it's included *before* the
``r'^admin/'`` entry, so that requests to ``/admin/doc/`` don't get
handled by the latter entry.
* Install the docutils Python module (http://docutils.sf.net/).

26
docs/ref/contrib/admin/index.txt
View file

@ -170,7 +170,7 @@ subclass::
``fields`` option (for more complex layout needs see the
:attr:`~ModelAdmin.fieldsets` option described in the next section). For
example, you could define a simpler version of the admin form for the
``django.contrib.flatpages.FlatPage`` model as follows::
:class:`django.contrib.flatpages.models.FlatPage` model as follows::
class FlatPageAdmin(admin.ModelAdmin):
fields = ('url', 'title', 'content')
@ -212,8 +212,8 @@ subclass::
a dictionary of information about the fieldset, including a list of fields
to be displayed in it.
A full example, taken from the :class:`django.contrib.flatpages.FlatPage`
model::
A full example, taken from the
:class:`django.contrib.flatpages.models.FlatPage` model::
class FlatPageAdmin(admin.ModelAdmin):
fieldsets = (
@ -357,7 +357,7 @@ subclass::
Note that the key in the dictionary is the actual field class, *not* a
string. The value is another dictionary; these arguments will be passed to
:meth:`~django.forms.Field.__init__`. See :doc:`/ref/forms/api` for
the form field's ``__init__()`` method. See :doc:`/ref/forms/api` for
details.
.. warning::
@ -584,7 +584,7 @@ subclass::
class PersonAdmin(UserAdmin):
list_filter = ('company__name',)
* a class inheriting from :mod:`django.contrib.admin.SimpleListFilter`,
* a class inheriting from ``django.contrib.admin.SimpleListFilter``,
which you need to provide the ``title`` and ``parameter_name``
attributes to and override the ``lookups`` and ``queryset`` methods,
e.g.::
@ -671,7 +671,7 @@ subclass::
* a tuple, where the first element is a field name and the second
element is a class inheriting from
:mod:`django.contrib.admin.FieldListFilter`, for example::
``django.contrib.admin.FieldListFilter``, for example::
from django.contrib.admin import BooleanFieldListFilter
@ -943,10 +943,9 @@ templates used by the :class:`ModelAdmin` views:
.. attribute:: ModelAdmin.delete_selected_confirmation_template
Path to a custom template, used by the :meth:`delete_selected`
action method for displaying a confirmation page when deleting one
or more objects. See the :doc:`actions
documentation</ref/contrib/admin/actions>`.
Path to a custom template, used by the ``delete_selected`` action method
for displaying a confirmation page when deleting one or more objects. See
the :doc:`actions documentation</ref/contrib/admin/actions>`.
.. attribute:: ModelAdmin.object_history_template
@ -1108,9 +1107,8 @@ templates used by the :class:`ModelAdmin` views:
Since this is usually not what you want, Django provides a convenience
wrapper to check permissions and mark the view as non-cacheable. This
wrapper is :meth:`AdminSite.admin_view` (i.e.
``self.admin_site.admin_view`` inside a ``ModelAdmin`` instance); use it
like so::
wrapper is ``AdminSite.admin_view()`` (i.e. ``self.admin_site.admin_view``
inside a ``ModelAdmin`` instance); use it like so::
class MyModelAdmin(admin.ModelAdmin):
def get_urls(self):
@ -1130,7 +1128,7 @@ templates used by the :class:`ModelAdmin` views:
If the page is cacheable, but you still want the permission check to be
performed, you can pass a ``cacheable=True`` argument to
:meth:`AdminSite.admin_view`::
``AdminSite.admin_view()``::
(r'^my_view/$', self.admin_site.admin_view(self.my_view, cacheable=True))

26
docs/ref/contrib/comments/custom.txt
View file

@ -66,15 +66,17 @@ In the ``models.py`` we'll define a ``CommentWithTitle`` model::
class CommentWithTitle(Comment):
title = models.CharField(max_length=300)
Most custom comment models will subclass the :class:`Comment` model. However,
Most custom comment models will subclass the
:class:`~django.contrib.comments.models.Comment` model. However,
if you want to substantially remove or change the fields available in the
:class:`Comment` model, but don't want to rewrite the templates, you could
try subclassing from :class:`BaseCommentAbstractModel`.
:class:`~django.contrib.comments.models.Comment` model, but don't want to
rewrite the templates, you could try subclassing from
``BaseCommentAbstractModel``.
Next, we'll define a custom comment form in ``forms.py``. This is a little more
tricky: we have to both create a form and override
:meth:`CommentForm.get_comment_model` and
:meth:`CommentForm.get_comment_create_data` to return deal with our custom title
``CommentForm.get_comment_model()`` and
``CommentForm.get_comment_create_data()`` to return deal with our custom title
field::
from django import forms
@ -139,7 +141,7 @@ however.
Return the :class:`~django.db.models.Model` class to use for comments. This
model should inherit from
:class:`django.contrib.comments.models.BaseCommentAbstractModel`, which
``django.contrib.comments.models.BaseCommentAbstractModel``, which
defines necessary core fields.
The default implementation returns
@ -170,33 +172,33 @@ however.
attribute when rendering your comment form.
The default implementation returns a reverse-resolved URL pointing
to the :func:`post_comment` view.
to the ``post_comment()`` view.
.. note::
If you provide a custom comment model and/or form, but you
want to use the default :func:`post_comment` view, you will
want to use the default ``post_comment()`` view, you will
need to be aware that it requires the model and form to have
certain additional attributes and methods: see the
:func:`post_comment` view documentation for details.
``django.contrib.comments.views.post_comment()`` view for details.
.. function:: get_flag_url()
Return the URL for the "flag this comment" view.
The default implementation returns a reverse-resolved URL pointing
to the :func:`django.contrib.comments.views.moderation.flag` view.
to the ``django.contrib.comments.views.moderation.flag()`` view.
.. function:: get_delete_url()
Return the URL for the "delete this comment" view.
The default implementation returns a reverse-resolved URL pointing
to the :func:`django.contrib.comments.views.moderation.delete` view.
to the ``django.contrib.comments.views.moderation.delete()`` view.
.. function:: get_approve_url()
Return the URL for the "approve this comment from moderation" view.
The default implementation returns a reverse-resolved URL pointing
to the :func:`django.contrib.comments.views.moderation.approve` view.
to the ``django.contrib.comments.views.moderation.approve()`` view.

4
docs/ref/contrib/comments/example.txt
View file

@ -136,7 +136,7 @@ Feeds
=====
Suppose you want to export a :doc:`feed </ref/contrib/syndication>` of the
latest comments, you can use the built-in :class:`LatestCommentFeed`. Just
latest comments, you can use the built-in ``LatestCommentFeed``. Just
enable it in your project's ``urls.py``:
.. code-block:: python
@ -166,7 +166,7 @@ features (all of which or only certain can be enabled):
* Close comments after a particular (user-defined) number of days.
* Email new comments to the site-staff.
To enable comment moderation, we subclass the :class:`CommentModerator` and
To enable comment moderation, we subclass the ``CommentModerator`` and
register it with the moderation features we want. Let's suppose we want to
close comments after 7 days of posting and also send out an email to the
site staff. In ``blog/models.py``, we register a comment moderator in the

9
docs/ref/contrib/comments/moderation.txt
View file

@ -185,15 +185,14 @@ via two methods:
be moderated using the options defined in the
``CommentModerator`` subclass. If any of the models are
already registered for moderation, the exception
:exc:`AlreadyModerated` will be raised.
``AlreadyModerated`` will be raised.
.. function:: moderator.unregister(model_or_iterable)
Takes one argument: a model class or list of model classes,
and removes the model or models from the set of models which
are being moderated. If any of the models are not currently
being moderated, the exception
:exc:`NotModerated` will be raised.
being moderated, the exception ``NotModerated`` will be raised.
Customizing the moderation system
@ -207,8 +206,8 @@ models with an instance of the subclass.
.. class:: Moderator
In addition to the :meth:`Moderator.register` and
:meth:`Moderator.unregister` methods detailed above, the following methods
In addition to the :func:`moderator.register` and
:func:`moderator.unregister` methods detailed above, the following methods
on :class:`Moderator` can be overridden to achieve customized behavior:
.. method:: connect

4
docs/ref/contrib/comments/signals.txt
View file

@ -81,8 +81,8 @@ Arguments sent with this signal:
:meth:`~django.db.models.Model.save` again.
``flag``
The :class:`~django.contrib.comments.models.CommentFlag` that's been
attached to the comment.
The ``django.contrib.comments.models.CommentFlag`` that's been attached to
the comment.
``created``
``True`` if this is a new flag; ``False`` if it's a duplicate flag.

8
docs/ref/contrib/contenttypes.txt
View file

@ -453,7 +453,7 @@ Generic relations in forms and admin
------------------------------------
The :mod:`django.contrib.contenttypes.generic` module provides
:class:`~django.contrib.contenttypes.generic.BaseGenericInlineFormSet`,
``BaseGenericInlineFormSet``,
:class:`~django.contrib.contenttypes.generic.GenericTabularInline`
and :class:`~django.contrib.contenttypes.generic.GenericStackedInline`
(the last two are subclasses of
@ -480,3 +480,9 @@ information.
The name of the integer field that represents the ID of the related
object. Defaults to ``object_id``.
.. class:: GenericTabularInline
.. class:: GenericStackedInline
Subclasses of :class:`GenericInlineModelAdmin` with stacked and tabular
layouts, respectively.

4
docs/ref/contrib/flatpages.txt
View file

@ -186,7 +186,7 @@ Via the Python API
If you add or modify flatpages via your own code, you will likely want to
check for duplicate flatpage URLs within the same site. The flatpage form
used in the admin performs this validation check, and can be imported from
:class:`django.contrib.flatpages.forms.FlatPageForm` and used in your own
``django.contrib.flatpages.forms.FlatPageForm`` and used in your own
views.
Flatpage templates
@ -256,7 +256,7 @@ Displaying ``registration_required`` flatpages
By default, the :ttag:`get_flatpages` templatetag will only show
flatpages that are marked ``registration_required = False``. If you
want to display registration-protected flatpages, you need to specify
an authenticated user using a``for`` clause.
an authenticated user using a ``for`` clause.
For example:

16
docs/ref/contrib/formtools/form-preview.txt
View file

@ -25,9 +25,8 @@ application takes care of the following workflow:
a. If it's valid, displays a preview page.
b. If it's not valid, redisplays the form with error messages.
3. When the "confirmation" form is submitted from the preview page, calls
a hook that you define -- a
:meth:`~django.contrib.formtools.preview.FormPreview.done()` method that gets
passed the valid data.
a hook that you define -- a ``done()`` method that gets passed the valid
data.
The framework enforces the required preview by passing a shared-secret hash to
the preview page via hidden form fields. If somebody tweaks the form parameters
@ -51,8 +50,7 @@ How to use ``FormPreview``
directory to your :setting:`TEMPLATE_DIRS` setting.
2. Create a :class:`~django.contrib.formtools.preview.FormPreview` subclass that
overrides the :meth:`~django.contrib.formtools.preview.FormPreview.done()`
method::
overrides the ``done()`` method::
from django.contrib.formtools.preview import FormPreview
from myapp.models import SomeModel
@ -92,13 +90,15 @@ How to use ``FormPreview``
A :class:`~django.contrib.formtools.preview.FormPreview` class is a simple Python class
that represents the preview workflow.
:class:`~django.contrib.formtools.preview.FormPreview` classes must subclass
``django.contrib.formtools.preview.FormPreview`` and override the
:meth:`~django.contrib.formtools.preview.FormPreview.done()` method. They can live
anywhere in your codebase.
``django.contrib.formtools.preview.FormPreview`` and override the ``done()``
method. They can live anywhere in your codebase.
``FormPreview`` templates
=========================
.. attribute:: FormPreview.form_template
.. attribute:: FormPreview.preview_template
By default, the form is rendered via the template :file:`formtools/form.html`,
and the preview page is rendered via the template :file:`formtools/preview.html`.
These values can be overridden for a particular form preview by setting

32
docs/ref/contrib/formtools/form-wizard.txt
View file

@ -54,7 +54,8 @@ you just have to do these things:
4. Add ``django.contrib.formtools`` to your
:setting:`INSTALLED_APPS` list in your settings file.
5. Point your URLconf at your :class:`WizardView` :meth:`~WizardView.as_view` method.
5. Point your URLconf at your :class:`WizardView` :meth:`~WizardView.as_view`
method.
Defining ``Form`` classes
-------------------------
@ -89,6 +90,9 @@ the message itself. Here's what the :file:`forms.py` might look like::
Creating a ``WizardView`` subclass
----------------------------------
.. class:: SessionWizardView
.. class:: CookieWizardView
The next step is to create a
:class:`django.contrib.formtools.wizard.views.WizardView` subclass. You can
also use the :class:`SessionWizardView` or :class:`CookieWizardView` classes
@ -225,9 +229,11 @@ Here's a full example template:
Hooking the wizard into a URLconf
---------------------------------
.. method:: WizardView.as_view
Finally, we need to specify which forms to use in the wizard, and then
deploy the new :class:`WizardView` object at a URL in the ``urls.py``. The
wizard's :meth:`as_view` method takes a list of your
wizard's ``as_view()`` method takes a list of your
:class:`~django.forms.Form` classes as an argument during instantiation::
from django.conf.urls import patterns
@ -346,9 +352,9 @@ Advanced ``WizardView`` methods
used as the form for step ``step``.
Returns an :class:`~django.db.models.Model` object which will be passed as
the :attr:`~django.forms.ModelForm.instance` argument when instantiating the
ModelForm for step ``step``. If no instance object was provided while
initializing the form wizard, ``None`` will be returned.
the ``instance`` argument when instantiating the ``ModelForm`` for step
``step``. If no instance object was provided while initializing the form
wizard, ``None`` will be returned.
The default implementation::
@ -514,10 +520,10 @@ Providing initial data for the forms
.. attribute:: WizardView.initial_dict
Initial data for a wizard's :class:`~django.forms.Form` objects can be
provided using the optional :attr:`~Wizard.initial_dict` keyword argument.
This argument should be a dictionary mapping the steps to dictionaries
containing the initial data for each step. The dictionary of initial data
will be passed along to the constructor of the step's
provided using the optional :attr:`~WizardView.initial_dict` keyword
argument. This argument should be a dictionary mapping the steps to
dictionaries containing the initial data for each step. The dictionary of
initial data will be passed along to the constructor of the step's
:class:`~django.forms.Form`::
>>> from myapp.forms import ContactForm1, ContactForm2
@ -542,11 +548,13 @@ Providing initial data for the forms
Handling files
==============
.. attribute:: WizardView.file_storage
To handle :class:`~django.forms.FileField` within any step form of the wizard,
you have to add a :attr:`file_storage` to your :class:`WizardView` subclass.
you have to add a ``file_storage`` to your :class:`WizardView` subclass.
This storage will temporarily store the uploaded files for the wizard. The
:attr:`file_storage` attribute should be a
``file_storage`` attribute should be a
:class:`~django.core.files.storage.Storage` subclass.
Django provides a built-in storage class (see :ref:`the built-in filesystem
@ -646,6 +654,8 @@ Usage of ``NamedUrlWizardView``
===============================
.. class:: NamedUrlWizardView
.. class:: NamedUrlSessionWizardView
.. class:: NamedUrlCookieWizardView
There is a :class:`WizardView` subclass which adds named-urls support to the
wizard. By doing this, you can have single urls for every step. You can also

2
docs/ref/contrib/formtools/index.txt
View file

@ -1,6 +1,8 @@
django.contrib.formtools
========================
.. module:: django.contrib.formtools
A set of high-level abstractions for Django forms (:mod:`django.forms`).
.. toctree::

17
docs/ref/contrib/gis/db-api.txt
View file

@ -4,20 +4,23 @@
GeoDjango Database API
======================
.. module:: django.contrib.gis.db.models
:synopsis: GeoDjango's database API.
.. _spatial-backends:
Spatial Backends
================
.. module:: django.contrib.gis.db.backends
:synopsis: GeoDjango's spatial database backends.
GeoDjango currently provides the following spatial database backends:
* :mod:`django.contrib.gis.db.backends.postgis`
* :mod:`django.contrib.gis.db.backends.mysql`
* :mod:`django.contrib.gis.db.backends.oracle`
* :mod:`django.contrib.gis.db.backends.spatialite`
* ``django.contrib.gis.db.backends.postgis``
* ``django.contrib.gis.db.backends.mysql``
* ``django.contrib.gis.db.backends.oracle``
* ``django.contrib.gis.db.backends.spatialite``
.. module:: django.contrib.gis.db.models
:synopsis: GeoDjango's database API.
.. _mysql-spatial-limitations:

10
docs/ref/contrib/gis/feeds.txt
View file

@ -27,7 +27,7 @@ API Reference
.. class:: Feed
In addition to methods provided by
the :class:`django.contrib.syndication.feeds.Feed`
the :class:`django.contrib.syndication.views.Feed`
base class, GeoDjango's ``Feed`` class provides
the following overrides. Note that these overrides may be done in multiple ways::
@ -71,11 +71,11 @@ API Reference
can be a ``GEOSGeometry`` instance, or a tuple that represents a
point coordinate or bounding box. For example::
class ZipcodeFeed(Feed):
class ZipcodeFeed(Feed):
def item_geometry(self, obj):
# Returns the polygon.
return obj.poly
def item_geometry(self, obj):
# Returns the polygon.
return obj.poly
``SyndicationFeed`` Subclasses
------------------------------

4
docs/ref/contrib/gis/geoquerysets.txt
View file

@ -683,7 +683,7 @@ Keyword Argument Description
a method name clashes with an existing
``GeoQuerySet`` method -- if you wanted to use the
``area()`` method on model with a ``PolygonField``
named ``area``, for example.
named ``area``, for example.
===================== =====================================================
Measurement
@ -1043,7 +1043,7 @@ Keyword Argument Description
===================== =====================================================
``relative`` If set to ``True``, the path data will be implemented
in terms of relative moves. Defaults to ``False``,
meaning that absolute moves are used instead.
meaning that absolute moves are used instead.
``precision`` This keyword may be used to specify the number of
significant digits for the coordinates in the SVG

14
docs/ref/contrib/gis/geos.txt
View file

@ -142,10 +142,9 @@ Geometry Objects
.. class:: GEOSGeometry(geo_input[, srid=None])
:param geo_input: Geometry input value
:type geo_input: string or buffer
:param geo_input: Geometry input value (string or buffer)
:param srid: spatial reference identifier
:type srid: integer
:type srid: int
This is the base class for all GEOS geometry objects. It initializes on the
given ``geo_input`` argument, and then assumes the proper geometry subclass
@ -800,7 +799,7 @@ Example::
:param string: string that contains spatial data
:type string: string
:param srid: spatial reference identifier
:type srid: integer
:type srid: int
:rtype: a :class:`GEOSGeometry` corresponding to the spatial data in the string
Example::
@ -966,3 +965,10 @@ location (e.g., ``/home/bob/lib/libgeos_c.so``).
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``.
Exceptions
==========
.. exception:: GEOSException
The base GEOS exception, indicates a GEOS-related error.

2
docs/ref/contrib/gis/install/index.txt
View file

@ -530,6 +530,6 @@ Finally, :ref:`install Django <installing-official-release>` on your system.
.. rubric:: Footnotes
.. [#] GeoDjango uses the :func:`~ctypes.util.find_library` routine from
:mod:`ctypes.util` to locate shared libraries.
``ctypes.util`` to locate shared libraries.
.. [#] The ``psycopg2`` Windows installers are packaged and maintained by
`Jason Erickson <http://www.stickpeople.com/projects/python/win-psycopg/>`_.

14
docs/ref/contrib/gis/tutorial.txt
View file

@ -226,7 +226,7 @@ model to represent this data::
class WorldBorder(models.Model):
# Regular Django fields corresponding to the attributes in the
# world borders shapefile.
# world borders shapefile.
name = models.CharField(max_length=50)
area = models.IntegerField()
pop2005 = models.IntegerField('Population 2005')
@ -236,13 +236,13 @@ model to represent this data::
un = models.IntegerField('United Nations Code')
region = models.IntegerField('Region Code')
subregion = models.IntegerField('Sub-Region Code')
lon = models.FloatField()
lat = models.FloatField()
lon = models.FloatField()
lat = models.FloatField()
# GeoDjango-specific: a geometry field (MultiPolygonField), and
# GeoDjango-specific: a geometry field (MultiPolygonField), and
# overriding the default manager with a GeoManager instance.
mpoly = models.MultiPolygonField()
objects = models.GeoManager()
mpoly = models.MultiPolygonField()
objects = models.GeoManager()
# Returns the string representation of the model.
def __unicode__(self):
@ -250,7 +250,7 @@ model to represent this data::
Please note two important things:
1. The ``models`` module is imported from :mod:`django.contrib.gis.db`.
1. The ``models`` module is imported from ``django.contrib.gis.db``.
2. You must override the model's default manager with
:class:`~django.contrib.gis.db.models.GeoManager` to perform spatial queries.

29
docs/ref/contrib/sitemaps.txt
View file

@ -49,6 +49,8 @@ loader can find the default templates.)
Initialization
==============
.. function:: views.sitemap(request, sitemaps, section=None, template_name='sitemap.xml', mimetype='application/xml')
To activate sitemap generation on your Django site, add this line to your
:doc:`URLconf </topics/http/urls>`::
@ -240,9 +242,9 @@ The sitemap framework provides a couple convenience classes for common cases:
The :class:`django.contrib.sitemaps.GenericSitemap` class allows you to
create a sitemap by passing it a dictionary which has to contain at least
a :data:`queryset` entry. This queryset will be used to generate the items
of the sitemap. It may also have a :data:`date_field` entry that
specifies a date field for objects retrieved from the :data:`queryset`.
a ``queryset`` entry. This queryset will be used to generate the items
of the sitemap. It may also have a ``date_field`` entry that
specifies a date field for objects retrieved from the ``queryset``.
This will be used for the :attr:`~Sitemap.lastmod` attribute in the
generated sitemap. You may also pass :attr:`~Sitemap.priority` and
:attr:`~Sitemap.changefreq` keyword arguments to the
@ -281,14 +283,16 @@ Here's an example of a :doc:`URLconf </topics/http/urls>` using both::
Creating a sitemap index
========================
.. function:: views.index(request, sitemaps, template_name='sitemap_index.xml', mimetype='application/xml', sitemap_url_name='django.contrib.sitemaps.views.sitemap')
The sitemap framework also has the ability to create a sitemap index that
references individual sitemap files, one per each section defined in your
:data:`sitemaps` dictionary. The only differences in usage are:
``sitemaps`` dictionary. The only differences in usage are:
* You use two views in your URLconf: :func:`django.contrib.sitemaps.views.index`
and :func:`django.contrib.sitemaps.views.sitemap`.
* The :func:`django.contrib.sitemaps.views.sitemap` view should take a
:data:`section` keyword argument.
``section`` keyword argument.
Here's what the relevant URLconf lines would look like for the example above::
@ -299,7 +303,7 @@ Here's what the relevant URLconf lines would look like for the example above::
This will automatically generate a :file:`sitemap.xml` file that references
both :file:`sitemap-flatpages.xml` and :file:`sitemap-blog.xml`. The
:class:`~django.contrib.sitemaps.Sitemap` classes and the :data:`sitemaps`
:class:`~django.contrib.sitemaps.Sitemap` classes and the ``sitemaps``
dict don't change at all.
You should create an index file if one of your sitemaps has more than 50,000
@ -350,19 +354,20 @@ rendering. For more details, see the :doc:`TemplateResponse documentation
Context variables
------------------
When customizing the templates for the :func:`~django.contrib.sitemaps.views.index`
and :func:`~django.contrib.sitemaps.views.sitemaps` views, you can rely on the
When customizing the templates for the
:func:`~django.contrib.sitemaps.views.index` and
:func:`~django.contrib.sitemaps.views.sitemap` views, you can rely on the
following context variables.
Index
-----
The variable :data:`sitemaps` is a list of absolute URLs to each of the sitemaps.
The variable ``sitemaps`` is a list of absolute URLs to each of the sitemaps.
Sitemap
-------
The variable :data:`urlset` is a list of URLs that should appear in the
The variable ``urlset`` is a list of URLs that should appear in the
sitemap. Each URL exposes attributes as defined in the
:class:`~django.contrib.sitemaps.Sitemap` class:
@ -411,14 +416,14 @@ that: :func:`django.contrib.sitemaps.ping_google()`.
.. function:: ping_google
:func:`ping_google` takes an optional argument, :data:`sitemap_url`,
:func:`ping_google` takes an optional argument, ``sitemap_url``,
which should be the absolute path to your site's sitemap (e.g.,
:file:`'/sitemap.xml'`). If this argument isn't provided,
:func:`ping_google` will attempt to figure out your
sitemap by performing a reverse looking in your URLconf.
:func:`ping_google` raises the exception
:exc:`django.contrib.sitemaps.SitemapNotFound` if it cannot determine your
``django.contrib.sitemaps.SitemapNotFound`` if it cannot determine your
sitemap URL.
.. admonition:: Register with Google first!

10
docs/ref/contrib/staticfiles.txt
View file

@ -33,7 +33,7 @@ STATICFILES_DIRS
Default: ``[]``
This setting defines the additional locations the staticfiles app will traverse
if the :class:`FileSystemFinder` finder is enabled, e.g. if you use the
if the ``FileSystemFinder`` finder is enabled, e.g. if you use the
:djadmin:`collectstatic` or :djadmin:`findstatic` management command or use the
static file serving view.
@ -101,19 +101,19 @@ The list of finder backends that know how to find static files in
various locations.
The default will find files stored in the :setting:`STATICFILES_DIRS` setting
(using :class:`django.contrib.staticfiles.finders.FileSystemFinder`) and in a
(using ``django.contrib.staticfiles.finders.FileSystemFinder``) and in a
``static`` subdirectory of each app (using
:class:`django.contrib.staticfiles.finders.AppDirectoriesFinder`)
``django.contrib.staticfiles.finders.AppDirectoriesFinder``)
One finder is disabled by default:
:class:`django.contrib.staticfiles.finders.DefaultStorageFinder`. If added to
``django.contrib.staticfiles.finders.DefaultStorageFinder``. If added to
your :setting:`STATICFILES_FINDERS` setting, it will look for static files in
the default file storage as defined by the :setting:`DEFAULT_FILE_STORAGE`
setting.
.. note::
When using the :class:`AppDirectoriesFinder` finder, make sure your apps
When using the ``AppDirectoriesFinder`` finder, make sure your apps
can be found by staticfiles. Simply add the app to the
:setting:`INSTALLED_APPS` setting of your site.

2
docs/ref/contrib/syndication.txt
View file

@ -334,7 +334,7 @@ And the accompanying URLconf::
Feed class reference
--------------------
.. class:: django.contrib.syndication.views.Feed
.. class:: views.Feed
This example illustrates all possible attributes and methods for a
:class:`~django.contrib.syndication.views.Feed` class::