Permalink
Browse files

[1.5.x] Fixed #19516 - Fixed remaining broken links.

Added -n to sphinx builds to catch issues going forward.

Backport of 9b5f64c from master.
  • Loading branch information...
1 parent 61c8615 commit be1e006c581cc45ed48ae0b423e7a0a996d2199b @timgraham timgraham committed Jan 1, 2013
Showing with 723 additions and 606 deletions.
  1. +1 −1 docs/Makefile
  2. +5 −4 docs/faq/usage.txt
  3. +9 −9 docs/howto/custom-model-fields.txt
  4. +6 −0 docs/howto/custom-template-tags.txt
  5. +3 −3 docs/internals/contributing/writing-code/coding-style.txt
  6. +9 −11 docs/internals/deprecation.txt
  7. +2 −2 docs/intro/tutorial01.txt
  8. +4 −4 docs/intro/tutorial04.txt
  9. +1 −1 docs/make.bat
  10. +18 −16 docs/ref/class-based-views/base.txt
  11. +39 −39 docs/ref/class-based-views/flattened-index.txt
  12. +1 −1 docs/ref/class-based-views/generic-date-based.txt
  13. +20 −20 docs/ref/class-based-views/generic-display.txt
  14. +5 −5 docs/ref/class-based-views/generic-editing.txt
  15. +5 −4 docs/ref/class-based-views/mixins-date-based.txt
  16. +26 −17 docs/ref/class-based-views/mixins-editing.txt
  17. +5 −6 docs/ref/class-based-views/mixins-multiple-object.txt
  18. +5 −7 docs/ref/class-based-views/mixins-simple.txt
  19. +20 −21 docs/ref/class-based-views/mixins-single-object.txt
  20. +4 −4 docs/ref/clickjacking.txt
  21. +1 −1 docs/ref/contrib/admin/admindocs.txt
  22. +12 −14 docs/ref/contrib/admin/index.txt
  23. +14 −12 docs/ref/contrib/comments/custom.txt
  24. +2 −2 docs/ref/contrib/comments/example.txt
  25. +4 −5 docs/ref/contrib/comments/moderation.txt
  26. +2 −2 docs/ref/contrib/comments/signals.txt
  27. +7 −1 docs/ref/contrib/contenttypes.txt
  28. +2 −2 docs/ref/contrib/databrowse.txt
  29. +2 −2 docs/ref/contrib/flatpages.txt
  30. +8 −8 docs/ref/contrib/formtools/form-preview.txt
  31. +21 −11 docs/ref/contrib/formtools/form-wizard.txt
  32. +2 −0 docs/ref/contrib/formtools/index.txt
  33. +10 −7 docs/ref/contrib/gis/db-api.txt
  34. +5 −5 docs/ref/contrib/gis/feeds.txt
  35. +2 −2 docs/ref/contrib/gis/geoquerysets.txt
  36. +10 −4 docs/ref/contrib/gis/geos.txt
  37. +1 −1 docs/ref/contrib/gis/install/index.txt
  38. +7 −7 docs/ref/contrib/gis/tutorial.txt
  39. +17 −12 docs/ref/contrib/sitemaps.txt
  40. +5 −5 docs/ref/contrib/staticfiles.txt
  41. +1 −1 docs/ref/contrib/syndication.txt
  42. +2 −2 docs/ref/databases.txt
  43. +2 −0 docs/ref/django-admin.txt
  44. +15 −0 docs/ref/exceptions.txt
  45. +2 −2 docs/ref/files/file.txt
  46. +1 −1 docs/ref/files/storage.txt
  47. +21 −20 docs/ref/forms/api.txt
  48. +6 −6 docs/ref/forms/widgets.txt
  49. +2 −2 docs/ref/middleware.txt
  50. +58 −35 docs/ref/models/fields.txt
  51. +1 −1 docs/ref/models/options.txt
  52. +1 −1 docs/ref/request-response.txt
  53. +1 −1 docs/ref/settings.txt
  54. +5 −6 docs/ref/signals.txt
  55. +11 −13 docs/ref/template-response.txt
  56. +19 −3 docs/ref/templates/api.txt
  57. +1 −1 docs/ref/templates/builtins.txt
  58. +0 −2 docs/ref/urls.txt
  59. +9 −10 docs/ref/utils.txt
  60. +1 −1 docs/ref/validators.txt
  61. +1 −1 docs/releases/1.2-beta-1.txt
  62. +5 −5 docs/releases/1.2.txt
  63. +1 −1 docs/releases/1.3-alpha-1.txt
  64. +3 −3 docs/releases/1.3-beta-1.txt
  65. +2 −3 docs/releases/1.3.txt
  66. +1 −1 docs/releases/1.4-alpha-1.txt
  67. +1 −1 docs/releases/1.4-beta-1.txt
  68. +2 −2 docs/releases/1.4.txt
  69. +6 −6 docs/topics/auth/passwords.txt
  70. +5 −3 docs/topics/cache.txt
  71. +6 −6 docs/topics/class-based-views/generic-display.txt
  72. +46 −35 docs/topics/class-based-views/generic-editing.txt
  73. +100 −92 docs/topics/class-based-views/mixins.txt
  74. +2 −3 docs/topics/db/sql.txt
  75. +3 −4 docs/topics/db/transactions.txt
  76. +2 −0 docs/topics/forms/formsets.txt
  77. +2 −2 docs/topics/http/file-uploads.txt
  78. +2 −0 docs/topics/http/views.txt
  79. +2 −2 docs/topics/i18n/timezones.txt
  80. +6 −6 docs/topics/logging.txt
  81. +35 −38 docs/topics/python3.txt
  82. +3 −1 docs/topics/serialization.txt
  83. +2 −1 docs/topics/settings.txt
  84. +4 −4 docs/topics/testing/overview.txt
View
@@ -10,7 +10,7 @@ BUILDDIR = _build
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+ALLSPHINXOPTS = -n -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
View
@@ -52,10 +52,11 @@ Using a :class:`~django.db.models.FileField` or an
#. All that will be stored in your database is a path to the file
(relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
- convenience :attr:`~django.core.files.File.url` attribute provided by
- Django. For example, if your :class:`~django.db.models.ImageField` is
- called ``mug_shot``, you can get the absolute path to your image in a
- template with ``{{ object.mug_shot.url }}``.
+ convenience :attr:`~django.db.models.fields.files.FieldFile.url` attribute
+ provided by Django. For example, if your
+ :class:`~django.db.models.ImageField` is called ``mug_shot``, you can get
+ the absolute path to your image in a template with
+ ``{{ object.mug_shot.url }}``.
How do I make a variable available to all my templates?
-------------------------------------------------------
@@ -199,20 +199,20 @@ The :meth:`~django.db.models.Field.__init__` method takes the following
parameters:
* :attr:`~django.db.models.Field.verbose_name`
-* :attr:`~django.db.models.Field.name`
+* ``name``
* :attr:`~django.db.models.Field.primary_key`
-* :attr:`~django.db.models.Field.max_length`
+* :attr:`~django.db.models.CharField.max_length`
* :attr:`~django.db.models.Field.unique`
* :attr:`~django.db.models.Field.blank`
* :attr:`~django.db.models.Field.null`
* :attr:`~django.db.models.Field.db_index`
-* :attr:`~django.db.models.Field.rel`: Used for related fields (like
- :class:`ForeignKey`). For advanced use only.
+* ``rel``: Used for related fields (like :class:`ForeignKey`). For advanced
+ use only.
* :attr:`~django.db.models.Field.default`
* :attr:`~django.db.models.Field.editable`
-* :attr:`~django.db.models.Field.serialize`: If ``False``, the field will
- not be serialized when the model is passed to Django's :doc:`serializers
- </topics/serialization>`. Defaults to ``True``.
+* ``serialize``: If ``False``, the field will not be serialized when the model
+ is passed to Django's :doc:`serializers </topics/serialization>`. Defaults to
+ ``True``.
* :attr:`~django.db.models.Field.unique_for_date`
* :attr:`~django.db.models.Field.unique_for_month`
* :attr:`~django.db.models.Field.unique_for_year`
@@ -222,7 +222,7 @@ parameters:
* :attr:`~django.db.models.Field.db_tablespace`: Only for index creation, if the
backend supports :doc:`tablespaces </topics/db/tablespaces>`. You can usually
ignore this option.
-* :attr:`~django.db.models.Field.auto_created`: True if the field was
+* ``auto_created``: True if the field was
automatically created, as for the `OneToOneField` used by model
inheritance. For advanced use only.
@@ -443,7 +443,7 @@ Python object type we want to store in the model's attribute. If anything is
going wrong during value conversion, you should raise a
:exc:`~django.core.exceptions.ValidationError` exception.
-**Remember:** If your custom field needs the :meth:`to_python` method to be
+**Remember:** If your custom field needs the :meth:`.to_python` method to be
called when it is created, you should be using `The SubfieldBase metaclass`_
mentioned earlier. Otherwise :meth:`.to_python` won't be called
automatically.
@@ -114,6 +114,8 @@ your function. Example:
Registering custom filters
~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. method:: django.template.Library.filter
+
Once you've written your filter definition, you need to register it with
your ``Library`` instance, to make it available to Django's template language:
@@ -151,6 +153,8 @@ are described in :ref:`filters and auto-escaping <filters-auto-escaping>` and
Template filters that expect strings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. method:: django.template.defaultfilters.stringfilter
+
If you're writing a template filter that only expects a string as the first
argument, you should use the decorator ``stringfilter``. This will
convert an object to its string value before being passed to your function:
@@ -722,6 +726,8 @@ cannot resolve the string passed to it in the current context of the page.
Simple tags
~~~~~~~~~~~
+.. method:: django.template.Library.simple_tag
+
Many template tags take a number of arguments -- strings or template variables
-- and return a string after doing some processing based solely on
the input arguments and some external information. For example, the
@@ -177,9 +177,9 @@ That means that the ability for third parties to import the module at the top
level is incompatible with the ability to configure the settings object
manually, or makes it very difficult in some circumstances.
-Instead of the above code, a level of laziness or indirection must be used, such
-as :class:`django.utils.functional.LazyObject`,
-:func:`django.utils.functional.lazy` or ``lambda``.
+Instead of the above code, a level of laziness or indirection must be used,
+such as ``django.utils.functional.LazyObject``,
+``django.utils.functional.lazy()`` or ``lambda``.
Miscellaneous
-------------
@@ -167,9 +167,8 @@ these changes.
* ``django.core.context_processors.PermWrapper`` and
``django.core.context_processors.PermLookupDict`` will be removed in
favor of the corresponding
- :class:`django.contrib.auth.context_processors.PermWrapper` and
- :class:`django.contrib.auth.context_processors.PermLookupDict`,
- respectively.
+ ``django.contrib.auth.context_processors.PermWrapper`` and
+ ``django.contrib.auth.context_processors.PermLookupDict``, respectively.
* The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings will be
required to end with a trailing slash to ensure there is a consistent
@@ -218,10 +217,10 @@ these changes.
synonym for ``django.views.decorators.csrf.csrf_exempt``, which should
be used to replace it.
-* The :class:`~django.core.cache.backends.memcached.CacheClass` backend
+* The ``django.core.cache.backends.memcached.CacheClass`` backend
was split into two in Django 1.3 in order to introduce support for
- PyLibMC. The historical :class:`~django.core.cache.backends.memcached.CacheClass`
- will be removed in favor of :class:`~django.core.cache.backends.memcached.MemcachedCache`.
+ PyLibMC. The historical ``CacheClass`` will be removed in favor of
+ ``django.core.cache.backends.memcached.MemcachedCache``.
* The UK-prefixed objects of ``django.contrib.localflavor.uk`` will only
be accessible through their GB-prefixed names (GB is the correct
@@ -243,8 +242,8 @@ these changes.
:setting:`LOGGING` setting should include this filter explicitly if
it is desired.
-* The builtin truncation functions :func:`django.utils.text.truncate_words`
- and :func:`django.utils.text.truncate_html_words` will be removed in
+* The builtin truncation functions ``django.utils.text.truncate_words()``
+ and ``django.utils.text.truncate_html_words()`` will be removed in
favor of the ``django.utils.text.Truncator`` class.
* The :class:`~django.contrib.gis.geoip.GeoIP` class was moved to
@@ -257,9 +256,8 @@ these changes.
:data:`~django.conf.urls.handler500`, are now available through
:mod:`django.conf.urls` .
-* The functions :func:`~django.core.management.setup_environ` and
- :func:`~django.core.management.execute_manager` will be removed from
- :mod:`django.core.management`. This also means that the old (pre-1.4)
+* The functions ``setup_environ()`` and ``execute_manager()`` will be removed
+ from :mod:`django.core.management`. This also means that the old (pre-1.4)
style of :file:`manage.py` file will no longer work.
* Setting the ``is_safe`` and ``needs_autoescape`` flags as attributes of
@@ -369,8 +369,8 @@ its human-readable name.
Some :class:`~django.db.models.Field` classes have required elements.
:class:`~django.db.models.CharField`, for example, requires that you give it a
-:attr:`~django.db.models.Field.max_length`. That's used not only in the database
-schema, but in validation, as we'll soon see.
+:attr:`~django.db.models.CharField.max_length`. That's used not only in the
+database schema, but in validation, as we'll soon see.
Finally, note a relationship is defined, using
:class:`~django.db.models.ForeignKey`. That tells Django each ``Choice`` is related
@@ -234,20 +234,20 @@ two views abstract the concepts of "display a list of objects" and
* Each generic view needs to know what model it will be acting
upon. This is provided using the ``model`` parameter.
-* The :class:`~django.views.generic.list.DetailView` generic view
+* The :class:`~django.views.generic.detail.DetailView` generic view
expects the primary key value captured from the URL to be called
``"pk"``, so we've changed ``poll_id`` to ``pk`` for the generic
views.
-By default, the :class:`~django.views.generic.list.DetailView` generic
+By default, the :class:`~django.views.generic.detail.DetailView` generic
view uses a template called ``<app name>/<model name>_detail.html``.
In our case, it'll use the template ``"polls/poll_detail.html"``. The
``template_name`` argument is used to tell Django to use a specific
template name instead of the autogenerated default template name. We
also specify the ``template_name`` for the ``results`` list view --
this ensures that the results view and the detail view have a
different appearance when rendered, even though they're both a
-:class:`~django.views.generic.list.DetailView` behind the scenes.
+:class:`~django.views.generic.detail.DetailView` behind the scenes.
Similarly, the :class:`~django.views.generic.list.ListView` generic
view uses a default template called ``<app name>/<model
@@ -257,7 +257,7 @@ name>_list.html``; we use ``template_name`` to tell
In previous parts of the tutorial, the templates have been provided
with a context that contains the ``poll`` and ``latest_poll_list``
-context variables. For DetailView the ``poll`` variable is provided
+context variables. For ``DetailView`` the ``poll`` variable is provided
automatically -- since we're using a Django model (``Poll``), Django
is able to determine an appropriate name for the context variable.
However, for ListView, the automatically generated context variable is
View
@@ -6,7 +6,7 @@ if "%SPHINXBUILD%" == "" (
set SPHINXBUILD=sphinx-build
)
set BUILDDIR=_build
-set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
+set ALLSPHINXOPTS=-n -d %BUILDDIR%/doctrees %SPHINXOPTS% .
if NOT "%PAPER%" == "" (
set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%
@@ -49,9 +49,13 @@ View
**Attributes**
- .. attribute:: http_method_names = ['get', 'post', 'put', 'delete', 'head', 'options', 'trace']
+ .. attribute:: http_method_names
- The default list of HTTP method names that this view will accept.
+ The list of HTTP method names that this view will accept.
+
+ Default::
+
+ ['get', 'post', 'put', 'delete', 'head', 'options', 'trace']
**Methods**
@@ -68,12 +72,11 @@ View
The default implementation will inspect the HTTP method and attempt to
delegate to a method that matches the HTTP method; a ``GET`` will be
- delegated to :meth:`~View.get()`, a ``POST`` to :meth:`~View.post()`,
- and so on.
+ delegated to ``get()``, a ``POST`` to ``post()``, and so on.
- By default, a ``HEAD`` request will be delegated to :meth:`~View.get()`.
+ By default, a ``HEAD`` request will be delegated to ``get()``.
If you need to handle ``HEAD`` requests in a different way than ``GET``,
- you can override the :meth:`~View.head()` method. See
+ you can override the ``head()`` method. See
:ref:`supporting-other-http-methods` for an example.
The default implementation also sets ``request``, ``args`` and
@@ -111,9 +114,9 @@ TemplateView
**Method Flowchart**
- 1. :meth:`dispatch()`
- 2. :meth:`http_method_not_allowed()`
- 3. :meth:`get_context_data()`
+ 1. :meth:`~django.views.generic.base.View.dispatch()`
+ 2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
+ 3. :meth:`~django.views.generic.base.ContextMixin.get_context_data()`
**Example views.py**::
@@ -169,8 +172,8 @@ RedirectView
**Method Flowchart**
- 1. :meth:`dispatch()`
- 2. :meth:`http_method_not_allowed()`
+ 1. :meth:`~django.views.generic.base.View.dispatch()`
+ 2. :meth:`~django.views.generic.base.View.http_method_not_allowed()`
3. :meth:`get_redirect_url()`
**Example views.py**::
@@ -230,9 +233,8 @@ RedirectView
Constructs the target URL for redirection.
- The default implementation uses :attr:`~RedirectView.url` as a starting
+ The default implementation uses :attr:`url` as a starting
string, performs expansion of ``%`` parameters in that string, as well
- as the appending of query string if requested by
- :attr:`~RedirectView.query_string`. Subclasses may implement any
- behavior they wish, as long as the method returns a redirect-ready URL
- string.
+ as the appending of query string if requested by :attr:`query_string`.
+ Subclasses may implement any behavior they wish, as long as the method
+ returns a redirect-ready URL string.
Oops, something went wrong.

0 comments on commit be1e006

Please sign in to comment.