Fixed some ReST errors regarding backticks
This commit is contained in:
parent
354009d67e
commit
29255fcb4f
|
@ -295,9 +295,9 @@ validation process will break.
|
|||
Therefore, you must ensure that the form field used to represent your
|
||||
custom field performs whatever input validation and data cleaning is
|
||||
necessary to convert user-provided form input into a
|
||||
`to_python()`-compatible model field value. This may require writing a
|
||||
``to_python()``-compatible model field value. This may require writing a
|
||||
custom form field, and/or implementing the :meth:`.formfield` method on
|
||||
your field to return a form field class whose `to_python()` returns the
|
||||
your field to return a form field class whose ``to_python()`` returns the
|
||||
correct datatype.
|
||||
|
||||
Documenting your custom field
|
||||
|
|
|
@ -28,6 +28,7 @@ the easiest, fastest, and most stable deployment choice.
|
|||
* `Chapter 12 of the Django Book (second edition)`_ discusses deployment
|
||||
and especially scaling in more detail. However, note that this edition
|
||||
was written against Django version 1.1 and has not been updated since
|
||||
`mod_python` was first deprecated, then completely removed in Django 1.5.
|
||||
``mod_python`` was first deprecated, then completely removed in
|
||||
Django 1.5.
|
||||
|
||||
.. _chapter 12 of the django book (second edition): http://djangobook.com/en/2.0/chapter12/
|
||||
|
|
|
@ -16,7 +16,7 @@ version >= 2.2 and mod_wsgi >= 2.0. For example, you could:
|
|||
|
||||
.. note::
|
||||
If you have installed a :ref:`custom User model <auth-custom-user>` and
|
||||
want to use this default auth handler, it must support an `is_active`
|
||||
want to use this default auth handler, it must support an ``is_active``
|
||||
attribute. If you want to use group based authorization, your custom user
|
||||
must have a relation named 'groups', referring to a related object that has
|
||||
a 'name' field. You can also specify your own custom mod_wsgi
|
||||
|
|
|
@ -193,7 +193,7 @@ other approaches:
|
|||
configuration).
|
||||
|
||||
2. Use an ``Alias`` directive, as demonstrated above, to alias the appropriate
|
||||
URL (probably :setting:`STATIC_URL` + `admin/`) to the actual location of
|
||||
URL (probably :setting:`STATIC_URL` + ``admin/``) to the actual location of
|
||||
the admin files.
|
||||
|
||||
3. Copy the admin static files so that they live within your Apache
|
||||
|
|
|
@ -600,7 +600,7 @@ for your own sanity when dealing with the interactive prompt, but also because
|
|||
objects' representations are used throughout Django's automatically-generated
|
||||
admin.
|
||||
|
||||
.. admonition:: `__unicode__` or `__str__`?
|
||||
.. admonition:: ``__unicode__`` or ``__str__``?
|
||||
|
||||
On Python 3, things are simpler, just use
|
||||
:meth:`~django.db.models.Model.__str__` and forget about
|
||||
|
|
|
@ -269,8 +269,8 @@ Making actions available site-wide
|
|||
|
||||
admin.site.add_action(export_selected_objects)
|
||||
|
||||
This makes the `export_selected_objects` action globally available as an
|
||||
action named `"export_selected_objects"`. You can explicitly give the action
|
||||
This makes the ``export_selected_objects`` action globally available as an
|
||||
action named "export_selected_objects". You can explicitly give the action
|
||||
a name -- good if you later want to programmatically :ref:`remove the action
|
||||
<disabling-admin-actions>` -- by passing a second argument to
|
||||
:meth:`AdminSite.add_action()`::
|
||||
|
|
|
@ -156,6 +156,6 @@ Edit this object
|
|||
Using these bookmarklets requires that you are either logged into the
|
||||
:mod:`Django admin <django.contrib.admin>` as a
|
||||
:class:`~django.contrib.auth.models.User` with
|
||||
:attr:`~django.contrib.auth.models.User.is_staff` set to `True`, or that the
|
||||
:attr:`~django.contrib.auth.models.User.is_staff` set to ``True``, or that the
|
||||
``XViewMiddleware`` is installed and you are accessing the site from an IP
|
||||
address listed in :setting:`INTERNAL_IPS`.
|
||||
|
|
|
@ -913,7 +913,7 @@ needed by ``select_related``), it is able to detect that the ``best_pizza``
|
|||
objects have already been fetched, and it will skip fetching them again.
|
||||
|
||||
Chaining ``prefetch_related`` calls will accumulate the lookups that are
|
||||
prefetched. To clear any ``prefetch_related`` behavior, pass `None` as a
|
||||
prefetched. To clear any ``prefetch_related`` behavior, pass ``None`` as a
|
||||
parameter::
|
||||
|
||||
>>> non_prefetched = qs.prefetch_related(None)
|
||||
|
|
|
@ -75,7 +75,7 @@ Minor features
|
|||
context level.
|
||||
|
||||
* The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
|
||||
``updated`` element now utilizes `updateddate` instead of ``pubdate``,
|
||||
``updated`` element now utilizes ``updateddate`` instead of ``pubdate``,
|
||||
allowing the ``published`` element to be included in the feed (which
|
||||
relies on ``pubdate``).
|
||||
|
||||
|
|
|
@ -686,13 +686,13 @@ auth views.
|
|||
* :class:`~django.contrib.auth.forms.AuthenticationForm`
|
||||
|
||||
Works with any subclass of :class:`~django.contrib.auth.models.AbstractBaseUser`,
|
||||
and will adapt to use the field defined in `USERNAME_FIELD`.
|
||||
and will adapt to use the field defined in ``USERNAME_FIELD``.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.PasswordResetForm`
|
||||
|
||||
Assumes that the user model has an integer primary key, has a field named
|
||||
``email`` that can be used to identify the user, and a boolean field
|
||||
named `is_active` to prevent password resets for inactive users.
|
||||
named ``is_active`` to prevent password resets for inactive users.
|
||||
|
||||
* :class:`~django.contrib.auth.forms.SetPasswordForm`
|
||||
|
||||
|
|
|
@ -265,8 +265,8 @@ Methods are copied according to the following rules:
|
|||
|
||||
- Public methods are copied by default.
|
||||
- Private methods (starting with an underscore) are not copied by default.
|
||||
- Methods with a `queryset_only` attribute set to `False` are always copied.
|
||||
- Methods with a `queryset_only` attribute set to `True` are never copied.
|
||||
- Methods with a ``queryset_only`` attribute set to ``False`` are always copied.
|
||||
- Methods with a ``queryset_only`` attribute set to ``True`` are never copied.
|
||||
|
||||
For example::
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ introduce controlled coupling for convenience's sake.
|
|||
:class:`~django.http.HttpResponse` object with that rendered text.
|
||||
|
||||
:func:`render()` is the same as a call to
|
||||
:func:`render_to_response()` with a `context_instance` argument that
|
||||
:func:`render_to_response()` with a ``context_instance`` argument that
|
||||
forces the use of a :class:`~django.template.RequestContext`.
|
||||
|
||||
Required arguments
|
||||
|
@ -169,7 +169,8 @@ This example is equivalent to::
|
|||
|
||||
The arguments could be:
|
||||
|
||||
* A model: the model's `get_absolute_url()` function will be called.
|
||||
* A model: the model's `:meth:`~django.db.models.Model.get_absolute_url()`
|
||||
function will be called.
|
||||
|
||||
* A view name, possibly with arguments: :func:`urlresolvers.reverse
|
||||
<django.core.urlresolvers.reverse>` will be used to reverse-resolve the
|
||||
|
|
Loading…
Reference in New Issue