mirror of https://github.com/django/django.git
Fixed #7814 -- Fixed a number of style inconsistencies in the docs. Thanks, uzi and programmerq
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8043 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
ca98003390
commit
bfcecfee91
|
@ -59,7 +59,7 @@ These APIs are stable:
|
|||
|
||||
- `Request/response objects`_.
|
||||
|
||||
- `Sending email`_.
|
||||
- `Sending e-mail`_.
|
||||
|
||||
- `Sessions`_.
|
||||
|
||||
|
@ -108,7 +108,7 @@ change:
|
|||
.. _mod_python integration: ../modpython/
|
||||
.. _redirects: ../redirects/
|
||||
.. _request/response objects: ../request_response/
|
||||
.. _sending email: ../email/
|
||||
.. _sending e-mail: ../email/
|
||||
.. _sessions: ../sessions/
|
||||
.. _settings: ../settings/
|
||||
.. _syndication: ../syndication_feeds/
|
||||
|
|
|
@ -631,7 +631,7 @@ The page shown after a user has changed their password.
|
|||
**Description:**
|
||||
|
||||
Allows a user to reset their password, and sends them the new password
|
||||
in an email.
|
||||
in an e-mail.
|
||||
|
||||
**Optional arguments:**
|
||||
|
||||
|
@ -640,7 +640,7 @@ in an email.
|
|||
``registration/password_reset_form.html`` if not supplied.
|
||||
|
||||
* ``email_template_name``: The full name of a template to use for
|
||||
generating the email with the new password. This will default to
|
||||
generating the e-mail with the new password. This will default to
|
||||
``registration/password_reset_email.html`` if not supplied.
|
||||
|
||||
**Template context:**
|
||||
|
@ -696,7 +696,7 @@ system provides several built-in forms:
|
|||
user to change their password.
|
||||
|
||||
* ``django.contrib.auth.forms.PasswordResetForm``: A form for resetting a
|
||||
user's password and emailing the new password to them.
|
||||
user's password and e-mailing the new password to them.
|
||||
|
||||
* ``django.contrib.auth.forms.UserCreationForm``: A form for creating a
|
||||
new user.
|
||||
|
|
|
@ -4,8 +4,8 @@ Cross Site Request Forgery protection
|
|||
|
||||
The CsrfMiddleware class provides easy-to-use protection against
|
||||
`Cross Site Request Forgeries`_. This type of attack occurs when a malicious
|
||||
web site creates a link or form button that is intended to perform some action
|
||||
on your web site, using the credentials of a logged-in user who is tricked
|
||||
Web site creates a link or form button that is intended to perform some action
|
||||
on your Web site, using the credentials of a logged-in user who is tricked
|
||||
into clicking on the link in their browser.
|
||||
|
||||
The first defense against CSRF attacks is to ensure that GET requests
|
||||
|
@ -38,7 +38,7 @@ CsrfMiddleware does two things:
|
|||
checks that the 'csrfmiddlewaretoken' is present and correct. If it
|
||||
isn't, the user will get a 403 error.
|
||||
|
||||
This ensures that only forms that have originated from your web site
|
||||
This ensures that only forms that have originated from your Web site
|
||||
can be used to POST data back.
|
||||
|
||||
It deliberately only targets HTTP POST requests (and the corresponding POST
|
||||
|
@ -47,7 +47,7 @@ effects (see `9.1.1 Safe Methods, HTTP 1.1, RFC 2616`_), and so a
|
|||
CSRF attack with a GET request ought to be harmless.
|
||||
|
||||
POST requests that are not accompanied by a session cookie are not protected,
|
||||
but they do not need to be protected, since the 'attacking' web site
|
||||
but they do not need to be protected, since the 'attacking' Web site
|
||||
could make these kind of requests anyway.
|
||||
|
||||
The Content-Type is checked before modifying the response, and only
|
||||
|
|
|
@ -463,7 +463,7 @@ Be careful, if you are using ``extra()`` to add custom handling to your
|
|||
may or may not make sense. If you are using custom SQL fragments in your
|
||||
``extra()`` calls, Django will not inspect these fragments to see if they need
|
||||
to be rewritten because of changes in the merged query. So test the effects
|
||||
carefully. Also realise that if you are combining two ``QuerySets`` with
|
||||
carefully. Also realize that if you are combining two ``QuerySets`` with
|
||||
``|``, you cannot use ``extra(select=...)`` or ``extra(where=...)`` on *both*
|
||||
``QuerySets``. You can only use those calls on one or the other (Django will
|
||||
raise a ``ValueError`` if you try to use this incorrectly).
|
||||
|
|
|
@ -395,7 +395,7 @@ makemessages
|
|||
|
||||
Runs over the entire source tree of the current directory and pulls out all
|
||||
strings marked for translation. It creates (or updates) a message file in the
|
||||
conf/locale (in the django tree) or locale (for project and application)
|
||||
conf/locale (in the Django tree) or locale (for project and application)
|
||||
directory. After making changes to the messages files you need to compile them
|
||||
with ``compilemessages`` for use with the builtin gettext support. See the
|
||||
`i18n documentation`_ for details.
|
||||
|
|
|
@ -1557,7 +1557,7 @@ mentioned above (``required``, ``label``, ``initial``, ``widget``,
|
|||
Custom form and field validation
|
||||
---------------------------------
|
||||
|
||||
Form validation happens when the data is cleaned. If you want to customise
|
||||
Form validation happens when the data is cleaned. If you want to customize
|
||||
this process, there are various places you can change, each one serving a
|
||||
different purpose. Three types of cleaning methods are run during form
|
||||
processing. These are normally executed when you call the ``is_valid()``
|
||||
|
@ -1568,7 +1568,7 @@ directly), but normally they won't be needed.
|
|||
In general, any cleaning method can raise ``ValidationError`` if there is a
|
||||
problem with the data it is processing, passing the relevant error message to
|
||||
the ``ValidationError`` constructor. If no ``ValidationError`` is raised, the
|
||||
method should return the cleaned (normalised) data as a Python object.
|
||||
method should return the cleaned (normalized) data as a Python object.
|
||||
|
||||
If you detect multiple errors during a cleaning method and wish to signal all
|
||||
of them to the form submitter, it is possible to pass a list of errors to the
|
||||
|
@ -1601,7 +1601,7 @@ The three types of cleaning methods are:
|
|||
* The Form subclass's ``clean()`` method. This method can perform
|
||||
any validation that requires access to multiple fields from the form at
|
||||
once. This is where you might put in things to check that if field ``A``
|
||||
is supplied, field ``B`` must contain a valid email address and the
|
||||
is supplied, field ``B`` must contain a valid e-mail address and the
|
||||
like. The data that this method returns is the final ``cleaned_data``
|
||||
attribute for the form, so don't forget to return the full list of
|
||||
cleaned data if you override this method (by default, ``Form.clean()``
|
||||
|
@ -1723,7 +1723,7 @@ Customizing widget instances
|
|||
When Django renders a widget as HTML, it only renders the bare minimum
|
||||
HTML - Django doesn't add a class definition, or any other widget-specific
|
||||
attributes. This means that all 'TextInput' widgets will appear the same
|
||||
on your web page.
|
||||
on your Web page.
|
||||
|
||||
If you want to make one widget look different to another, you need to
|
||||
specify additional attributes for each widget. When you specify a
|
||||
|
@ -1747,7 +1747,7 @@ each widget will be rendered exactly the same::
|
|||
<tr><th>Url:</th><td><input type="text" name="url"/></td></tr>
|
||||
<tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
|
||||
|
||||
On a real web page, you probably don't want every widget to look the same. You
|
||||
On a real Web page, you probably don't want every widget to look the same. You
|
||||
might want a larger input element for the comment, and you might want the
|
||||
'name' widget to have some special CSS class. To do this, you specify a
|
||||
custom widget for your fields, and specify some attributes to use
|
||||
|
|
|
@ -888,7 +888,7 @@ does translation:
|
|||
* The string domain is ``django`` or ``djangojs``. This string domain is
|
||||
used to differentiate between different programs that store their data
|
||||
in a common message-file library (usually ``/usr/share/locale/``). The
|
||||
``django`` domain is used for python and template translation strings
|
||||
``django`` domain is used for Python and template translation strings
|
||||
and is loaded into the global translation catalogs. The ``djangojs``
|
||||
domain is only used for JavaScript translation catalogs to make sure
|
||||
that those are as small as possible.
|
||||
|
|
|
@ -18,7 +18,7 @@ Install Apache and mod_python
|
|||
=============================
|
||||
|
||||
If you just want to experiment with Django, skip ahead to the next
|
||||
section; Django includes a lightweight web server you can use for
|
||||
section; Django includes a lightweight Web server you can use for
|
||||
testing, so you won't need to set up Apache until you're ready to
|
||||
deploy Django in production.
|
||||
|
||||
|
@ -64,7 +64,7 @@ installed.
|
|||
You will also want to read the database-specific notes for the `MySQL backend`_.
|
||||
|
||||
* If you're using SQLite and either Python 2.3 or Python 2.4, you'll need
|
||||
pysqlite_. Use version 2.0.3 or higher. Python 2.5 ships with an sqlite
|
||||
pysqlite_. Use version 2.0.3 or higher. Python 2.5 ships with an SQLite
|
||||
wrapper in the standard library, so you don't need to install anything extra
|
||||
in that case.
|
||||
|
||||
|
|
|
@ -99,7 +99,7 @@ Problem reports and getting help
|
|||
================================
|
||||
|
||||
Need help resolving a problem with Django? The documentation in the
|
||||
distribution is also available online_ at the `Django website`_. The FAQ_
|
||||
distribution is also available online_ at the `Django Web site`_. The FAQ_
|
||||
document is especially recommended, as it contains a number of issues that
|
||||
come up time and again.
|
||||
|
||||
|
@ -115,7 +115,7 @@ Django users and developers from around the world. Friendly people are usually
|
|||
available at any hour of the day -- to help, or just to chat.
|
||||
|
||||
.. _online: http://www.djangoproject.com/documentation/0.95/
|
||||
.. _Django website: http://www.djangoproject.com/
|
||||
.. _Django Web site: http://www.djangoproject.com/
|
||||
.. _FAQ: http://www.djangoproject.com/documentation/faq/
|
||||
.. _django-users: http://groups.google.com/group/django-users
|
||||
|
||||
|
|
|
@ -1945,7 +1945,7 @@ information.
|
|||
django.contrib.webdesign
|
||||
------------------------
|
||||
|
||||
A collection of template tags that can be useful while designing a website,
|
||||
A collection of template tags that can be useful while designing a Web site,
|
||||
such as a generator of Lorem Ipsum text. See the `webdesign documentation`_.
|
||||
|
||||
.. _webdesign documentation: ../webdesign/
|
||||
|
|
|
@ -441,11 +441,11 @@ Here's what happens if a user goes to "/polls/34/" in this system:
|
|||
|
||||
* Django will find the match at ``'^polls/'``
|
||||
* It will strip off the matching text (``"polls/"``) and send the remaining
|
||||
text -- ``"34/"`` -- to the 'mysite.polls.urls' urlconf for
|
||||
text -- ``"34/"`` -- to the 'mysite.polls.urls' URLconf for
|
||||
further processing.
|
||||
|
||||
Now that we've decoupled that, we need to decouple the
|
||||
'mysite.polls.urls' urlconf by removing the leading "polls/" from each
|
||||
'mysite.polls.urls' URLconf by removing the leading "polls/" from each
|
||||
line::
|
||||
|
||||
urlpatterns = patterns('mysite.polls.views',
|
||||
|
|
|
@ -373,7 +373,7 @@ Including other URLconfs
|
|||
At any point, your ``urlpatterns`` can "include" other URLconf modules. This
|
||||
essentially "roots" a set of URLs below other ones.
|
||||
|
||||
For example, here's the URLconf for the `Django website`_ itself. It includes a
|
||||
For example, here's the URLconf for the `Django Web site`_ itself. It includes a
|
||||
number of other URLconfs::
|
||||
|
||||
from django.conf.urls.defaults import *
|
||||
|
@ -390,7 +390,7 @@ Django encounters ``include()``, it chops off whatever part of the URL matched
|
|||
up to that point and sends the remaining string to the included URLconf for
|
||||
further processing.
|
||||
|
||||
.. _`Django website`: http://www.djangoproject.com/
|
||||
.. _`Django Web site`: http://www.djangoproject.com/
|
||||
|
||||
Captured parameters
|
||||
-------------------
|
||||
|
|
Loading…
Reference in New Issue