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
|
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.
.. _FunFormKit: http://funformkit.sf.net
.. _Webware: http://webware.sf.net
|
