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:
Adrian Holovaty 2008-09-09 01:54:20 +00:00
parent 834a041e67
commit 74f386dba2
13 changed files with 78 additions and 40 deletions

View File

@ -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 %}

View File

@ -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.

View File

@ -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" %}

View File

@ -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

View File

@ -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
----------------------------------------------- -----------------------------------------------

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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']

View File

@ -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

View File

@ -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

View File

@ -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.).