Changeset 8020 for django/trunk/docs/forms.txt
- Timestamp:
- 07/21/08 11:38:54 (6 months ago)
- Files:
-
- django/trunk/docs/forms.txt (moved) (moved from django/trunk/docs/newforms.txt) (12 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
django/trunk/docs/forms.txt
r7978 r8020 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. 1 ================= 2 The forms library 3 ================= 4 5 ``django.forms`` is Django's fantastic new form-handling library. It's a 6 replacement for the old form/manipulator/validation framework, which has been 7 moved to ``django.oldforms``. This document explains how to use this new 8 library. 8 9 9 10 Migration plan … … 55 56 ======== 56 57 57 As with the ``django. forms`` ("manipulators") system before it,58 ``django. newforms`` is intended to handle HTML form display, data processing58 As with the ``django.oldforms`` ("manipulators") system before it, 59 ``django.forms`` is intended to handle HTML form display, data processing 59 60 (validation) and redisplay. It's what you use if you want to perform 60 61 server-side validation for an HTML form. … … 89 90 ============ 90 91 91 The primary way of using the `` newforms`` library is to create a form object.92 Do this by subclassing ``django. newforms.Form`` and specifying the form's92 The primary way of using the ``forms`` library is to create a form object. 93 Do this by subclassing ``django.forms.Form`` and specifying the form's 93 94 fields, in a declarative style that you'll be familiar with if you've used 94 95 Django database models. In this section, we'll iteratively develop a form … … 98 99 Start with this basic ``Form`` subclass, which we'll call ``ContactForm``:: 99 100 100 from django import newforms asforms101 from django import forms 101 102 102 103 class ContactForm(forms.Form): … … 585 586 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 586 587 587 By default, forms use ``django. newforms.util.ErrorList`` to format validation588 By default, forms use ``django.forms.util.ErrorList`` to format validation 588 589 errors. If you'd like to use an alternate class for displaying errors, you can 589 590 pass that in at construction time:: 590 591 591 >>> from django. newforms.util import ErrorList592 >>> from django.forms.util import ErrorList 592 593 >>> class DivErrorList(ErrorList): 593 594 ... def __unicode__(self): … … 784 785 785 786 Note that we check ``field.field.required`` and not ``field.required``. In the 786 template, ``field`` is a `` newforms.forms.BoundField`` instance, which holds787 template, ``field`` is a ``forms.forms.BoundField`` instance, which holds 787 788 the actual ``Field`` instance in its ``field`` attribute. 788 789 … … 919 920 you can also instantiate them and use them directly to get a better idea of 920 921 how they work. Each ``Field`` instance has a ``clean()`` method, which takes 921 a single argument and either raises a ``django. newforms.ValidationError``922 a single argument and either raises a ``django.forms.ValidationError`` 922 923 exception or returns the clean value:: 923 924 … … 934 935 If you've used Django's old forms/validation framework, take care in noticing 935 936 this ``ValidationError`` is different than the previous ``ValidationError``. 936 This one lives at ``django. newforms.ValidationError`` rather than937 This one lives at ``django.forms.ValidationError`` rather than 937 938 ``django.core.validators.ValidationError``. 938 939 … … 1186 1187 -------------------------- 1187 1188 1188 Naturally, the `` newforms`` library comes with a set of ``Field`` classes that1189 Naturally, the ``forms`` library comes with a set of ``Field`` classes that 1189 1190 represent common validation needs. This section documents each built-in field. 1190 1191 … … 1589 1590 If the built-in ``Field`` classes don't meet your needs, you can easily create 1590 1591 custom ``Field`` classes. To do this, just create a subclass of 1591 ``django. newforms.Field``. Its only requirements are that it implement a1592 ``django.forms.Field``. Its only requirements are that it implement a 1592 1593 ``clean()`` method and that its ``__init__()`` method accept the core arguments 1593 1594 mentioned above (``required``, ``label``, ``initial``, ``widget``, … … 1680 1681 ``is_valid_email()``. The full class:: 1681 1682 1682 from django import newforms asforms1683 from django import forms 1683 1684 1684 1685 class MultiEmailField(forms.Field): … … 2516 2517 That's all the documentation for now. For more, see the file 2517 2518 http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/forms 2518 -- the unit tests for ``django. newforms``. This can give you a good idea of2519 -- the unit tests for ``django.forms``. This can give you a good idea of 2519 2520 what's possible. (Each submodule there contains separate tests.) 2520 2521
