Table Of Contents
What’s New in WTForms 3¶
WTForms 3 is something something TODO
Past Major Releases¶
WTForms 2 was the first major version bump since WTForms 1.0. Coming with it are a number of major changes that allow far more customization of core WTForms features. This is done to make WTForms even more capable when working along with companion libraries.
- Class Meta paradigm allows customization of many aspects of WTForms.
- CSRF and i18n are core features not needing extensions anymore.
- Widget rendering changes:
<attribute name>=Falseto WTForms widget rendering is now ignored, making it easier to deal with boolean HTML attributes.
- Creating an html attribute
data-foocan be done by passing the keyword
data_footo the widget.
These API’s still work, but in most cases will cause a DeprecationWarning. The deprecated API’s will be removed in WTForms 3.0, so write code against the new API’s unless it needs to work across both WTForms 1.x and 2.x
- WTForms Extensions
All the extensions are being deprecated. We feel like the extensions we had
would actually benefit from being pulled outside the WTForms package,
because it would allow them to have a separate release schedule that suits
their companion libraries.
wtforms.ext.appengineIs deprecated, see WTForms-Appengine
wtforms.ext.csrfCSRF protection is now built in
wtforms.ext.dateutilIs deprecated, but does not have a new home yet.
wtforms.ext.djangoIs deprecated. See WTForms-Django
wtforms.ext.i18ni18n is now built in
wtforms.ext.sqlalchemyIs deprecated, look at WTForms-Alchemy (docs)
Most of these changes shouldn’t affect the typical library user, however we are including these changes for completeness for those who are creating companion libraries to WTForms.
BaseForm._fieldsis now an OrderedDict, not a plain dict.
FormMetanow manages an attribute called
_wtforms_metawhich is a subclass of any
class Metadefined on ancestor form classes.
- A new keyword-param called simply
data=to the Form constructor has been added and positioned as the place where soon we will be able to accept structured data which is neither formdata, object data, or defaults. Currently this parameter is merged with the kwargs, but the intention is to handle other structured data (think JSON).
Filterson fields stop on the first ValueError, instead of continuing on to the next one.