As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

This question was asked and answered over 2 years ago and there is none of the "solicit debate, arguments, polling or extended discussion" that you guys said will "likely" happen. A little overzealous perhaps?
–
Y.H WongDec 15 '12 at 19:05

5 Answers
5

Generally speaking I'm a little wary about HTML form libraries now. If you use something from a mega-framework, you invariably have to bring in the whole mega-framework as your dependency.

Many sub-components of many mega-frameworks claim to not depend on the framework but let's not kid ourselves. If you don't use one, there are at least a dozen form libraries that I know of out there with a wide range of differences in capabilities. Just the choices alone can get quite confusing. Generally speaking, as Ian Bicking says many years ago and is still true, I think the notion of one form library that suits everybody is quite ludicrous. In fact I'd argue you probably need to think twice before deciding you really need one. Chances are mostly of the time you just need a form validation library like FormEncode. It really depends on how you want to use it.

For me, since I don't use a mega-framework, I'd choose something light-weight, easy to pick up and configure, and something that doesn't get in the way of the normal usage of HTML/JS/CSS.

ToscaWidgets, ToscaWidgets 2 - Extremely powerful, but also extremely complicated. ToscaWidgets 2 is much better but it's still quite alpha ATM. It takes quite a bit of ninja skills to setup and your code tend to bloat up fairly quickly whenever you need to customize the default templates.

Formish/Deform - Almost as powerful as TW but Formish is dormant now. It's also quite tightly bound to Mako so if you don't use Mako, it's probably not for you. Deform is a rewrite of Formish but it brings in tons of Zope dependencies. Chameleon is also not quite there yet in terms of supporting other templating languages other then ZPT. These 2 libraries are also not particularly easy to setup.

WTForm - Very simple, doesn't get in your way and it's very active in terms of development. It's nowhere near as powerful as the above libraries but it generally takes care of the 80% use cases you might encounter so it's good enough.

FormEncode - Tried-and-true since 2005. Its well-tested, comes with the largest number of prebuilt validators, supports conditional validation, and useful error messages in dozens of languages. It also has a very simple but focused ability to generate form code in HTML prefilled with values and error messages. Its disadvantages includes a occasionally non-intuitive API and its absolutely spagetti-like internal code. However this library is quite dependable and fits very well in all the data validation use cases and it's the one I always come back to.

As of the end of 2012, a quick Google and PyPI search for a Python validation library comes back with hundreds of packages. There are a little more than a dozen notable ones, discounting those Django extensions, that are under active development. There seems to be a trend towards defining a schema using JSON-Schema and being able to generically validate Python data structures. This is likely a reflection of the server application developers' moving accepting user data from multiple channels (RESTful APIs and HTML forms), but remain wanting to use only one validation library.

Given the release of Python 3.3 will likely spark a massive movement towards porting existing libraries over to support Python 3.x (the flip side of that is seeing old libraries stagnant and remain compatible only with Python 2.x), it may be wise to choose one that already supports or is working actively to support Python 3.x.

Lastly, another great area of concern when choosing a form validation library is the ability to report useful error messages, which invariably includes the need for the localization of error messages in the long run. The ease of supplying your own error messages will quickly determine the complexity of integrating the library with the rest of your Web application architecture.

This topic is a bit on the old side, but I thought I'd shamelessly plug a library I've been writing for this very purpose. It's not exclusive to HTML forms, but was written with them, at least partially, in mind.

For your task, I would recommend you to use the web2py-Framework, which is easy to use and still "mighty". It has form-validation by default (the web2py-book is free), that does exactly what you want: It sepereates the html generation from the validation and does this automatically, but you can, if you wish, customize it.

@Satoru.Logic thanks for -1 for an answer, I spend my time for.. anyway, explain what do you mean with "web2py sucks"?
–
JoschuaJul 7 '10 at 12:34

>.< Because I'm suffering from a legacy system that is built with web2py. In web2py, implicit is much more common than explicit, just think about all those global variables ... the web2py file-based session is such a var, and I didn't see any easy way to change for another session implementation ...
–
satoruJul 7 '10 at 13:08

+1 for web2py sucking. The global environment and everything being implicit make just about everything harder, especially testing. It's like writing PHP in Python, except worse, because you keep forgetting it isn't real Python.
–
Mike AAug 16 '11 at 13:21

1

I mean there is some amount of magic with everything that's arround models + controllers. True. Magic far from PHP land. Certain vars/objects may appear as if they were global while they are in application scope. Those objects are so common that you hardly find application not using session, database, request etc. They are documented. You are aware of the entire injection and keep that in mind - trust me nothing bad happens. Unit tests are problematic in almost every framework. As you have to provide context/environment, you cant test form without simulating request and environment.
–
Marek MollinOct 30 '12 at 16:04