TW2 standalone vs TurboGears etc.
62 views
Skip to first unread message
Paul Johnston
Jul 12, 2013, 5:18:50 AM7/12/13
to toscawidge...@googlegroups.com
Hi,
Interesting question... and one I could write about for days :-)
tw2 is essentially a form building library. tg.crud is a completely different approach to forms - it autogenerates your templates, somewhat like Rails scaffolding. There are other approachs too, such as client-side templating, e.g. AngularJS. I won't argue the pros and cons of each approach, but form building works for me. If you're using tw2, you're using the form building approach. There are other form building libraries, e.g. Django forms, EasyWidgets.
In the simplest case you define your widgets in full, and do all database access explicitly in your controller. If you do this, tw2 plays nicely with Pyramid, TurboGears, etc. You can use tw2 standalone too, although it is quite basic compared to a "proper" framwork like Pyramid. Controllers are very simple, essentially just WebOb, and there's not much help with quickstart, configuration, etc. My experiemental branch (https://github.com/paj28/tw2.core) does have better support for authentication/authorisation and navigation.
Database access is often uniform - you do the same work for loading and saving every form. This seems a good angle for a library to help you. tw2.sqla can help you with this with widgets like DbSingleSelectField, DbListPage, DbFormPage. These save a lot of typing if your data access is uniform. If you have specific requirements, e.g. "this select field only show jobs related to this customer" it gets more difficult. You can customise things, but at this point you're not reducing your typing by much. I have had some success with incorporating business rules into the ORM session (http://pajhome.org.uk/security/clouddata.html).
I've not seen much else like this in the WSGI world. Sprox does DbSingleSelectField, but not DbListPage/DbFormPage. Rum is another attempt, but it is more Django Autoadmin - giving you a full automatic database editor, rather than individual load/save methods that a developer can control. So, this is one of things I really like about tw2.sqla. I only use this with tw2 standalone. DbSingleSelectField and such will play fine with Pyramid and such. However, using something like DbListPage is more controversial. I expect it would basically work, but cause some issues. Especially with my experimental branch where every Page widget has to be within a Directory. I'd be interested to hear from people who have tried this.
Widgets definitions often follow model classes in a uniform way. This is another angle for a library to help you. Both Sprox and tw2.sqla can automatically generate Widget forms from model classes. But this gets problematic if you want a form that doesn't quite match your model. They both heave features to let you override generation. tw2.sqla lets you do both policy overrides e.g. "every string field becomes a textarea" and individual field overrides. But it gets messy. Should the overrides go on the model - polluting your model with view considerations? Or should they go in a separate file?
Because of all this, I've ended up not using this part of tw2.sqla. I'm actually starting to wonder if a better approach is to go the other way. Generate model definitions from forms. For a typical web app, we probably care more about the forms, rather than defining a rigid data model. And this better fits NoSQL databases, where you don't even have a model definition.
There are already some thoughts here: http://toscawidgets.org/documentation/tw2.sqla/design.html
If someone wanted to explore how to make DbListPage and such play better with Pyramid and write a tutorial about this, that would be very valuable.
Paul
> I don't want to hijack the thread--but this discussion bears the question--which db-enabled flavor of TW to use, i.e. TW standalone, TurboGears, or Pyramid (and perhaps others?). Is there a document somewhere that describes the various strengths/weaknesses/
Interesting question... and one I could write about for days :-)
tw2 is essentially a form building library. tg.crud is a completely different approach to forms - it autogenerates your templates, somewhat like Rails scaffolding. There are other approachs too, such as client-side templating, e.g. AngularJS. I won't argue the pros and cons of each approach, but form building works for me. If you're using tw2, you're using the form building approach. There are other form building libraries, e.g. Django forms, EasyWidgets.
In the simplest case you define your widgets in full, and do all database access explicitly in your controller. If you do this, tw2 plays nicely with Pyramid, TurboGears, etc. You can use tw2 standalone too, although it is quite basic compared to a "proper" framwork like Pyramid. Controllers are very simple, essentially just WebOb, and there's not much help with quickstart, configuration, etc. My experiemental branch (https://github.com/paj28/tw2.core) does have better support for authentication/authorisation and navigation.
Database access is often uniform - you do the same work for loading and saving every form. This seems a good angle for a library to help you. tw2.sqla can help you with this with widgets like DbSingleSelectField, DbListPage, DbFormPage. These save a lot of typing if your data access is uniform. If you have specific requirements, e.g. "this select field only show jobs related to this customer" it gets more difficult. You can customise things, but at this point you're not reducing your typing by much. I have had some success with incorporating business rules into the ORM session (http://pajhome.org.uk/security/clouddata.html).
I've not seen much else like this in the WSGI world. Sprox does DbSingleSelectField, but not DbListPage/DbFormPage. Rum is another attempt, but it is more Django Autoadmin - giving you a full automatic database editor, rather than individual load/save methods that a developer can control. So, this is one of things I really like about tw2.sqla. I only use this with tw2 standalone. DbSingleSelectField and such will play fine with Pyramid and such. However, using something like DbListPage is more controversial. I expect it would basically work, but cause some issues. Especially with my experimental branch where every Page widget has to be within a Directory. I'd be interested to hear from people who have tried this.
Widgets definitions often follow model classes in a uniform way. This is another angle for a library to help you. Both Sprox and tw2.sqla can automatically generate Widget forms from model classes. But this gets problematic if you want a form that doesn't quite match your model. They both heave features to let you override generation. tw2.sqla lets you do both policy overrides e.g. "every string field becomes a textarea" and individual field overrides. But it gets messy. Should the overrides go on the model - polluting your model with view considerations? Or should they go in a separate file?
Because of all this, I've ended up not using this part of tw2.sqla. I'm actually starting to wonder if a better approach is to go the other way. Generate model definitions from forms. For a typical web app, we probably care more about the forms, rather than defining a rigid data model. And this better fits NoSQL databases, where you don't even have a model definition.
There are already some thoughts here: http://toscawidgets.org/documentation/tw2.sqla/design.html
If someone wanted to explore how to make DbListPage and such play better with Pyramid and write a tutorial about this, that would be very valuable.
Paul
> I don't want to hijack the thread--but this discussion bears the question--which db-enabled flavor of TW to use, i.e. TW standalone, TurboGears, or Pyramid (and perhaps others?). Is there a document somewhere that describes the various strengths/weaknesses/
appropriate uses of each?
Reply all
Reply to author
Forward
0 new messages