Background and Motivation
+++++++++++++++++++++++++

There are a number of approaches to take when designing the form handling
components of a web application.

#.  Code the forms in HTML, write the validation by hand and write SQL to store
    and retrieve data from the database.

#.  Model a form field, validation object and database field as the same thing, 
    create specific field objects for each data type your application needs 
    and create one definition for each form that serves as the database 
    structure definition validation object and form handling code all in one.

The first approach is fine for simple applications but leads to a lot of
duplication of effort for any project consiting of more than a few forms.

The second approach is brilliant for certain applications where field objects
already exist for the data types you wish to handle and you don't want to do
anything clever or complicated with a database. If this is the case you only
need to define your fields and the application is virtually written. This
is the approach `Django <http://www.djangoproject.com>`_ takes.

The drawback is that you have to unravel a lot of carefully crafted code if you
want to do anything more complicated than the system was designed for and this
can be very difficult.

The optimum solution for form and database handling has to be that you create
form layouts in templates with an API that can be modified to affect the
rendering of your forms. Form data is validated with a validation API that is
separate from the form layout and form rendering code (after all a form layout
is not the same as the values the form contains) and this data is then saved to
the database in whatever place is appropriate (after all the data contained in
a single form might be stored in more than one table in a database).

Luckily `FormEncode <http://www.formencode.org>`_ already exists to provide a
brilliant validation API and `SQLAlchemy <http://www.sqlalchemy.org>`_ exists
to provide first class database handling. FormBuild fills the gap to provide
form generation tools and the handling glue to handle forms.

Future
======

Even the FormBuild approach may contain some unnecessary dupliaction. For
example if your SQLAlchemy table definition contains an integer field why not
automatically create a FormEncode schema with an Int validator and a FormBuild
form with a text box field for input? 

Well, this may well be a valid argument and FormBuild has ``creator`` objects
to help with just such a task although none have yet been written for the
example above. 

Perhaps once FormBuild has been used more extensively it will become more
obvious if this sort of tool would be a genuine benefit or simply a gimmick. So
far the Pylons team have made various attempts at a useful CRUD type system
(see `ContentStor <http://pylonshq.com/project/pylonshq/browser/ContentStor>`_
and the more recent `Scaffold
<http://pylonshq.com/project/pylonshq/browser/sandbox/james/Scaffold>`_ code)
but have come to the conclusion each time that such solutions limit flexibility
and in reality don't offer huge advantages for developers.
