History and Goals
=================

.. contents::

History
-------

I'm the author of FunFormKit_, a form generation and validation
package for Webware_.  I consider FunFormKit (FFK) to be a very
powerful and complete package, with features that few other form
validation packages for Python have (as to other languages, I haven't
researched enough to know).  It supports repeating and compound fields
(which most packages do not), and has a very expressive validation
system.

However, this is not FFK.  In fact, it signals 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 (and I won't claim to be an addict or
sufficiently disciplined about unit testing, but at least I'm better
at it now).  FFK was not made with testability in mind.  It's 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

Goals
-----

These are some of the concrete features I would like to implement,
sometime:

Form generation:

* Javascript validation.  We can't trust Javascript validation, but we
  can check some things before the form is submitted so that the user
  gets faster feedback (especially on simple things, like empty
  fields).  This is an extension to `Validator`, `Field`, and `Form`
  -- `Field` to access the values, `Validator` to generate the
  Javascript, and `Form` to trigger the process and handle the
  response of the validation.

* Ordered items in schemas.

* Non-HTML forms.  GUI forms could be generated either locally (i.e.,
  built up directly) or remotely (perhaps represented with an XML form
  description, and communicating with XML-RPC or some other RPC
  protocol).  Remote is probably more interesting.

* More ways of creating Schemas.