Fixed #8979 -- Made a bunch of typo/formatting fixes to the docs. Thanks, ramiro
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8987 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
834a041e67
commit
74f386dba2
|
@ -924,7 +924,9 @@ better to override only the section of the template which you need to change.
|
||||||
To continue the example above, we want to add a new link next to the ``History``
|
To continue the example above, we want to add a new link next to the ``History``
|
||||||
tool for the ``Page`` model. After looking at ``change_form.html`` we determine
|
tool for the ``Page`` model. After looking at ``change_form.html`` we determine
|
||||||
that we only need to override the ``object-tools`` block. Therefore here is our
|
that we only need to override the ``object-tools`` block. Therefore here is our
|
||||||
new ``change_form.html`` ::
|
new ``change_form.html`` :
|
||||||
|
|
||||||
|
.. code-block:: html+django
|
||||||
|
|
||||||
{% extends "admin/change_form.html" %}
|
{% extends "admin/change_form.html" %}
|
||||||
{% load i18n %}
|
{% load i18n %}
|
||||||
|
|
|
@ -7,6 +7,8 @@ Django's comments framework
|
||||||
.. module:: django.contrib.comments
|
.. module:: django.contrib.comments
|
||||||
:synopsis: Django's comment framework
|
:synopsis: Django's comment framework
|
||||||
|
|
||||||
|
.. highlightlang:: html+django
|
||||||
|
|
||||||
Django includes a simple, yet customizable comments framework. The built-in
|
Django includes a simple, yet customizable comments framework. The built-in
|
||||||
comments framework can be used to attach comments to any model, so you can use
|
comments framework can be used to attach comments to any model, so you can use
|
||||||
it for comments on blog entries, photos, book chapters, or anything else.
|
it for comments on blog entries, photos, book chapters, or anything else.
|
||||||
|
|
|
@ -169,7 +169,9 @@ You can specify it in two ways:
|
||||||
* Pass :attr:`~django.contrib.formtools.wizard.FormWizard.extra_context`
|
* Pass :attr:`~django.contrib.formtools.wizard.FormWizard.extra_context`
|
||||||
as extra parameters in the URLconf.
|
as extra parameters in the URLconf.
|
||||||
|
|
||||||
Here's a full example template::
|
Here's a full example template:
|
||||||
|
|
||||||
|
.. code-block:: html+django
|
||||||
|
|
||||||
{% extends "base.html" %}
|
{% extends "base.html" %}
|
||||||
|
|
||||||
|
|
|
@ -385,7 +385,7 @@ makemessages
|
||||||
------------
|
------------
|
||||||
|
|
||||||
.. versionchanged:: 1.0
|
.. versionchanged:: 1.0
|
||||||
Before 1.0 this was the "bin/make-messages.py" command.
|
Before 1.0 this was the ``bin/make-messages.py`` command.
|
||||||
|
|
||||||
Runs over the entire source tree of the current directory and pulls out all
|
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
|
strings marked for translation. It creates (or updates) a message file in the
|
||||||
|
|
|
@ -88,7 +88,7 @@ Additional ``ImageField`` attributes
|
||||||
|
|
||||||
.. attribute:: File.height
|
.. attribute:: File.height
|
||||||
|
|
||||||
Heigght of the image.
|
Height of the image.
|
||||||
|
|
||||||
Additional methods on files attached to objects
|
Additional methods on files attached to objects
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
|
|
|
@ -95,17 +95,6 @@ All attributes except ``session`` should be considered read-only.
|
||||||
|
|
||||||
.. attribute:: HttpRequest.FILES
|
.. attribute:: HttpRequest.FILES
|
||||||
|
|
||||||
.. admonition:: Changed in Django development version
|
|
||||||
|
|
||||||
In previous versions of Django, ``request.FILES`` contained
|
|
||||||
simple ``dict`` objects representing uploaded files. This is
|
|
||||||
no longer true -- files are represented by ``UploadedFile``
|
|
||||||
objects as described below.
|
|
||||||
|
|
||||||
These ``UploadedFile`` objects will emulate the old-style ``dict``
|
|
||||||
interface, but this is deprecated and will be removed in the next
|
|
||||||
release of Django.
|
|
||||||
|
|
||||||
A dictionary-like object containing all uploaded files. Each key in
|
A dictionary-like object containing all uploaded files. Each key in
|
||||||
``FILES`` is the ``name`` from the ``<input type="file" name="" />``. Each
|
``FILES`` is the ``name`` from the ``<input type="file" name="" />``. Each
|
||||||
value in ``FILES`` is an ``UploadedFile`` object containing the following
|
value in ``FILES`` is an ``UploadedFile`` object containing the following
|
||||||
|
@ -123,6 +112,16 @@ All attributes except ``session`` should be considered read-only.
|
||||||
``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank
|
``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank
|
||||||
dictionary-like object.
|
dictionary-like object.
|
||||||
|
|
||||||
|
.. versionchanged:: 1.0
|
||||||
|
|
||||||
|
In previous versions of Django, ``request.FILES`` contained simple ``dict``
|
||||||
|
objects representing uploaded files. This is no longer true -- files are
|
||||||
|
represented by ``UploadedFile`` objects as described below.
|
||||||
|
|
||||||
|
These ``UploadedFile`` objects will emulate the old-style ``dict``
|
||||||
|
interface, but this is deprecated and will be removed in the next release of
|
||||||
|
Django.
|
||||||
|
|
||||||
.. attribute:: HttpRequest.META
|
.. attribute:: HttpRequest.META
|
||||||
|
|
||||||
A standard Python dictionary containing all available HTTP headers.
|
A standard Python dictionary containing all available HTTP headers.
|
||||||
|
|
|
@ -29,7 +29,9 @@ content from a database or enable access to other template tags.
|
||||||
|
|
||||||
Block tags are surrounded by ``"{%"`` and ``"%}"``.
|
Block tags are surrounded by ``"{%"`` and ``"%}"``.
|
||||||
|
|
||||||
Example template with block tags::
|
Example template with block tags:
|
||||||
|
|
||||||
|
.. code-block:: html+django
|
||||||
|
|
||||||
{% if is_logged_in %}Thanks for logging in!{% else %}Please log in.{% endif %}
|
{% if is_logged_in %}Thanks for logging in!{% else %}Please log in.{% endif %}
|
||||||
|
|
||||||
|
@ -37,7 +39,9 @@ A **variable** is a symbol within a template that outputs a value.
|
||||||
|
|
||||||
Variable tags are surrounded by ``"{{"`` and ``"}}"``.
|
Variable tags are surrounded by ``"{{"`` and ``"}}"``.
|
||||||
|
|
||||||
Example template with variables::
|
Example template with variables:
|
||||||
|
|
||||||
|
.. code-block:: html+django
|
||||||
|
|
||||||
My first name is {{ first_name }}. My last name is {{ last_name }}.
|
My first name is {{ first_name }}. My last name is {{ last_name }}.
|
||||||
|
|
||||||
|
@ -566,7 +570,7 @@ returns the resulting string::
|
||||||
|
|
||||||
The ``render_to_string`` shortcut takes one required argument --
|
The ``render_to_string`` shortcut takes one required argument --
|
||||||
``template_name``, which should be the name of the template to load
|
``template_name``, which should be the name of the template to load
|
||||||
and render -- and two optional arguments::
|
and render -- and two optional arguments:
|
||||||
|
|
||||||
dictionary
|
dictionary
|
||||||
A dictionary to be used as variables and values for the
|
A dictionary to be used as variables and values for the
|
||||||
|
|
|
@ -14,6 +14,8 @@ documentation for any custom tags or filters installed.
|
||||||
Built-in tag reference
|
Built-in tag reference
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
|
.. highlightlang:: html+django
|
||||||
|
|
||||||
.. templatetag:: autoescape
|
.. templatetag:: autoescape
|
||||||
|
|
||||||
autoescape
|
autoescape
|
||||||
|
@ -473,7 +475,9 @@ Regroup a list of alike objects by a common attribute.
|
||||||
|
|
||||||
This complex tag is best illustrated by use of an example: say that ``people``
|
This complex tag is best illustrated by use of an example: say that ``people``
|
||||||
is a list of people represented by dictionaries with ``first_name``,
|
is a list of people represented by dictionaries with ``first_name``,
|
||||||
``last_name``, and ``gender`` keys::
|
``last_name``, and ``gender`` keys:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
people = [
|
people = [
|
||||||
{'first_name': 'George', 'last_name': 'Bush', 'gender': 'Male'},
|
{'first_name': 'George', 'last_name': 'Bush', 'gender': 'Male'},
|
||||||
|
@ -530,7 +534,9 @@ the fact that the ``people`` list was ordered by ``gender`` in the first place.
|
||||||
If the ``people`` list did *not* order its members by ``gender``, the regrouping
|
If the ``people`` list did *not* order its members by ``gender``, the regrouping
|
||||||
would naively display more than one group for a single gender. For example,
|
would naively display more than one group for a single gender. For example,
|
||||||
say the ``people`` list was set to this (note that the males are not grouped
|
say the ``people`` list was set to this (note that the males are not grouped
|
||||||
together)::
|
together):
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
people = [
|
people = [
|
||||||
{'first_name': 'Bill', 'last_name': 'Clinton', 'gender': 'Male'},
|
{'first_name': 'Bill', 'last_name': 'Clinton', 'gender': 'Male'},
|
||||||
|
@ -657,12 +663,16 @@ arguments in the URL. All arguments required by the URLconf should be present.
|
||||||
|
|
||||||
For example, suppose you have a view, ``app_views.client``, whose URLconf
|
For example, suppose you have a view, ``app_views.client``, whose URLconf
|
||||||
takes a client ID (here, ``client()`` is a method inside the views file
|
takes a client ID (here, ``client()`` is a method inside the views file
|
||||||
``app_views.py``). The URLconf line might look like this::
|
``app_views.py``). The URLconf line might look like this:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
('^client/(\d+)/$', 'app_views.client')
|
('^client/(\d+)/$', 'app_views.client')
|
||||||
|
|
||||||
If this app's URLconf is included into the project's URLconf under a path
|
If this app's URLconf is included into the project's URLconf under a path
|
||||||
such as this::
|
such as this:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
('^clients/', include('project_name.app_name.urls'))
|
('^clients/', include('project_name.app_name.urls'))
|
||||||
|
|
||||||
|
@ -682,19 +692,18 @@ Note that if the URL you're reversing doesn't exist, you'll get an
|
||||||
:exc:`NoReverseMatch` exception raised, which will cause your site to display an
|
:exc:`NoReverseMatch` exception raised, which will cause your site to display an
|
||||||
error page.
|
error page.
|
||||||
|
|
||||||
**New in development verson:** If you'd like to retrieve a URL without displaying it,
|
.. versionadded:: 1.0
|
||||||
you can use a slightly different call:
|
|
||||||
|
If you'd like to retrieve a URL without displaying it, you can use a slightly
|
||||||
|
different call::
|
||||||
|
|
||||||
.. code-block:: html+django
|
|
||||||
|
|
||||||
{% url path.to.view arg, arg2 as the_url %}
|
{% url path.to.view arg, arg2 as the_url %}
|
||||||
|
|
||||||
<a href="{{ the_url }}">I'm linking to {{ the_url }}</a>
|
<a href="{{ the_url }}">I'm linking to {{ the_url }}</a>
|
||||||
|
|
||||||
This ``{% url ... as var %}`` syntax will *not* cause an error if the view is
|
This ``{% url ... as var %}`` syntax will *not* cause an error if the view is
|
||||||
missing. In practice you'll use this to link to views that are optional:
|
missing. In practice you'll use this to link to views that are optional::
|
||||||
|
|
||||||
.. code-block:: html+django
|
|
||||||
|
|
||||||
{% url path.to.view as the_url %}
|
{% url path.to.view as the_url %}
|
||||||
{% if the_url %}
|
{% if the_url %}
|
||||||
|
@ -845,7 +854,9 @@ For example::
|
||||||
|
|
||||||
{{ value|dictsort:"name" }}
|
{{ value|dictsort:"name" }}
|
||||||
|
|
||||||
If ``value`` is::
|
If ``value`` is:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
[
|
[
|
||||||
{'name': 'zed', 'age': 19},
|
{'name': 'zed', 'age': 19},
|
||||||
|
@ -853,7 +864,9 @@ If ``value`` is::
|
||||||
{'name': 'joe', 'age': 31},
|
{'name': 'joe', 'age': 31},
|
||||||
]
|
]
|
||||||
|
|
||||||
then the output would be::
|
then the output would be:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
[
|
[
|
||||||
{'name': 'amy', 'age': 22},
|
{'name': 'amy', 'age': 22},
|
||||||
|
@ -1274,7 +1287,9 @@ Uses the same syntax as Python's list slicing. See
|
||||||
http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice
|
http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice
|
||||||
for an introduction.
|
for an introduction.
|
||||||
|
|
||||||
Example: ``{{ some_list|slice:":2" }}``
|
Example::
|
||||||
|
|
||||||
|
{{ some_list|slice:":2" }}
|
||||||
|
|
||||||
.. templatefilter:: slugify
|
.. templatefilter:: slugify
|
||||||
|
|
||||||
|
|
|
@ -306,7 +306,9 @@ management form inside the template. Lets look at a sample view::
|
||||||
formset = ArticleFormSet()
|
formset = ArticleFormSet()
|
||||||
return render_to_response('manage_articles.html', {'formset': formset})
|
return render_to_response('manage_articles.html', {'formset': formset})
|
||||||
|
|
||||||
The ``manage_articles.html`` template might look like this::
|
The ``manage_articles.html`` template might look like this:
|
||||||
|
|
||||||
|
.. code-block:: html+django
|
||||||
|
|
||||||
<form method="POST" action="">
|
<form method="POST" action="">
|
||||||
{{ formset.management_form }}
|
{{ formset.management_form }}
|
||||||
|
@ -318,7 +320,9 @@ The ``manage_articles.html`` template might look like this::
|
||||||
</form>
|
</form>
|
||||||
|
|
||||||
However the above can be slightly shortcutted and let the formset itself deal
|
However the above can be slightly shortcutted and let the formset itself deal
|
||||||
with the management form::
|
with the management form:
|
||||||
|
|
||||||
|
.. code-block:: html+django
|
||||||
|
|
||||||
<form method="POST" action="">
|
<form method="POST" action="">
|
||||||
<table>
|
<table>
|
||||||
|
|
|
@ -10,6 +10,8 @@ Working with forms
|
||||||
For a more detailed look at the forms API, see :ref:`ref-forms-api`. For
|
For a more detailed look at the forms API, see :ref:`ref-forms-api`. For
|
||||||
documentation of the available field types, see :ref:`ref-forms-fields`.
|
documentation of the available field types, see :ref:`ref-forms-fields`.
|
||||||
|
|
||||||
|
.. highlightlang:: html+django
|
||||||
|
|
||||||
``django.forms`` is Django's form-handling library.
|
``django.forms`` is Django's form-handling library.
|
||||||
|
|
||||||
While it is possible to process form submissions just using Django's
|
While it is possible to process form submissions just using Django's
|
||||||
|
@ -60,7 +62,9 @@ make use of a declarative style that you'll be familiar with if you've used
|
||||||
Django's database models.
|
Django's database models.
|
||||||
|
|
||||||
For example, consider a form used to implement "contact me" functionality on a
|
For example, consider a form used to implement "contact me" functionality on a
|
||||||
personal Web site::
|
personal Web site:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
from django import forms
|
from django import forms
|
||||||
|
|
||||||
|
@ -82,7 +86,9 @@ description.
|
||||||
Using a form in a view
|
Using a form in a view
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
The standard pattern for processing a form in a view looks like this::
|
The standard pattern for processing a form in a view looks like this:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
def contact(request):
|
def contact(request):
|
||||||
if request.method == 'POST': # If the form has been submitted...
|
if request.method == 'POST': # If the form has been submitted...
|
||||||
|
@ -133,7 +139,9 @@ also be converted in to the relevant Python types for you. In the above example,
|
||||||
``cc_myself`` will be a boolean value. Likewise, fields such as ``IntegerField``
|
``cc_myself`` will be a boolean value. Likewise, fields such as ``IntegerField``
|
||||||
and ``FloatField`` convert values to a Python int and float respectively.
|
and ``FloatField`` convert values to a Python int and float respectively.
|
||||||
|
|
||||||
Extending the above example, here's how the form data could be processed::
|
Extending the above example, here's how the form data could be processed:
|
||||||
|
|
||||||
|
.. code-block:: python
|
||||||
|
|
||||||
if form.is_valid():
|
if form.is_valid():
|
||||||
subject = form.cleaned_data['subject']
|
subject = form.cleaned_data['subject']
|
||||||
|
|
|
@ -36,7 +36,7 @@ from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
|
||||||
Configuring the session engine
|
Configuring the session engine
|
||||||
==============================
|
==============================
|
||||||
|
|
||||||
.. versionadded:: 1.0.
|
.. versionadded:: 1.0
|
||||||
|
|
||||||
By default, Django stores sessions in your database (using the model
|
By default, Django stores sessions in your database (using the model
|
||||||
``django.contrib.sessions.models.Session``). Though this is convenient, in
|
``django.contrib.sessions.models.Session``). Though this is convenient, in
|
||||||
|
|
|
@ -395,7 +395,7 @@ obtain) the language translations themselves. Here's how that works.
|
||||||
application) and English strings (from Django itself). If you want to
|
application) and English strings (from Django itself). If you want to
|
||||||
support a locale for your application that is not already part of
|
support a locale for your application that is not already part of
|
||||||
Django, you'll need to make at least a minimal translation of the Django
|
Django, you'll need to make at least a minimal translation of the Django
|
||||||
core. See the relevant :ref:LocaleMiddleware note`<locale-middleware-notes>`
|
core. See the relevant :ref:`LocaleMiddleware note<locale-middleware-notes>`
|
||||||
for more details.
|
for more details.
|
||||||
|
|
||||||
Message files
|
Message files
|
||||||
|
|
|
@ -38,6 +38,8 @@ or CheetahTemplate_, you should feel right at home with Django's templates.
|
||||||
Templates
|
Templates
|
||||||
=========
|
=========
|
||||||
|
|
||||||
|
.. highlightlang:: html+django
|
||||||
|
|
||||||
A template is simply a text file. It can generate any text-based format (HTML,
|
A template is simply a text file. It can generate any text-based format (HTML,
|
||||||
XML, CSV, etc.).
|
XML, CSV, etc.).
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue