From ec74dba2ab3f04fb828c0b926b49f63ec8486dd8 Mon Sep 17 00:00:00 2001 From: I am Clinton Date: Sat, 9 May 2015 22:18:56 -0500 Subject: [PATCH] Light edits to docs/topics/forms/index.txt --- docs/topics/forms/index.txt | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 360eced0fa..8133478e82 100644 --- a/docs/topics/forms/index.txt +++ b/docs/topics/forms/index.txt @@ -27,10 +27,10 @@ objects or controls, and so on, and then send that information back to the 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 ```` -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 +```` elements to achieve these effects. As well as its ```` 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. 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 @@ -102,7 +102,7 @@ do in code they wrote themselves. 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 @@ -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 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 `, but these can be overridden as 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. 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. @@ -364,8 +364,8 @@ by a view, and rendered as an HTML ``
``. 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 ======================================= @@ -560,7 +560,7 @@ in a Django template, will be rendered appropriately. For example: {{ form.cc_myself }} -Complete ``