On Intentions And HistoryΒΆ

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.

Previous topic

htmlfill

Next topic

FormEncode Design

This Page