Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Changes between Version 1 and Version 2 of SimpleAdminIdeas

10/18/05 00:16:46 (14 years ago)



  • SimpleAdminIdeas

    v1 v2  
    33This document will gather the ideas, prior art and choices for providing TurboGears with the ability to automatically generate interfaces for creating/retrieving/updating/deleting data from databases. This feature is targeted for TurboGears 0.9. 
     5== Design Goals == 
     7Before diving in to details and comparisons of existing technology and ideas, let's review what we specifically want to accomplish for TurboGears quickstart applications: 
     91. A means to create simple database update forms nearly "for free" 
     102. These forms should allow for both client-side and server-side validation easily 
     113. A means to create the controller to receive that form input nearly "for free" 
     124. A smooth migration path from the automatically generated forms to something that is tailored for the application at hand 
     135. A smooth migration path for the controller's behavior as needs change 
     15Right now, this document is focused on the '''view layer''', which means specifically #1, #2 and #4. The controller layer will likely be considerably less complex. 
     17The 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. 
     19== Implementation Goals == 
     21This follows the general TurboGears philosophy, but it's worth repeating. 
     231. 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. 
     242. Unit tests are critical 
     253. If it's not documented, it doesn't exist. 
     27I (Kevin) realize that many people don't like #3. That's fine. If you write the code, I'd be happy to help with #3. 
     29#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. 
     31== Prior Art == 
     33Lots 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. 
     35The 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. 
     37Good 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. 
     40class Category(SQLObject): 
     41    name = StringCol(length=50) 
     44class Person(SQLObject): 
     45    name = StringCol(length=50) 
     46    address = StringCol(length=50) 
     47    city = StringCol(length=50) 
     48    state = StringCol(length=2) 
     49    zip = StringCol(length=10) 
     50    age = IntCol() 
     51    category = ForeignKey('Category') 
     54Ignoring the several obvious problems with this example, it should still function as a reasonable application for simple CRUD. 
     56If 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.