1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
FAQ
===
This contains the most commonly asked questions about WTForms. The most current
version of this document can always be found on the `WTForms Website`_.
.. _WTForms Website: http://wtforms.simplecodes.com
Why does WTForms copy Django Forms?
-----------------------------------
Were we a bit more audacious, we'd probably say Django Forms copied us, but the
reality is that WTForms and Django's "newforms" were actually written at about
the same time.
When WTForms was written, our primary goals were to provide HTML customization
through templates, easily customized validation and a simple, declarative
ORM-style API. At the time there was no newforms and the other alternatives
either didn't support HTML generation, were very tightly coupled with a
single framework, or relied too heavily on an ORM.
Does WTForms work with [library here]?
--------------------------------------
The answer is most likely **yes**. WTForms tries to provide as usable an API as
possible. We've listed here some of the known libraries to work with WTForms,
but if it's not listed, it doesn't mean it won't work.
* **Request/Form Input**
* Django
* Webob (Includes Pylons, Google App Engine, Turbogears)
* Werkzeug (Includes Flask, Tipfy)
* any other cgi.FieldStorage-type multidict
* **Templating Engines**
* Jinja2
* Mako
* Django Templates (To get the full power of WTForms in your templates, you
will need to use the Django :mod:`extension <wtforms.ext.django>`.)
* Genshi
* **Database Objects**
* Pretty much any ORM or object-DB should work, as long as data objects allow
attribute access to their members.
Special support is there for SQLAlchemy, Google App Engine, and Django
collections via :mod:`extensions <wtforms.ext>`.
Does WTForms support unicode?
-----------------------------
Simple answer: Yes.
Longer answer: WTForms uses unicode strings throughout the source code, and
assumes that form input has already been coerced to unicode by your framework
(Most frameworks already do this.) WTForms fields render to unicode strings by
default, and therefore as long as your templating engine can work with that,
you should have no unicode issues.
What versions of Python are supported?
--------------------------------------
WTForms supports Python versions 2.5 and up. Presently (as of December 2011),
Python 3.x is not officially supported, but the development version has made
headway on this. We expect the upcoming 1.0 release to fully support Python 3
using the '2to3' tool.
How can I contribute to WTForms?
--------------------------------
WTForms is not that scary. Really. We try to keep it as succint and readable as
possible. If you feel like you have something to contribute to WTForms, let us
know on the `mailing list`_. For bugs and feature requests, you can file a
ticket on the `project page`_.
.. _mailing list: http://groups.google.com/group/wtforms
.. _project page: http://bitbucket.org/simplecodes/wtforms
How do I mark in a template when a field is required?
-----------------------------------------------------
Some validators (notably Required and Optional) set flags on the fields'
:attr:`~wtforms.fields.Field.flags` object. To use this in a template, you can
do something like:
.. code-block:: html+jinja
{% for field in form %}
{{ field }}
{% if field.flags.required %}*{% endif %}{{ field.label }}
{% endfor %}
Does WTForms handle file uploads?
---------------------------------
Currently, it does not. This is because WTForms strives to be
framework-agnostic, and every web framework handles file uploads somewhat
differently. WTForms has a :class:`~wtforms.fields.FileField` which will let
you render a file input widget, but the rest is up to you. An example use in a
django-ish framework::
class MyForm(Form):
image = FileField()
def my_view(request):
form = MyForm(request.POST)
file_wrapper = request.FILES[form.image.name]
# Do things with your file wrapper now
Using ``form.image.name`` is an easy way to know what input name was generated
for your file input, even if the form is prefixed.
Why does blank input not go back to the default value?
------------------------------------------------------
A key design decision of WTForms was that form data -always- takes precedence
when there's a form submission. That is, if a field exists on a form, and a
form was posted, but that field's value was missing, it will not revert to a
default, but instead store an empty value (and in some cases cause a validation
error.)
This is for a number of reasons:
1. Security. If a form reverted to defaults on missing data, then an evil user
could potentially cause problems by submitting a hand-coded form with key
missing fields.
2. Bug-finding. If you omitted a field in your template, it might fall through
to the default and you'd possibly miss it.
3. Consistency.
See the following mailing list posts for more discussion on the topic:
- http://groups.google.com/group/wtforms/browse_frm/thread/6755a45a13878e9
- http://groups.google.com/group/wtforms/msg/fa409c8c89b6f62d
How do I... [convoluted combination of libraries]
-------------------------------------------------
You'll probably want to check out our
:ref:`Solving Specific Problems <specific_problems>` doc.
|
