TG2.1, nice web app framework. I just with it has better documentations. Compare to django, TG2.1 documentations are way behind. But, still it is much more flexible.
I encountered problem that TG2 Admin Page, created with TG Administration System, automatically set the (html) input field of the model's PK to disabled. Sprox assumes that your model's PK is auto-generated.
Some one already reported the issue here
and then created the proper tickets to sprox here
Got a good clue where to check, so after taking a look inside sprox.formbase source code, below is the reason why PK fields are non-editable.
class EditableForm(FormBase):
"..."
def _do_get_disabled_fields(self): fields = self.disable_fields[:]
fields.append(self.provider.get_primary_field(self.entity))
# automatically set PK field disabled return fields
same goes with: class AddRecordForm(FormBase)
I wrote it in here.
Hopefully useful for those who need it.
Showing posts with label TurboGears 2. Show all posts
Showing posts with label TurboGears 2. Show all posts
Friday, April 8, 2011
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).
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).
Subscribe to:
Posts (Atom)