[1.7.x] Light edits to docs/topics/forms/index.txt

server.

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

that pops up a date picker or allows you to move a slider or manipulate

controls will typically use JavaScript and CSS as well as HTML form ``<input>``

elements to achieve these effects.

simple and are built into HTML itself. Others are much more complex; an

interface that pops up a date picker or allows you to move a slider or

manipulate controls will typically use JavaScript and CSS as well as HTML form

``<input>`` elements to achieve these effects.

As well as its ``<input>`` elements, a form must specify two things:

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

bundles up the form data, encodes it for transmission, sends it back to the

server, and then receives its response.

bundles up the form data, encodes it for transmission, sends it to the server,

and then receives back its response.

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

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

* receiving and processing submitted forms and data from the client

:class:`FileField` handle very different kinds of data and have to do

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

:doc:`Widget class </ref/forms/widgets/>`, but these can be overridden as

required.

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

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

the user to populate it.

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,

you should be aware of what else is readily available in the forms system

and know a little bit about some of the underlying machinery.

you should be prepared to understand other features of the forms system and

ready to learn a bit more about the underlying machinery.

More about Django :class:`Form` classes

=======================================

        {{ form.cc_myself }}

    </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:

.. code-block:: html+django