Django

Code

root/django/tags/releases/0.96/docs/newforms.txt

Revision 4804, 39.9 kB (checked in by ubernostrum, 2 years ago)

Remove notes about things added/removed in development version, since the development version is about to become 0.96

Line 
1 ====================
2 The newforms library
3 ====================
4
5 ``django.newforms`` is Django's fantastic new form-handling library. It's a
6 replacement for ``django.forms``, the old form/manipulator/validation
7 framework. This document explains how to use this new library.
8
9 Migration plan
10 ==============
11
12 ``django.newforms`` currently is only available in Django beginning
13 with the 0.96 release.  the Django development version -- i.e., it's
14 not available in the Django 0.95 release. For the next Django release,
15 our plan is to do the following:
16
17     * As of revision [4208], we've copied the current ``django.forms`` to
18       ``django.oldforms``. This allows you to upgrade your code *now* rather
19       than waiting for the backwards-incompatible change and rushing to fix
20       your code after the fact. Just change your import statements like this::
21
22           from django import forms             # old
23           from django import oldforms as forms # new
24
25     * At an undecided future date, we will move the current ``django.newforms``
26       to ``django.forms``. This will be a backwards-incompatible change, and
27       anybody who is still using the old version of ``django.forms`` at that
28       time will need to change their import statements, as described in the
29       previous bullet.
30
31     * We will remove ``django.oldforms`` in the release *after* the next Django
32       release -- the release that comes after the release in which we're
33       creating the new ``django.forms``.
34
35 With this in mind, we recommend you use the following import statement when
36 using ``django.newforms``::
37
38     from django import newforms as forms
39
40 This way, your code can refer to the ``forms`` module, and when
41 ``django.newforms`` is renamed to ``django.forms``, you'll only have to change
42 your ``import`` statements.
43
44 If you prefer "``import *``" syntax, you can do the following::
45
46     from django.newforms import *
47
48 This will import all fields, widgets, form classes and other various utilities
49 into your local namespace. Some people find this convenient; others find it
50 too messy. The choice is yours.
51
52 Overview
53 ========
54
55 As with the ``django.forms`` ("manipulators") system before it,
56 ``django.newforms`` is intended to handle HTML form display, data processing
57 (validation) and redisplay. It's what you use if you want to perform
58 server-side validation for an HTML form.
59
60 For example, if your Web site has a contact form that visitors can use to
61 send you e-mail, you'd use this library to implement the display of the HTML
62 form fields, along with the form validation. Any time you need to use an HTML
63 ``<form>``, you can use this library.
64
65 The library deals with these concepts:
66
67     * **Widget** -- A class that corresponds to an HTML form widget, e.g.
68       ``<input type="text">`` or ``<textarea>``. This handles rendering of the
69       widget as HTML.
70
71     * **Field** -- A class that is responsible for doing validation, e.g.
72       an ``EmailField`` that makes sure its data is a valid e-mail address.
73
74     * **Form** -- A collection of fields that knows how to validate itself and
75       display itself as HTML.
76
77 The library is decoupled from the other Django components, such as the database
78 layer, views and templates. It relies only on Django settings, a couple of
79 ``django.utils`` helper functions and Django's internationalization hooks (but
80 you're not required to be using internationalization features to use this
81 library).
82
83 Form objects
84 ============
85
86 The primary way of using the ``newforms`` library is to create a form object.
87 Do this by subclassing ``django.newforms.Form`` and specifying the form's
88 fields, in a declarative style that you'll be familiar with if you've used
89 Django database models. In this section, we'll iteratively develop a form
90 object that you might use to implement "contact me" functionality on your
91 personal Web site.
92
93 Start with this basic ``Form`` subclass, which we'll call ``ContactForm``::
94
95     from django import newforms as forms
96
97     class ContactForm(forms.Form):
98         subject = forms.CharField(max_length=100)
99         message = forms.CharField()
100         sender = forms.EmailField()
101         cc_myself = forms.BooleanField()
102
103 A form is composed of ``Field`` objects. In this case, our form has four
104 fields: ``subject``, ``message``, ``sender`` and ``cc_myself``. We'll explain
105 the different types of fields -- e.g., ``CharField`` and ``EmailField`` --
106 shortly.
107
108 Creating ``Form`` instances
109 ---------------------------
110
111 A ``Form`` instance is either **bound** or **unbound** to a set of data.
112
113     * If it's **bound** to a set of data, it's capable of validating that data
114       and rendering the form as HTML with the data displayed in the HTML.
115
116     * If it's **unbound**, it cannot do validation (because there's no data to
117       validate!), but it can still render the blank form as HTML.
118
119 To create an unbound ``Form`` instance, simply instantiate the class::
120
121     >>> f = ContactForm()
122
123 To bind data to a form, pass the data as a dictionary as the first parameter to
124 your ``Form`` class constructor::
125
126     >>> data = {'subject': 'hello',
127     ...         'message': 'Hi there',
128     ...         'sender': 'foo@example.com',
129     ...         'cc_myself': True}
130     >>> f = ContactForm(data)
131
132 In this dictionary, the keys are the field names, which correspond to the
133 attributes in your ``Form`` class. The values are the data you're trying
134 to validate. These will usually be strings, but there's no requirement that
135 they be strings; the type of data you pass depends on the ``Field``, as we'll
136 see in a moment.
137
138 If you need to distinguish between bound and unbound form instances at runtime,
139 check the value of the form's ``is_bound`` attribute::
140
141     >>> f = ContactForm()
142     >>> f.is_bound
143     False
144     >>> f = ContactForm({'subject': 'hello'})
145     >>> f.is_bound
146     True
147
148 Note that passing an empty dictionary creates a *bound* form with empty data::
149
150     >>> f = ContactForm({})
151     >>> f.is_bound
152     True
153
154 If you have a bound ``Form`` instance and want to change the data somehow, or
155 if you want to bind an unbound ``Form`` instance to some data, create another
156 ``Form`` instance. There is no way to change data in a ``Form`` instance. Once
157 a ``Form`` instance has been created, you should consider its data immutable,
158 whether it has data or not.
159
160 Using forms to validate data
161 ----------------------------
162
163 The primary task of a ``Form`` object is to validate data. With a bound
164 ``Form`` instance, call the ``is_valid()`` method to run validation and return
165 a boolean designating whether the data was valid::
166
167     >>> data = {'subject': 'hello',
168     ...         'message': 'Hi there',
169     ...         'sender': 'foo@example.com',
170     ...         'cc_myself': True}
171     >>> f = ContactForm(data)
172     >>> f.is_valid()
173     True
174
175 Let's try with some invalid data. In this case, ``subject`` is blank (an error,
176 because all fields are required by default) and ``sender`` is not a valid
177 e-mail address::
178
179     >>> data = {'subject': '',
180     ...         'message': 'Hi there',
181     ...         'sender': 'invalid e-mail address',
182     ...         'cc_myself': True}
183     >>> f = ContactForm(data)
184     >>> f.is_valid()
185     False
186
187 Access the ``Form`` attribute ``errors`` to get a dictionary of error messages::
188
189     >>> f.errors
190     {'sender': [u'Enter a valid e-mail address.'], 'subject': [u'This field is required.']}
191
192 In this dictionary, the keys are the field names, and the values are lists of
193 Unicode strings representing the error messages. The error messages are stored
194 in lists because a field can have multiple error messages.
195
196 You can access ``errors`` without having to call ``is_valid()`` first. The
197 form's data will be validated the first time either you call ``is_valid()`` or
198 access ``errors``.
199
200 Behavior of unbound forms
201 ~~~~~~~~~~~~~~~~~~~~~~~~~
202
203 It's meaningless to validate a form with no data, but, for the record, here's
204 what happens with unbound forms::
205
206     >>> f = ContactForm()
207     >>> f.is_valid()
208     False
209     >>> f.errors
210     {}
211
212 Accessing "clean" data
213 ----------------------
214
215 Each ``Field`` in a ``Form`` class is responsible not only for validating data,
216 but also for "cleaning" it -- normalizing it to a consistent format. This is a
217 nice feature, because it allows data for a particular field to be input in
218 a variety of ways, always resulting in consistent output.
219
220 For example, ``DateField`` normalizes input into a Python ``datetime.date``
221 object. Regardless of whether you pass it a string in the format
222 ``'1994-07-15'``, a ``datetime.date`` object or a number of other formats,
223 ``DateField`` will always normalize it to a ``datetime.date`` object as long as
224 it's valid.
225
226 Once you've created a ``Form`` instance with a set of data and validated it,
227 you can access the clean data via the ``clean_data`` attribute of the ``Form``
228 object::
229
230     >>> data = {'subject': 'hello',
231     ...         'message': 'Hi there',
232     ...         'sender': 'foo@example.com',
233     ...         'cc_myself': True}
234     >>> f = ContactForm(data)
235     >>> f.is_valid()
236     True
237     >>> f.clean_data
238     {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
239
240 Note that any text-based field -- such as ``CharField`` or ``EmailField`` --
241 always cleans the input into a Unicode string. We'll cover the encoding
242 implications later in this document.
243
244 If your data does *not* validate, your ``Form`` instance will not have a
245 ``clean_data`` attribute::
246
247     >>> data = {'subject': '',
248     ...         'message': 'Hi there',
249     ...         'sender': 'invalid e-mail address',
250     ...         'cc_myself': True}
251     >>> f = ContactForm(data)
252     >>> f.is_valid()
253     False
254     >>> f.clean_data
255     Traceback (most recent call last):
256     ...
257     AttributeError: 'ContactForm' object has no attribute 'clean_data'
258
259 ``clean_data`` will always *only* contain a key for fields defined in the
260 ``Form``, even if you pass extra data when you define the ``Form``. In this
261 example, we pass a bunch of extra fields to the ``ContactForm`` constructor,
262 but ``clean_data`` contains only the form's fields::
263
264     >>> data = {'subject': 'hello',
265     ...         'message': 'Hi there',
266     ...         'sender': 'foo@example.com',
267     ...         'cc_myself': True,
268     ...         'extra_field_1': 'foo',
269     ...         'extra_field_2': 'bar',
270     ...         'extra_field_3': 'baz'}
271     >>> f = ContactForm(data)
272     >>> f.is_valid()
273     True
274     >>> f.clean_data # Doesn't contain extra_field_1, etc.
275     {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
276
277 Behavior of unbound forms
278 ~~~~~~~~~~~~~~~~~~~~~~~~~
279
280 It's meaningless to request "clean" data in a form with no data, but, for the
281 record, here's what happens with unbound forms::
282
283     >>> f = ContactForm()
284     >>> f.clean_data
285     Traceback (most recent call last):
286     ...
287     AttributeError: 'ContactForm' object has no attribute 'clean_data'
288
289 Outputting forms as HTML
290 ------------------------
291
292 The second task of a ``Form`` object is to render itself as HTML. To do so,
293 simply ``print`` it::
294
295     >>> f = ContactForm()
296     >>> print f
297     <tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" /></td></tr>
298     <tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" /></td></tr>
299     <tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" /></td></tr>
300     <tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" /></td></tr>
301
302 If the form is bound to data, the HTML output will include that data
303 appropriately. For example, if a field is represented by an
304 ``<input type="text">``, the data will be in the ``value`` attribute. If a
305 field is represented by an ``<input type="checkbox">``, then that HTML will
306 include ``checked="checked"`` if appropriate::
307
308     >>> data = {'subject': 'hello',
309     ...         'message': 'Hi there',
310     ...         'sender': 'foo@example.com',
311     ...         'cc_myself': True}
312     >>> f = ContactForm(data)
313     >>> print f
314     <tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" value="hello" /></td></tr>
315     <tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" value="Hi there" /></td></tr>
316     <tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" value="foo@example.com" /></td></tr>
317     <tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" checked="checked" /></td></tr>
318
319 This default output is a two-column HTML table, with a ``<tr>`` for each field.
320 Notice the following:
321
322     * For flexibility, the output does *not* include the ``<table>`` and
323       ``</table>`` tags, nor does it include the ``<form>`` and ``</form>``
324       tags or an ``<input type="submit">`` tag. It's your job to do that.
325
326     * Each field type has a default HTML representation. ``CharField`` and
327       ``EmailField`` are represented by an ``<input type="text">``.
328       ``BooleanField`` is represented by an ``<input type="checkbox">``. Note
329       these are merely sensible defaults; you can specify which HTML to use for
330       a given field by using widgets, which we'll explain shortly.
331
332     * The HTML ``name`` for each tag is taken directly from its attribute name
333       in the ``ContactForm`` class.
334
335     * The text label for each field -- e.g. ``'Subject:'``, ``'Message:'`` and
336       ``'Cc myself:'`` is generated from the field name by converting all
337       underscores to spaces and upper-casing the first letter. Again, note
338       these are merely sensible defaults; you can also specify labels manually.
339
340     * Each text label is surrounded in an HTML ``<label>`` tag, which points
341       to the appropriate form field via its ``id``. Its ``id``, in turn, is
342       generated by prepending ``'id_'`` to the field name. The ``id``
343       attributes and ``<label>`` tags are included in the output by default, to
344       follow best practices, but you can change that behavior.
345
346 Although ``<table>`` output is the default output style when you ``print`` a
347 form, other output styles are available. Each style is available as a method on
348 a form object, and each rendering method returns a Unicode object.
349
350 ``as_p()``
351 ~~~~~~~~~~
352
353 ``Form.as_p()`` renders the form as a series of ``<p>`` tags, with each ``<p>``
354 containing one field::
355
356     >>> f = ContactForm()
357     >>> f.as_p()
358     u'<p><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></p>\n<p><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></p>\n<p><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></p>\n<p><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></p>'
359     >>> print f.as_p()
360     <p><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></p>
361     <p><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></p>
362     <p><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></p>
363     <p><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></p>
364
365 ``as_ul()``
366 ~~~~~~~~~~~
367
368 ``Form.as_ul()`` renders the form as a series of ``<li>`` tags, with each
369 ``<li>`` containing one field. It does *not* include the ``<ul>`` or ``</ul>``,
370 so that you can specify any HTML attributes on the ``<ul>`` for flexibility::
371
372     >>> f = ContactForm()
373     >>> f.as_ul()
374     u'<li><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></li>\n<li><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></li>\n<li><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></li>\n<li><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></li>'
375     >>> print f.as_ul()
376     <li><label for="id_subject">Subject:</label> <input id="id_subject" type="text" name="subject" maxlength="100" /></li>
377     <li><label for="id_message">Message:</label> <input type="text" name="message" id="id_message" /></li>
378     <li><label for="id_sender">Sender:</label> <input type="text" name="sender" id="id_sender" /></li>
379     <li><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></li>
380
381 ``as_table()``
382 ~~~~~~~~~~~~~~
383
384 Finally, ``Form.as_table()`` outputs the form as an HTML ``<table>``. This is
385 exactly the same as ``print``. In fact, when you ``print`` a form object, it
386 calls its ``as_table()`` method behind the scenes::
387
388     >>> f = ContactForm()
389     >>> f.as_table()
390     u'<tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" /></td></tr>\n<tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" /></td></tr>\n<tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" /></td></tr>\n<tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" /></td></tr>'
391     >>> print f.as_table()
392     <tr><th><label for="id_subject">Subject:</label></th><td><input id="id_subject" type="text" name="subject" maxlength="100" /></td></tr>
393     <tr><th><label for="id_message">Message:</label></th><td><input type="text" name="message" id="id_message" /></td></tr>
394     <tr><th><label for="id_sender">Sender:</label></th><td><input type="text" name="sender" id="id_sender" /></td></tr>
395     <tr><th><label for="id_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_cc_myself" /></td></tr>
396
397 Configuring HTML ``<label>`` tags
398 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
399
400 An HTML ``<label>`` tag designates which label text is associated with which
401 form element. This small enhancement makes forms more usable and more accessible
402 to assistive devices. It's always a good idea to use ``<label>`` tags.
403
404 By default, the form rendering methods include HTML ``id`` attributes on the
405 form elements and corresponding ``<label>`` tags around the labels. The ``id``
406 attribute values are generated by prepending ``id_`` to the form field names.
407 This behavior is configurable, though, if you want to change the ``id``
408 convention or remove HTML ``id`` attributes and ``<label>`` tags entirely.
409
410 Use the ``auto_id`` argument to the ``Form`` constructor to control the label
411 and ``id`` behavior. This argument must be ``True``, ``False`` or a string.
412
413 If ``auto_id`` is ``False``, then the form output will not include ``<label>``
414 tags nor ``id`` attributes::
415
416     >>> f = ContactForm(auto_id=False)
417     >>> print f.as_table()
418     <tr><th>Subject:</th><td><input type="text" name="subject" maxlength="100" /></td></tr>
419     <tr><th>Message:</th><td><input type="text" name="message" /></td></tr>
420     <tr><th>Sender:</th><td><input type="text" name="sender" /></td></tr>
421     <tr><th>Cc myself:</th><td><input type="checkbox" name="cc_myself" /></td></tr>
422     >>> print f.as_ul()
423     <li>Subject: <input type="text" name="subject" maxlength="100" /></li>
424     <li>Message: <input type="text" name="message" /></li>
425     <li>Sender: <input type="text" name="sender" /></li>
426     <li>Cc myself: <input type="checkbox" name="cc_myself" /></li>
427     >>> print f.as_p()
428     <p>Subject: <input type="text" name="subject" maxlength="100" /></p>
429     <p>Message: <input type="text" name="message" /></p>
430     <p>Sender: <input type="text" name="sender" /></p>
431     <p>Cc myself: <input type="checkbox" name="cc_myself" /></p>
432
433 If ``auto_id`` is set to ``True``, then the form output *will* include
434 ``<label>`` tags and will simply use the field name as its ``id`` for each form
435 field::
436
437     >>> f = ContactForm(auto_id=True)
438     >>> print f.as_table()
439     <tr><th><label for="subject">Subject:</label></th><td><input id="subject" type="text" name="subject" maxlength="100" /></td></tr>
440     <tr><th><label for="message">Message:</label></th><td><input type="text" name="message" id="message" /></td></tr>
441     <tr><th><label for="sender">Sender:</label></th><td><input type="text" name="sender" id="sender" /></td></tr>
442     <tr><th><label for="cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="cc_myself" /></td></tr>
443     >>> print f.as_ul()
444     <li><label for="subject">Subject:</label> <input id="subject" type="text" name="subject" maxlength="100" /></li>
445     <li><label for="message">Message:</label> <input type="text" name="message" id="message" /></li>
446     <li><label for="sender">Sender:</label> <input type="text" name="sender" id="sender" /></li>
447     <li><label for="cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="cc_myself" /></li>
448     >>> print f.as_p()
449     <p><label for="subject">Subject:</label> <input id="subject" type="text" name="subject" maxlength="100" /></p>
450     <p><label for="message">Message:</label> <input type="text" name="message" id="message" /></p>
451     <p><label for="sender">Sender:</label> <input type="text" name="sender" id="sender" /></p>
452     <p><label for="cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="cc_myself" /></p>
453
454 If ``auto_id`` is set to a string containing the format character ``'%s'``,
455 then the form output will include ``<label>`` tags, and will generate ``id``
456 attributes based on the format string. For example, for a format string
457 ``'field_%s'``, a field named ``subject`` will get the ``id``
458 ``'field_subject'``. Continuing our example::
459
460     >>> f = ContactForm(auto_id='id_for_%s')
461     >>> print f.as_table()
462     <tr><th><label for="id_for_subject">Subject:</label></th><td><input id="id_for_subject" type="text" name="subject" maxlength="100" /></td></tr>
463     <tr><th><label for="id_for_message">Message:</label></th><td><input type="text" name="message" id="id_for_message" /></td></tr>
464     <tr><th><label for="id_for_sender">Sender:</label></th><td><input type="text" name="sender" id="id_for_sender" /></td></tr>
465     <tr><th><label for="id_for_cc_myself">Cc myself:</label></th><td><input type="checkbox" name="cc_myself" id="id_for_cc_myself" /></td></tr>
466     >>> print f.as_ul()
467     <li><label for="id_for_subject">Subject:</label> <input id="id_for_subject" type="text" name="subject" maxlength="100" /></li>
468     <li><label for="id_for_message">Message:</label> <input type="text" name="message" id="id_for_message" /></li>
469     <li><label for="id_for_sender">Sender:</label> <input type="text" name="sender" id="id_for_sender" /></li>
470     <li><label for="id_for_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_for_cc_myself" /></li>
471     >>> print f.as_p()
472     <p><label for="id_for_subject">Subject:</label> <input id="id_for_subject" type="text" name="subject" maxlength="100" /></p>
473     <p><label for="id_for_message">Message:</label> <input type="text" name="message" id="id_for_message" /></p>
474     <p><label for="id_for_sender">Sender:</label> <input type="text" name="sender" id="id_for_sender" /></p>
475     <p><label for="id_for_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_for_cc_myself" /></p>
476
477 If ``auto_id`` is set to any other true value -- such as a string that doesn't
478 include ``%s`` -- then the library will act as if ``auto_id`` is ``True``.
479
480 By default, ``auto_id`` is set to the string ``'id_%s'``.
481
482 Notes on field ordering
483 ~~~~~~~~~~~~~~~~~~~~~~~
484
485 In the ``as_p()``, ``as_ul()`` and ``as_table()`` shortcuts, the fields are
486 displayed in the order in which you define them in your form class. For
487 example, in the ``ContactForm`` example, the fields are defined in the order
488 ``subject``, ``message``, ``sender``, ``cc_myself``. To reorder the HTML
489 output, just change the order in which those fields are listed in the class.
490
491 How errors are displayed
492 ~~~~~~~~~~~~~~~~~~~~~~~~
493
494 If you render a bound ``Form`` object, the act of rendering will automatically
495 run the form's validation if it hasn't already happened, and the HTML output
496 will include the validation errors as a ``<ul>`` near the field. The particular
497 positioning of the error messages depends on the output method you're using::
498
499     >>> data = {'subject': '',
500     ...         'message': 'Hi there',
501     ...         'sender': 'invalid e-mail address',
502     ...         'cc_myself': True}
503     >>> f = ContactForm(data, auto_id=False)
504     >>> print f.as_table()
505     <tr><th>Subject:</th><td><ul class="errorlist"><li>This field is required.</li></ul><input type="text" name="subject" maxlength="100" /></td></tr>
506     <tr><th>Message:</th><td><input type="text" name="message" value="Hi there" /></td></tr>
507     <tr><th>Sender:</th><td><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul><input type="text" name="sender" value="invalid e-mail address" /></td></tr>
508     <tr><th>Cc myself:</th><td><input checked="checked" type="checkbox" name="cc_myself" /></td></tr>
509     >>> print f.as_ul()
510     <li><ul class="errorlist"><li>This field is required.</li></ul>Subject: <input type="text" name="subject" maxlength="100" /></li>
511     <li>Message: <input type="text" name="message" value="Hi there" /></li>
512     <li><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul>Sender: <input type="text" name="sender" value="invalid e-mail address" /></li>
513     <li>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></li>
514     >>> print f.as_p()
515     <p><ul class="errorlist"><li>This field is required.</li></ul></p>
516     <p>Subject: <input type="text" name="subject" maxlength="100" /></p>
517     <p>Message: <input type="text" name="message" value="Hi there" /></p>
518     <p><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul></p>
519     <p>Sender: <input type="text" name="sender" value="invalid e-mail address" /></p>
520     <p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
521
522 More granular output
523 ~~~~~~~~~~~~~~~~~~~~
524
525 The ``as_p()``, ``as_ul()`` and ``as_table()`` methods are simply shortcuts for
526 lazy developers -- they're not the only way a form object can be displayed.
527
528 To display the HTML for a single field in your form, use dictionary lookup
529 syntax using the field's name as the key, and print the resulting object::
530
531     >>> f = ContactForm()
532     >>> print f['subject']
533     <input id="id_subject" type="text" name="subject" maxlength="100" />
534     >>> print f['message']
535     <input type="text" name="message" id="id_message" />
536     >>> print f['sender']
537     <input type="text" name="sender" id="id_sender" />
538     >>> print f['cc_myself']
539     <input type="checkbox" name="cc_myself" id="id_cc_myself" />
540
541 Call ``str()`` or ``unicode()`` on the field to get its rendered HTML as a
542 string or Unicode object, respectively::
543
544     >>> str(f['subject'])
545     '<input id="id_subject" type="text" name="subject" maxlength="100" />'
546     >>> unicode(f['subject'])
547     u'<input id="id_subject" type="text" name="subject" maxlength="100" />'
548
549 The field-specific output honors the form object's ``auto_id`` setting::
550
551     >>> f = ContactForm(auto_id=False)
552     >>> print f['message']
553     <input type="text" name="message" />
554     >>> f = ContactForm(auto_id='id_%s')
555     >>> print f['message']
556     <input type="text" name="message" id="id_message" />
557
558 For a field's list of errors, access the field's ``errors`` attribute. This
559 is a list-like object that is displayed as an HTML ``<ul>`` when printed::
560
561     >>> data = {'subject': 'hi', 'message': '', 'sender': '', 'cc_myself': ''}
562     >>> f = ContactForm(data, auto_id=False)
563     >>> print f['message']
564     <input type="text" name="message" />
565     >>> f['message'].errors
566     [u'This field is required.']
567     >>> print f['message'].errors
568     <ul class="errorlist"><li>This field is required.</li></ul>
569     >>> f['subject'].errors
570     []
571     >>> print f['subject'].errors
572
573     >>> str(f['subject'].errors)
574     ''
575
576 Subclassing forms
577 -----------------
578
579 If you subclass a custom ``Form`` class, the resulting ``Form`` class will
580 include all fields of the parent class(es), followed by the fields you define
581 in the subclass.
582
583 In this example, ``ContactFormWithPriority`` contains all the fields from
584 ``ContactForm``, plus an additional field, ``priority``. The ``ContactForm``
585 fields are ordered first::
586
587     >>> class ContactFormWithPriority(ContactForm):
588     ...     priority = forms.CharField()
589     >>> f = ContactFormWithPriority(auto_id=False)
590     >>> print f.as_ul()
591     <li>Subject: <input type="text" name="subject" maxlength="100" /></li>
592     <li>Message: <input type="text" name="message" /></li>
593     <li>Sender: <input type="text" name="sender" /></li>
594     <li>Cc myself: <input type="checkbox" name="cc_myself" /></li>
595     <li>Priority: <input type="text" name="priority" /></li>
596
597 It's possible to subclass multiple forms, treating forms as "mix-ins." In this
598 example, ``BeatleForm`` subclasses both ``PersonForm`` and ``InstrumentForm``
599 (in that order), and its field list includes the fields from the parent
600 classes::
601
602     >>> class PersonForm(Form):
603     ...     first_name = CharField()
604     ...     last_name = CharField()
605     >>> class InstrumentForm(Form):
606     ...     instrument = CharField()
607     >>> class BeatleForm(PersonForm, InstrumentForm):
608     ...     haircut_type = CharField()
609     >>> b = BeatleForm(auto_id=False)
610     >>> print b.as_ul()
611     <li>First name: <input type="text" name="first_name" /></li>
612     <li>Last name: <input type="text" name="last_name" /></li>
613     <li>Instrument: <input type="text" name="instrument" /></li>
614     <li>Haircut type: <input type="text" name="haircut_type" /></li>
615
616 Fields
617 ======
618
619 When you create a ``Form`` class, the most important part is defining the
620 fields of the form. Each field has custom validation logic, along with a few
621 other hooks.
622
623 Although the primary way you'll use ``Field`` classes is in ``Form`` classes,
624 you can also instantiate them and use them directly to get a better idea of
625 how they work. Each ``Field`` instance has a ``clean()`` method, which takes
626 a single argument and either raises a ``django.newforms.ValidationError``
627 exception or returns the clean value::
628
629     >>> f = forms.EmailField()
630     >>> f.clean('foo@example.com')
631     u'foo@example.com'
632     >>> f.clean(u'foo@example.com')
633     u'foo@example.com'
634     >>> f.clean('invalid e-mail address')
635     Traceback (most recent call last):
636     ...
637     ValidationError: [u'Enter a valid e-mail address.']
638
639 If you've used Django's old forms/validation framework, take care in noticing
640 this ``ValidationError`` is different than the previous ``ValidationError``.
641 This one lives at ``django.newforms.ValidationError`` rather than
642 ``django.core.validators.ValidationError``.
643
644 Core field arguments
645 --------------------
646
647 Each ``Field`` class constructor takes at least these arguments. Some
648 ``Field`` classes take additional, field-specific arguments, but the following
649 should *always* be available:
650
651 ``required``
652 ~~~~~~~~~~~~
653
654 By default, each ``Field`` class assumes the value is required, so if you pass
655 an empty value -- either ``None`` or the empty string (``""``) -- then
656 ``clean()`` will raise a ``ValidationError`` exception::
657
658     >>> f = forms.CharField()
659     >>> f.clean('foo')
660     u'foo'
661     >>> f.clean('')
662     Traceback (most recent call last):
663     ...
664     ValidationError: [u'This field is required.']
665     >>> f.clean(None)
666     Traceback (most recent call last):
667     ...
668     ValidationError: [u'This field is required.']
669     >>> f.clean(' ')
670     u' '
671     >>> f.clean(0)
672     u'0'
673     >>> f.clean(True)
674     u'True'
675     >>> f.clean(False)
676     u'False'
677
678 To specify that a field is *not* required, pass ``required=False`` to the
679 ``Field`` constructor::
680
681     >>> f = forms.CharField(required=False)
682     >>> f.clean('foo')
683     u'foo'
684     >>> f.clean('')
685     u''
686     >>> f.clean(None)
687     u''
688     >>> f.clean(0)
689     u'0'
690     >>> f.clean(True)
691     u'True'
692     >>> f.clean(False)
693     u'False'
694
695 If a ``Field`` has ``required=False`` and you pass ``clean()`` an empty value,
696 then ``clean()`` will return a *normalized* empty value rather than raising
697 ``ValidationError``. For ``CharField``, this will be a Unicode empty string.
698 For other ``Field`` classes, it might be ``None``. (This varies from field to
699 field.)
700
701 ``label``
702 ~~~~~~~~~
703
704 The ``label`` argument lets you specify the "human-friendly" label for this
705 field. This is used when the ``Field`` is displayed in a ``Form``.
706
707 As explained in _`Outputting forms as HTML` above, the default label for a
708 ``Field`` is generated from the field name by converting all underscores to
709 spaces and upper-casing the first letter. Specify ``label`` if that default
710 behavior doesn't result in an adequate label.
711
712 Here's a full example ``Form`` that implements ``label`` for two of its fields.
713 We've specified ``auto_id=False`` to simplify the output::
714
715     >>> class CommentForm(forms.Form):
716     ...     name = forms.CharField(label='Your name')
717     ...     url = forms.URLField(label='Your Web site', required=False)
718     ...     comment = forms.CharField()
719     >>> f = CommentForm(auto_id=False)
720     >>> print f
721     <tr><th>Your name:</th><td><input type="text" name="name" /></td></tr>
722     <tr><th>Your Web site:</th><td><input type="text" name="url" /></td></tr>
723     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
724
725 ``initial``
726 ~~~~~~~~~~~
727
728 The ``initial`` argument lets you specify the initial value to use when
729 rendering this ``Field`` in an unbound ``Form``.
730
731 The use-case for this is when you want to display an "empty" form in which a
732 field is initialized to a particular value. For example::
733
734     >>> class CommentForm(forms.Form):
735     ...     name = forms.CharField(initial='Your name')
736     ...     url = forms.URLField(initial='http://')
737     ...     comment = forms.CharField()
738     >>> f = CommentForm(auto_id=False)
739     >>> print f
740     <tr><th>Name:</th><td><input type="text" name="name" value="Your name" /></td></tr>
741     <tr><th>Url:</th><td><input type="text" name="url" value="http://" /></td></tr>
742     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
743
744 You may be thinking, why not just pass a dictionary of the initial values as
745 data when displaying the form? Well, if you do that, you'll trigger validation,
746 and the HTML output will include any validation errors::
747
748     >>> class CommentForm(forms.Form):
749     ...     name = forms.CharField()
750     ...     url = forms.URLField()
751     ...     comment = forms.CharField()
752     >>> default_data = {'name': 'Your name', 'url': 'http://'}
753     >>> f = CommentForm(default_data, auto_id=False)
754     >>> print f
755     <tr><th>Name:</th><td><input type="text" name="name" value="Your name" /></td></tr>
756     <tr><th>Url:</th><td><ul class="errorlist"><li>Enter a valid URL.</li></ul><input type="text" name="url" value="http://" /></td></tr>
757     <tr><th>Comment:</th><td><ul class="errorlist"><li>This field is required.</li></ul><input type="text" name="comment" /></td></tr>
758
759 This is why ``initial`` values are only displayed for unbound forms. For bound
760 forms, the HTML output will use the bound data.
761
762 Also note that ``initial`` values are *not* used as "fallback" data in
763 validation if a particular field's value is not given. ``initial`` values are
764 *only* intended for initial form display::
765
766     >>> class CommentForm(forms.Form):
767     ...     name = forms.CharField(initial='Your name')
768     ...     url = forms.URLField(initial='http://')
769     ...     comment = forms.CharField()
770     >>> data = {'name': '', 'url': '', 'comment': 'Foo'}
771     >>> f = CommentForm(data)
772     >>> f.is_valid()
773     False
774     # The form does *not* fall back to using the initial values.
775     >>> f.errors
776     {'url': [u'This field is required.'], 'name': [u'This field is required.']}
777
778 ``widget``
779 ~~~~~~~~~~
780
781 The ``widget`` argument lets you specify a ``Widget`` class to use when
782 rendering this ``Field``. See _`Widgets` below for more information.
783
784 ``help_text``
785 ~~~~~~~~~~~~~
786
787 The ``help_text`` argument lets you specify descriptive text for this
788 ``Field``. If you provide ``help_text``, it will be displayed next to the
789 ``Field`` when the ``Field`` is rendered in a ``Form``.
790
791 Here's a full example ``Form`` that implements ``help_text`` for two of its
792 fields. We've specified ``auto_id=False`` to simplify the output::
793
794     >>> class HelpTextContactForm(forms.Form):
795     ...     subject = forms.CharField(max_length=100, help_text='100 characters max.')
796     ...     message = forms.CharField()
797     ...     sender = forms.EmailField(help_text='A valid e-mail address, please.')
798     ...     cc_myself = forms.BooleanField()
799     >>> f = HelpTextContactForm(auto_id=False)
800     >>> print f.as_table()
801     <tr><th>Subject:</th><td><input type="text" name="subject" maxlength="100" /><br />100 characters max.</td></tr>
802     <tr><th>Message:</th><td><input type="text" name="message" /></td></tr>
803     <tr><th>Sender:</th><td><input type="text" name="sender" /><br />A valid e-mail address, please.</td></tr>
804     <tr><th>Cc myself:</th><td><input type="checkbox" name="cc_myself" /></td></tr>
805     >>> print f.as_ul()
806     <li>Subject: <input type="text" name="subject" maxlength="100" /> 100 characters max.</li>
807     <li>Message: <input type="text" name="message" /></li>
808     <li>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</li>
809     <li>Cc myself: <input type="checkbox" name="cc_myself" /></li>
810     >>> print f.as_p()
811     <p>Subject: <input type="text" name="subject" maxlength="100" /> 100 characters max.</p>
812     <p>Message: <input type="text" name="message" /></p>
813     <p>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</p>
814     <p>Cc myself: <input type="checkbox" name="cc_myself" /></p>
815
816 Dynamic initial values
817 ----------------------
818
819 The ``initial`` argument to ``Field`` (explained above) lets you hard-code the
820 initial value for a ``Field`` -- but what if you want to declare the initial
821 value at runtime? For example, you might want to fill in a ``username`` field
822 with the username of the current session.
823
824 To accomplish this, use the ``initial`` argument to a ``Form``. This argument,
825 if given, should be a dictionary mapping field names to initial values. Only
826 include the fields for which you're specifying an initial value; it's not
827 necessary to include every field in your form. For example::
828
829     >>> class CommentForm(forms.Form):
830     ...     name = forms.CharField()
831     ...     url = forms.URLField()
832     ...     comment = forms.CharField()
833     >>> f = CommentForm(initial={'name': 'your username'}, auto_id=False)
834     >>> print f
835     <tr><th>Name:</th><td><input type="text" name="name" value="your username" /></td></tr>
836     <tr><th>Url:</th><td><input type="text" name="url" /></td></tr>
837     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
838     >>> f = CommentForm(initial={'name': 'another username'}, auto_id=False)
839     >>> print f
840     <tr><th>Name:</th><td><input type="text" name="name" value="another username" /></td></tr>
841     <tr><th>Url:</th><td><input type="text" name="url" /></td></tr>
842     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
843
844 Just like the ``initial`` parameter to ``Field``, these values are only
845 displayed for unbound forms, and they're not used as fallback values if a
846 particular value isn't provided.
847
848 Finally, note that if a ``Field`` defines ``initial`` *and* you include
849 ``initial`` when instantiating the ``Form``, then the latter ``initial`` will
850 have precedence. In this example, ``initial`` is provided both at the field
851 level and at the form instance level, and the latter gets precedence::
852
853     >>> class CommentForm(forms.Form):
854     ...     name = forms.CharField(initial='class')
855     ...     url = forms.URLField()
856     ...     comment = forms.CharField()
857     >>> f = CommentForm(initial={'name': 'instance'}, auto_id=False)
858     >>> print f
859     <tr><th>Name:</th><td><input type="text" name="name" value="instance" /></td></tr>
860     <tr><th>Url:</th><td><input type="text" name="url" /></td></tr>
861     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
862
863 More coming soon
864 ================
865
866 That's all the documentation for now. For more, see the file
867 http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms/tests.py
868 -- the unit tests for ``django.newforms``. This can give you a good idea of
869 what's possible.
870
871 If you're really itching to learn and use this library, please be patient.
872 We're working hard on finishing both the code and documentation.
873
874 Widgets
875 =======
Note: See TracBrowser for help on using the browser.