| author: | Ian Bicking |
|---|
I’m the author of FunFormKit, a form generation and validation package for Webware. I considered FunFormKit (FFK) to be a very powerful and complete package, with features that few other form validation packages for Python had (as to other languages, I haven’t researched enough to know). It supported repeating and compound fields (which most packages do not), and had a very expressive validation system.
However, this is not FFK. In fact, it is a deprecation of FFK and does not provide backward compatibility. Why?
Probably the biggest problem was that FFK didn’t support compound and repeating fields. Adding them made everything much more difficult – it was a sort of clever hack (maybe not even clever), and the result was very hard for anyone else to understand. Ultimately hard for me to understand.
Ontop of this was a structure that had too much coupling. Testing was difficult. I only came to like unit testing after FFK had gone through several revisions. FFK was not made with testability in mind. It can be hard to add later.
Also, I wanted to use pieces of FFK without the entire framework. Validation without the form generation was the biggest one. Alternate kinds of forms also interested me – making it easier to do highly granual templating, or non-HTML/HTTP forms. Alternate data sources, like SQL or XMLRPC, also seemed important. All of these were not easy within the interfaces that FFK used.
So... FormEncode! FormEncode takes a lot of ideas from FFK, and a lot of the code is just modified FFK code. All of it is reviewed and actively inserted into FormEncode, I’m not transferring anything wholesale.