Tuesday, February 15, 2011

TurboGears 2 presenting relationship

Time for me to move on and learn TurboGears2.1. Coming from django background, I expected somewhat similar elegance in TurboGears. Something like urlpatterns, which is quite nice. I did not found something like that. A bit disappointment, because urlpatterns really such a wonderful way to map between url requests and the handlers.
The main and biggest issue with django is it's orm. I really wish somehow we can replace it with sqlalchemy and still having all the auto generated Admin Interface.
Sqlalchemy is totally awesome. If you have not used it yet, please spend sometimes with it.

Since, TurboGears supports sqlalchemy, I decided to take a look and play around with it. The awesome thing about TurboGears 2.1 it also have Administration System, which will auto generate the web interface, using python-rum and sprox.

The first time I used the Admin System, I got the UI (tables and forms) for all the tables prepared. The only issue at that time was the relationship displayed is still using 'id'. Quite confusing for the end-user.

Digging more and more about TurboGears 2.1, I learned that all of the transformations from the table schema into web UI are done via sprox, which uses '_name', 'name', (and some other values) as default values for column name matching relationship representation.

Did some more digging and I figured out how to define the desired column for relationship representation.

class: TableFiller
modifier: __possible_field_names__ = [ 'brand', 'first_name' ]
class: AddRecordForm
modifier: __dropdown_field_names__ = [ 'title' ]
class: EditableForm
modifier: __dropdown_field_names__ = [ 'name', 'info' ]

Those classes could be imported using the following:
from sprox.fillerbase import TableFiller
from sprox.formbase import AddRecordForm, EditableForm

TableFiller is for viewing, AddRecordForm is for adding new record, EditableForm is of course for edit existing record.

So, what you can do is subclass those classes, according to your need, and set either __possible_field_names__, __dropdown_field_names__ or both, to the appropriate columns. Then store the subclasses in the controller (project/app/controllers/root.py, for example).