Simple CRUD Ideas

This document will gather the ideas, prior art and choices for providing TurboGears with the ability to automatically generate interfaces for creating/retrieving/updating/deleting (CRUD) data from databases. This feature is targeted for TurboGears 0.9.

Design Goals

Before diving in to details and comparisons of existing technology and ideas, let's review what we specifically want to accomplish for TurboGears quickstart applications:

A means to create simple database update forms nearly "for free"

These forms should allow for both client-side and server-side validation easily

A means to create the controller to receive that form input nearly "for free"

A smooth migration path from the automatically generated forms to something that is tailored for the application at hand

A smooth migration path for the controller's behavior as needs change

Right now, this document is focused on the view layer, which means specifically nos. 1, 2 and 4. The controller layer will likely be considerably less complex.

The first pass does not need to take into account one-to-many and many-to-many relationships (item/detail style forms). Or, rather, the first version does not need to create such forms automatically. It does need to be possible for the developer to create such forms, though.

Implementation Goals

This follows the general TurboGears philosophy, but it's worth repeating.

Don't write code for the sake of writing code. If there's an existing package with a good license that can be adapted for TurboGears, we should do that.

Unit tests are critical

If it's not documented, it doesn't exist.

I (Kevin) realize that many people don't like no. 3. That's fine. If you write the code, I'd be happy to help with no. 3.

No. 2 should really be done along with the code. If you're not sure about how to write a test for something, send a message to the list and there will definitely be help available.

Prior Art

Lots of people have ideas on generating forms automatically, and quite a few have even written code for it. Some amount of that code is already in Python. A few minutes spent looking at work that has already been done can save us hours of reinvention.

The following sections represent ideas to be explored. Feel free to add details or comments, or even an entire new wiki page if you need to. With the information packaged up on the prior art, it will be easier to decide what needs to be implemented in TurboGears.

Good APIs cannot be designed in a vacuum: they need to make real applications easier, not theoretical ones. Since we're starting off simple, let's consider an Address Book application.

FormEncode is already included in TurboGears. Ian Bicking has recently been looking at form generation (formgen in FormEncode) and has also been thinking about using generic functions from the PyProtocols? dispatch package.

FormIO

Catwalk

Personnally, I've read the different ideas discribed here above, and none of them, if I'm correct, was able to match my needs: generate the Html code for a select, text, input, ... and validate the received values (but can be done via Formencode.validator).
Then I remember I've already seen such discussion on the CherryPy? mailinglist months ago. And Bingo!!!! they have FastFormward.
This is EXACTLY what I need:

generate the whole form (the only last step is to include it in the Kid file)

it validate the received values (in case of submit) and if wrong displays, close to the field, a small error message.

Very simple and nice!!! no ????

What is missing is the link with SQLObject. Indeed, SQLObject knows which type of data we have (boolean, text, string, ...). Could be nice that an enhanced version of this module could take advantage of it.

I should add that I've not yet test it ;-( ... but it's a question of hours.
FastFormward was not CP2.1 compatible, I've adatp it and few tests runs fine. You can download it from here.