Background and Motivation

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

  1. Code the forms in HTML, write the validation by hand and write SQL to store and retrieve data from the database.
  2. 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 consisting 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 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 already exists to provide a brilliant validation API and SQLAlchemy 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 duplication. 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 and the more recent 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.