Fixed #16863 -- Corrected ReST markup to avoid errors building docs.
Although directives such as "note" and "warning" will accept content immediately following the directive, this is technically where arguments to the directive should go (see http://sphinx.pocoo.org/rest.html#directives). Putting the content there means that any lines beginning with an inline text role (e.g. ":setting:`DEBUG`") will be mis-interpreted as an option block for the directive. To avoid this error, there should always be a blank line between the directive start and the directive content. git-svn-id: http://code.djangoproject.com/svn/django/trunk@16842 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
d1d6109229
commit
00678334aa
|
@ -177,6 +177,7 @@ below), but we ensure it has a fixed length, since it only needs to hold 52
|
||||||
card values plus their suits; 104 characters in total.
|
card values plus their suits; 104 characters in total.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Many of Django's model fields accept options that they don't do anything
|
Many of Django's model fields accept options that they don't do anything
|
||||||
with. For example, you can pass both
|
with. For example, you can pass both
|
||||||
:attr:`~django.db.models.Field.editable` and
|
:attr:`~django.db.models.Field.editable` and
|
||||||
|
@ -189,8 +190,8 @@ card values plus their suits; 104 characters in total.
|
||||||
This behavior simplifies the field classes, because they don't need to
|
This behavior simplifies the field classes, because they don't need to
|
||||||
check for options that aren't necessary. They just pass all the options to
|
check for options that aren't necessary. They just pass all the options to
|
||||||
the parent class and then don't use them later on. It's up to you whether
|
the parent class and then don't use them later on. It's up to you whether
|
||||||
you want your fields to be more strict about the options they select, or
|
you want your fields to be more strict about the options they select, or to
|
||||||
to use the simpler, more permissive behavior of the current fields.
|
use the simpler, more permissive behavior of the current fields.
|
||||||
|
|
||||||
.. method:: Field.__init__
|
.. method:: Field.__init__
|
||||||
|
|
||||||
|
|
|
@ -1895,12 +1895,13 @@ a new view to your admin site, extend the base
|
||||||
a pattern for your new view.
|
a pattern for your new view.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Any view you render that uses the admin templates, or extends the base
|
Any view you render that uses the admin templates, or extends the base
|
||||||
admin template, should provide the ``current_app`` argument to
|
admin template, should provide the ``current_app`` argument to
|
||||||
:class:`~django.template.RequestContext` or :class:`~django.template.Context`
|
:class:`~django.template.RequestContext` or
|
||||||
when rendering the template. It should be set to either ``self.name`` if
|
:class:`~django.template.Context` when rendering the template. It should
|
||||||
your view is on an ``AdminSite`` or ``self.admin_site.name`` if your view
|
be set to either ``self.name`` if your view is on an ``AdminSite`` or
|
||||||
is on a ``ModelAdmin``.
|
``self.admin_site.name`` if your view is on a ``ModelAdmin``.
|
||||||
|
|
||||||
.. _admin-reverse-urls:
|
.. _admin-reverse-urls:
|
||||||
|
|
||||||
|
|
|
@ -1765,11 +1765,13 @@ If the :doc:`staticfiles</ref/contrib/staticfiles>` contrib app is enabled
|
||||||
files into this directory. See the howto on :doc:`managing static
|
files into this directory. See the howto on :doc:`managing static
|
||||||
files</howto/static-files>` for more details about usage.
|
files</howto/static-files>` for more details about usage.
|
||||||
|
|
||||||
.. warning:: This should be an (initially empty) destination directory for
|
.. warning::
|
||||||
collecting your static files from their permanent locations into one
|
|
||||||
directory for ease of deployment; it is **not** a place to store your
|
This should be an (initially empty) destination directory for collecting
|
||||||
static files permanently. You should do that in directories that will be
|
your static files from their permanent locations into one directory for
|
||||||
found by :doc:`staticfiles</ref/contrib/staticfiles>`'s
|
ease of deployment; it is **not** a place to store your static files
|
||||||
|
permanently. You should do that in directories that will be found by
|
||||||
|
:doc:`staticfiles</ref/contrib/staticfiles>`'s
|
||||||
:setting:`finders<STATICFILES_FINDERS>`, which by default, are
|
:setting:`finders<STATICFILES_FINDERS>`, which by default, are
|
||||||
``'static/'`` app sub-directories and any directories you include in
|
``'static/'`` app sub-directories and any directories you include in
|
||||||
:setting:`STATICFILES_DIRS`).
|
:setting:`STATICFILES_DIRS`).
|
||||||
|
@ -2059,9 +2061,9 @@ format of the current locale.
|
||||||
See also :setting:`USE_I18N` and :setting:`LANGUAGE_CODE`
|
See also :setting:`USE_I18N` and :setting:`LANGUAGE_CODE`
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
The default :file:`settings.py` file created by
|
|
||||||
:djadmin:`django-admin.py startproject <startproject>` includes
|
The default :file:`settings.py` file created by :djadmin:`django-admin.py
|
||||||
``USE_L10N = True`` for convenience.
|
startproject <startproject>` includes ``USE_L10N = True`` for convenience.
|
||||||
|
|
||||||
.. setting:: USE_THOUSAND_SEPARATOR
|
.. setting:: USE_THOUSAND_SEPARATOR
|
||||||
|
|
||||||
|
|
|
@ -404,11 +404,12 @@ optional, third positional argument, ``processors``. In this example, the
|
||||||
return HttpResponse(t.render(c))
|
return HttpResponse(t.render(c))
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
If you're using Django's :func:`~django.shortcuts.render_to_response()`
|
If you're using Django's :func:`~django.shortcuts.render_to_response()`
|
||||||
shortcut to populate a template with the contents of a dictionary, your
|
shortcut to populate a template with the contents of a dictionary, your
|
||||||
template will be passed a ``Context`` instance by default (not a
|
template will be passed a ``Context`` instance by default (not a
|
||||||
``RequestContext``). To use a ``RequestContext`` in your template rendering,
|
``RequestContext``). To use a ``RequestContext`` in your template
|
||||||
pass an optional third argument to
|
rendering, pass an optional third argument to
|
||||||
:func:`~django.shortcuts.render_to_response()`: a ``RequestContext``
|
:func:`~django.shortcuts.render_to_response()`: a ``RequestContext``
|
||||||
instance. Your code might look like this::
|
instance. Your code might look like this::
|
||||||
|
|
||||||
|
@ -704,12 +705,13 @@ class. Here are the template loaders that come with Django:
|
||||||
)
|
)
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
All of the built-in Django template tags are safe to use with the cached
|
|
||||||
loader, but if you're using custom template tags that come from third
|
All of the built-in Django template tags are safe to use with the
|
||||||
party packages, or that you wrote yourself, you should ensure that the
|
cached loader, but if you're using custom template tags that come from
|
||||||
``Node`` implementation for each tag is thread-safe. For more
|
third party packages, or that you wrote yourself, you should ensure
|
||||||
information, see
|
that the ``Node`` implementation for each tag is thread-safe. For more
|
||||||
:ref:`template tag thread safety considerations<template_tag_thread_safety>`.
|
information, see :ref:`template tag thread safety
|
||||||
|
considerations<template_tag_thread_safety>`.
|
||||||
|
|
||||||
This loader is disabled by default.
|
This loader is disabled by default.
|
||||||
|
|
||||||
|
|
|
@ -98,13 +98,13 @@ view; it'll return that :class:`~django.http.HttpResponse`. Response
|
||||||
middleware is always called on every response.
|
middleware is always called on every response.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
Accessing :attr:`request.POST <django.http.HttpRequest.POST>` or
|
|
||||||
:attr:`request.REQUEST <django.http.HttpRequest.REQUEST>` inside
|
Accessing :attr:`request.POST <django.http.HttpRequest.POST>` or
|
||||||
middleware from ``process_request`` or ``process_view`` will prevent any
|
:attr:`request.REQUEST <django.http.HttpRequest.REQUEST>` inside middleware
|
||||||
view running after the middleware from being able to
|
from ``process_request`` or ``process_view`` will prevent any view running
|
||||||
:ref:`modify the upload handlers for the
|
after the middleware from being able to :ref:`modify the upload handlers
|
||||||
request <modifying_upload_handlers_on_the_fly>`, and should normally be
|
for the request <modifying_upload_handlers_on_the_fly>`, and should
|
||||||
avoided.
|
normally be avoided.
|
||||||
|
|
||||||
The :class:`~django.middleware.csrf.CsrfViewMiddleware` class can be
|
The :class:`~django.middleware.csrf.CsrfViewMiddleware` class can be
|
||||||
considered an exception, as it provides the
|
considered an exception, as it provides the
|
||||||
|
|
|
@ -260,9 +260,10 @@ Django's formatting system is disabled by default. To enable it, it's
|
||||||
necessary to set :setting:`USE_L10N = True <USE_L10N>` in your settings file.
|
necessary to set :setting:`USE_L10N = True <USE_L10N>` in your settings file.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
The default :file:`settings.py` file created by
|
|
||||||
:djadmin:`django-admin.py startproject <startproject>` includes
|
The default :file:`settings.py` file created by :djadmin:`django-admin.py
|
||||||
:setting:`USE_L10N = True <USE_L10N>` for convenience.
|
startproject <startproject>` includes :setting:`USE_L10N = True <USE_L10N>`
|
||||||
|
for convenience.
|
||||||
|
|
||||||
When using Django's formatting system, dates and numbers on templates will be
|
When using Django's formatting system, dates and numbers on templates will be
|
||||||
displayed using the format specified for the current locale. Two users
|
displayed using the format specified for the current locale. Two users
|
||||||
|
|
Loading…
Reference in New Issue