Light edits to docs/topics/forms/index.txt
This commit is contained in:
parent
0d7a295f28
commit
ec74dba2ab
|
@ -27,10 +27,10 @@ objects or controls, and so on, and then send that information back to the
|
||||||
server.
|
server.
|
||||||
|
|
||||||
Some of these form interface elements - text input or checkboxes - are fairly
|
Some of these form interface elements - text input or checkboxes - are fairly
|
||||||
simple and built-in to HTML itself. Others are much more complex; an interface
|
simple and are built into HTML itself. Others are much more complex; an
|
||||||
that pops up a date picker or allows you to move a slider or manipulate
|
interface that pops up a date picker or allows you to move a slider or
|
||||||
controls will typically use JavaScript and CSS as well as HTML form ``<input>``
|
manipulate controls will typically use JavaScript and CSS as well as HTML form
|
||||||
elements to achieve these effects.
|
``<input>`` elements to achieve these effects.
|
||||||
|
|
||||||
As well as its ``<input>`` elements, a form must specify two things:
|
As well as its ``<input>`` elements, a form must specify two things:
|
||||||
|
|
||||||
|
@ -59,8 +59,8 @@ data is returned to ``/admin/``.
|
||||||
``GET`` and ``POST`` are the only HTTP methods to use when dealing with forms.
|
``GET`` and ``POST`` are the only HTTP methods to use when dealing with forms.
|
||||||
|
|
||||||
Django's login form is returned using the ``POST`` method, in which the browser
|
Django's login form is returned using the ``POST`` method, in which the browser
|
||||||
bundles up the form data, encodes it for transmission, sends it back to the
|
bundles up the form data, encodes it for transmission, sends it to the server,
|
||||||
server, and then receives its response.
|
and then receives back its response.
|
||||||
|
|
||||||
``GET``, by contrast, bundles the submitted data into a string, and uses this
|
``GET``, by contrast, bundles the submitted data into a string, and uses this
|
||||||
to compose a URL. The URL contains the address where the data must be sent, as
|
to compose a URL. The URL contains the address where the data must be sent, as
|
||||||
|
@ -102,7 +102,7 @@ do in code they wrote themselves.
|
||||||
|
|
||||||
Django handles three distinct parts of the work involved in forms:
|
Django handles three distinct parts of the work involved in forms:
|
||||||
|
|
||||||
* preparing and restructuring data ready for rendering
|
* preparing and restructuring data to make it ready for rendering
|
||||||
* creating HTML forms for the data
|
* creating HTML forms for the data
|
||||||
* receiving and processing submitted forms and data from the client
|
* receiving and processing submitted forms and data from the client
|
||||||
|
|
||||||
|
@ -138,7 +138,7 @@ validation when a form is submitted. A :class:`DateField` and a
|
||||||
:class:`FileField` handle very different kinds of data and have to do
|
:class:`FileField` handle very different kinds of data and have to do
|
||||||
different things with it.
|
different things with it.
|
||||||
|
|
||||||
A form field is represented to a user in the browser as a HTML "widget" - a
|
A form field is represented to a user in the browser as an HTML "widget" - a
|
||||||
piece of user interface machinery. Each field type has an appropriate default
|
piece of user interface machinery. Each field type has an appropriate default
|
||||||
:doc:`Widget class </ref/forms/widgets/>`, but these can be overridden as
|
:doc:`Widget class </ref/forms/widgets/>`, but these can be overridden as
|
||||||
required.
|
required.
|
||||||
|
@ -156,7 +156,7 @@ Rendering a form in a template involves nearly the same work as rendering any
|
||||||
other kind of object, but there are some key differences.
|
other kind of object, but there are some key differences.
|
||||||
|
|
||||||
In the case of a model instance that contained no data, it would rarely if ever
|
In the case of a model instance that contained no data, it would rarely if ever
|
||||||
be useful to do anything with one in a template. On the other hand, it makes
|
be useful to do anything with it in a template. On the other hand, it makes
|
||||||
perfect sense to render an unpopulated form - that's what we do when we want
|
perfect sense to render an unpopulated form - that's what we do when we want
|
||||||
the user to populate it.
|
the user to populate it.
|
||||||
|
|
||||||
|
@ -364,8 +364,8 @@ by a view, and rendered as an HTML ``<form>``.
|
||||||
|
|
||||||
That's all you need to get started, but the forms framework puts a lot more at
|
That's all you need to get started, but the forms framework puts a lot more at
|
||||||
your fingertips. Once you understand the basics of the process described above,
|
your fingertips. Once you understand the basics of the process described above,
|
||||||
you should be aware of what else is readily available in the forms system
|
you should be prepared to understand other features of the forms system and
|
||||||
and know a little bit about some of the underlying machinery.
|
ready to learn a bit more about the underlying machinery.
|
||||||
|
|
||||||
More about Django :class:`Form` classes
|
More about Django :class:`Form` classes
|
||||||
=======================================
|
=======================================
|
||||||
|
@ -560,7 +560,7 @@ in a Django template, will be rendered appropriately. For example:
|
||||||
{{ form.cc_myself }}
|
{{ form.cc_myself }}
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
Complete ``<label>`` element can also be generated using the
|
Complete ``<label>`` elements can also be generated using the
|
||||||
:meth:`~django.forms.BoundField.label_tag`. For example:
|
:meth:`~django.forms.BoundField.label_tag`. For example:
|
||||||
|
|
||||||
.. code-block:: html+django
|
.. code-block:: html+django
|
||||||
|
|
Loading…
Reference in New Issue