mirror of
https://github.com/django/django.git
synced 2025-08-04 10:59:45 +00:00
Fixed many more ReST indentation errors, somehow accidentally missed from [16955]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Luke Plant
parent
5109ac3709
commit
d1e5c55258
129 changed files with 5708 additions and 5740 deletions
|
|
@ -17,10 +17,10 @@ While it is possible to process form submissions just using Django's
|
|||
:class:`~django.http.HttpRequest` class, using the form library takes care of a
|
||||
number of common form-related tasks. Using it, you can:
|
||||
|
||||
1. Display an HTML form with automatically generated form widgets.
|
||||
2. Check submitted data against a set of validation rules.
|
||||
3. Redisplay a form in the case of validation errors.
|
||||
4. Convert submitted form data to the relevant Python data types.
|
||||
1. Display an HTML form with automatically generated form widgets.
|
||||
2. Check submitted data against a set of validation rules.
|
||||
3. Redisplay a form in the case of validation errors.
|
||||
4. Convert submitted form data to the relevant Python data types.
|
||||
|
||||
Overview
|
||||
========
|
||||
|
|
@ -106,13 +106,13 @@ The standard pattern for processing a form in a view looks like this:
|
|||
|
||||
There are three code paths here:
|
||||
|
||||
1. If the form has not been submitted, an unbound instance of ContactForm is
|
||||
created and passed to the template.
|
||||
2. If the form has been submitted, a bound instance of the form is created
|
||||
using ``request.POST``. If the submitted data is valid, it is processed
|
||||
and the user is re-directed to a "thanks" page.
|
||||
3. If the form has been submitted but is invalid, the bound form instance is
|
||||
passed on to the template.
|
||||
1. If the form has not been submitted, an unbound instance of ContactForm is
|
||||
created and passed to the template.
|
||||
2. If the form has been submitted, a bound instance of the form is created
|
||||
using ``request.POST``. If the submitted data is valid, it is processed
|
||||
and the user is re-directed to a "thanks" page.
|
||||
3. If the form has been submitted but is invalid, the bound form instance is
|
||||
passed on to the template.
|
||||
|
||||
The distinction between **bound** and **unbound** forms is important. An unbound
|
||||
form does not have any data associated with it; when rendered to the user, it
|
||||
|
|
@ -287,35 +287,35 @@ Within this loop, ``{{ field }}`` is an instance of :class:`BoundField`.
|
|||
``BoundField`` also has the following attributes, which can be useful in your
|
||||
templates:
|
||||
|
||||
``{{ field.label }}``
|
||||
The label of the field, e.g. ``Email address``.
|
||||
``{{ field.label }}``
|
||||
The label of the field, e.g. ``Email address``.
|
||||
|
||||
``{{ field.label_tag }}``
|
||||
The field's label wrapped in the appropriate HTML ``<label>`` tag,
|
||||
e.g. ``<label for="id_email">Email address</label>``
|
||||
``{{ field.label_tag }}``
|
||||
The field's label wrapped in the appropriate HTML ``<label>`` tag,
|
||||
e.g. ``<label for="id_email">Email address</label>``
|
||||
|
||||
``{{ field.html_name }}``
|
||||
The name of the field that will be used in the input element's name
|
||||
field. This takes the form prefix into account, if it has been set.
|
||||
``{{ field.html_name }}``
|
||||
The name of the field that will be used in the input element's name
|
||||
field. This takes the form prefix into account, if it has been set.
|
||||
|
||||
``{{ field.help_text }}``
|
||||
Any help text that has been associated with the field.
|
||||
``{{ field.help_text }}``
|
||||
Any help text that has been associated with the field.
|
||||
|
||||
``{{ field.errors }}``
|
||||
Outputs a ``<ul class="errorlist">`` containing any validation errors
|
||||
corresponding to this field. You can customize the presentation of
|
||||
the errors with a ``{% for error in field.errors %}`` loop. In this
|
||||
case, each object in the loop is a simple string containing the error
|
||||
message.
|
||||
``{{ field.errors }}``
|
||||
Outputs a ``<ul class="errorlist">`` containing any validation errors
|
||||
corresponding to this field. You can customize the presentation of
|
||||
the errors with a ``{% for error in field.errors %}`` loop. In this
|
||||
case, each object in the loop is a simple string containing the error
|
||||
message.
|
||||
|
||||
``field.is_hidden``
|
||||
This attribute is ``True`` if the form field is a hidden field and
|
||||
``False`` otherwise. It's not particularly useful as a template
|
||||
variable, but could be useful in conditional tests such as::
|
||||
``field.is_hidden``
|
||||
This attribute is ``True`` if the form field is a hidden field and
|
||||
``False`` otherwise. It's not particularly useful as a template
|
||||
variable, but could be useful in conditional tests such as::
|
||||
|
||||
{% if field.is_hidden %}
|
||||
{# Do something special #}
|
||||
{% endif %}
|
||||
{% if field.is_hidden %}
|
||||
{# Do something special #}
|
||||
{% endif %}
|
||||
|
||||
Looping over hidden and visible fields
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -45,70 +45,70 @@ model field has a corresponding default form field. For example, a
|
|||
model ``ManyToManyField`` is represented as a ``MultipleChoiceField``. Here is
|
||||
the full list of conversions:
|
||||
|
||||
=============================== ========================================
|
||||
Model field Form field
|
||||
=============================== ========================================
|
||||
``AutoField`` Not represented in the form
|
||||
=============================== ========================================
|
||||
Model field Form field
|
||||
=============================== ========================================
|
||||
``AutoField`` Not represented in the form
|
||||
|
||||
``BigIntegerField`` ``IntegerField`` with ``min_value`` set
|
||||
to -9223372036854775808 and ``max_value``
|
||||
set to 9223372036854775807.
|
||||
``BigIntegerField`` ``IntegerField`` with ``min_value`` set
|
||||
to -9223372036854775808 and ``max_value``
|
||||
set to 9223372036854775807.
|
||||
|
||||
``BooleanField`` ``BooleanField``
|
||||
``BooleanField`` ``BooleanField``
|
||||
|
||||
``CharField`` ``CharField`` with ``max_length`` set to
|
||||
the model field's ``max_length``
|
||||
``CharField`` ``CharField`` with ``max_length`` set to
|
||||
the model field's ``max_length``
|
||||
|
||||
``CommaSeparatedIntegerField`` ``CharField``
|
||||
``CommaSeparatedIntegerField`` ``CharField``
|
||||
|
||||
``DateField`` ``DateField``
|
||||
``DateField`` ``DateField``
|
||||
|
||||
``DateTimeField`` ``DateTimeField``
|
||||
``DateTimeField`` ``DateTimeField``
|
||||
|
||||
``DecimalField`` ``DecimalField``
|
||||
``DecimalField`` ``DecimalField``
|
||||
|
||||
``EmailField`` ``EmailField``
|
||||
``EmailField`` ``EmailField``
|
||||
|
||||
``FileField`` ``FileField``
|
||||
``FileField`` ``FileField``
|
||||
|
||||
``FilePathField`` ``CharField``
|
||||
``FilePathField`` ``CharField``
|
||||
|
||||
``FloatField`` ``FloatField``
|
||||
``FloatField`` ``FloatField``
|
||||
|
||||
``ForeignKey`` ``ModelChoiceField`` (see below)
|
||||
``ForeignKey`` ``ModelChoiceField`` (see below)
|
||||
|
||||
``ImageField`` ``ImageField``
|
||||
``ImageField`` ``ImageField``
|
||||
|
||||
``IntegerField`` ``IntegerField``
|
||||
``IntegerField`` ``IntegerField``
|
||||
|
||||
``IPAddressField`` ``IPAddressField``
|
||||
``IPAddressField`` ``IPAddressField``
|
||||
|
||||
``GenericIPAddressField`` ``GenericIPAddressField``
|
||||
``GenericIPAddressField`` ``GenericIPAddressField``
|
||||
|
||||
``ManyToManyField`` ``ModelMultipleChoiceField`` (see
|
||||
below)
|
||||
``ManyToManyField`` ``ModelMultipleChoiceField`` (see
|
||||
below)
|
||||
|
||||
``NullBooleanField`` ``CharField``
|
||||
``NullBooleanField`` ``CharField``
|
||||
|
||||
``PhoneNumberField`` ``USPhoneNumberField``
|
||||
(from ``django.contrib.localflavor.us``)
|
||||
``PhoneNumberField`` ``USPhoneNumberField``
|
||||
(from ``django.contrib.localflavor.us``)
|
||||
|
||||
``PositiveIntegerField`` ``IntegerField``
|
||||
``PositiveIntegerField`` ``IntegerField``
|
||||
|
||||
``PositiveSmallIntegerField`` ``IntegerField``
|
||||
``PositiveSmallIntegerField`` ``IntegerField``
|
||||
|
||||
``SlugField`` ``SlugField``
|
||||
``SlugField`` ``SlugField``
|
||||
|
||||
``SmallIntegerField`` ``IntegerField``
|
||||
``SmallIntegerField`` ``IntegerField``
|
||||
|
||||
``TextField`` ``CharField`` with
|
||||
``widget=forms.Textarea``
|
||||
``TextField`` ``CharField`` with
|
||||
``widget=forms.Textarea``
|
||||
|
||||
``TimeField`` ``TimeField``
|
||||
``TimeField`` ``TimeField``
|
||||
|
||||
``URLField`` ``URLField`` with ``verify_exists`` set
|
||||
to the model field's ``verify_exists``
|
||||
=============================== ========================================
|
||||
``URLField`` ``URLField`` with ``verify_exists`` set
|
||||
to the model field's ``verify_exists``
|
||||
=============================== ========================================
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``BigIntegerField`` is new in Django 1.2.
|
||||
|
|
@ -117,31 +117,31 @@ the full list of conversions:
|
|||
As you might expect, the ``ForeignKey`` and ``ManyToManyField`` model field
|
||||
types are special cases:
|
||||
|
||||
* ``ForeignKey`` is represented by ``django.forms.ModelChoiceField``,
|
||||
which is a ``ChoiceField`` whose choices are a model ``QuerySet``.
|
||||
* ``ForeignKey`` is represented by ``django.forms.ModelChoiceField``,
|
||||
which is a ``ChoiceField`` whose choices are a model ``QuerySet``.
|
||||
|
||||
* ``ManyToManyField`` is represented by
|
||||
``django.forms.ModelMultipleChoiceField``, which is a
|
||||
``MultipleChoiceField`` whose choices are a model ``QuerySet``.
|
||||
* ``ManyToManyField`` is represented by
|
||||
``django.forms.ModelMultipleChoiceField``, which is a
|
||||
``MultipleChoiceField`` whose choices are a model ``QuerySet``.
|
||||
|
||||
In addition, each generated form field has attributes set as follows:
|
||||
|
||||
* If the model field has ``blank=True``, then ``required`` is set to
|
||||
``False`` on the form field. Otherwise, ``required=True``.
|
||||
* If the model field has ``blank=True``, then ``required`` is set to
|
||||
``False`` on the form field. Otherwise, ``required=True``.
|
||||
|
||||
* The form field's ``label`` is set to the ``verbose_name`` of the model
|
||||
field, with the first character capitalized.
|
||||
* The form field's ``label`` is set to the ``verbose_name`` of the model
|
||||
field, with the first character capitalized.
|
||||
|
||||
* The form field's ``help_text`` is set to the ``help_text`` of the model
|
||||
field.
|
||||
* The form field's ``help_text`` is set to the ``help_text`` of the model
|
||||
field.
|
||||
|
||||
* If the model field has ``choices`` set, then the form field's ``widget``
|
||||
will be set to ``Select``, with choices coming from the model field's
|
||||
``choices``. The choices will normally include the blank choice which is
|
||||
selected by default. If the field is required, this forces the user to
|
||||
make a selection. The blank choice will not be included if the model
|
||||
field has ``blank=False`` and an explicit ``default`` value (the
|
||||
``default`` value will be initially selected instead).
|
||||
* If the model field has ``choices`` set, then the form field's ``widget``
|
||||
will be set to ``Select``, with choices coming from the model field's
|
||||
``choices``. The choices will normally include the blank choice which is
|
||||
selected by default. If the field is required, this forces the user to
|
||||
make a selection. The blank choice will not be included if the model
|
||||
field has ``blank=False`` and an explicit ``default`` value (the
|
||||
``default`` value will be initially selected instead).
|
||||
|
||||
Finally, note that you can override the form field used for a given model
|
||||
field. See `Overriding the default field types or widgets`_ below.
|
||||
|
|
@ -518,13 +518,13 @@ the original ``ArticleForm.Meta`` to remove one field.
|
|||
|
||||
There are a couple of things to note, however.
|
||||
|
||||
* Normal Python name resolution rules apply. If you have multiple base
|
||||
classes that declare a ``Meta`` inner class, only the first one will be
|
||||
used. This means the child's ``Meta``, if it exists, otherwise the
|
||||
``Meta`` of the first parent, etc.
|
||||
* Normal Python name resolution rules apply. If you have multiple base
|
||||
classes that declare a ``Meta`` inner class, only the first one will be
|
||||
used. This means the child's ``Meta``, if it exists, otherwise the
|
||||
``Meta`` of the first parent, etc.
|
||||
|
||||
* For technical reasons, a subclass cannot inherit from both a ``ModelForm``
|
||||
and a ``Form`` simultaneously.
|
||||
* For technical reasons, a subclass cannot inherit from both a ``ModelForm``
|
||||
and a ``Form`` simultaneously.
|
||||
|
||||
Chances are these notes won't affect you unless you're trying to do something
|
||||
tricky with subclassing.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue