|Version 8 (modified by william, 11 years ago) (diff)|
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.
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.
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.
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.
class Category(SQLObject): name = StringCol(length=50) class Person(SQLObject): name = StringCol(length=50) address = StringCol(length=50) city = StringCol(length=50) state = StringCol(length=2) zip = StringCol(length=10) age = IntCol() category = ForeignKey('Category')
Ignoring the several obvious problems with this example, it should still function as a reasonable application for simple CRUD.
If you can easily create a form for this, with appropriate validation and with a significant ability to customize as needed, then we've got a good start.
Prior art candidates:
- Ruby on Rails
There is also a message from bonono about his style of doing CRUD.
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.
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.