Hello > Chris, Alberto and I have been working hard in the CRUD area. > I think, much advancements have been made in this area. > > So, I am very interested, how data is entered in average TG/TG2/... > web applications. > > Is your admin interface web based?
The answer is a bit complicated. The Web application itself can be considered an "admin interface": it doesn't have a read-only area with fancy pages and reports (well, it almost doesn't). In other words, it /is/ an application in the full sense :-) However, there are two types of data input: - data input by operators (with various permission levels), which is of course done through the Web interface; let's call it "daily data" - data input by myself, as an admin, when doing bulk imports of existing legacy data (data that was in use before the application was written, or got whatever additional feature), or when performing certain rare and priviledged tasks (like adding users); let's call it "exceptional data" > Is it hand written, or do you use existing CRUD solutions? > For both, hand-written. I had considered using a CRUD solution for the sole user/group/permission thing, but existing solutions didn't seem mature and functional enough. > Who enters the data? > - daily data: various operators - exceptional data: me, after it was sent it to me by my client (often as baroquely-formatted CSV files :-)) > How many persons use the admin interface? > - daily data: several dozens - exceptional data: 1 (me) > How long per day are they supposed to work with it? > - daily data: 8 hours a day for some of them (full time) - exceptional data: almost never > Are there granular permissions requirements? > Table permissions (which classes/ tables can be edited), Row level > permissions (which objecs can be edited), column level permissions > (block specific attributes)? > I've built my permissions at the functional level (that is, at the controller/method level), but it could be approximated by a model- or database-level permission system. Most of it abounds to table-level permission, but there is a bit of row-level permission (depending on certain joins with some additional property I've added to the Group object), and even column-level permission (for a single sensitive set of columns). > How many tables does your database contain? Or can you give any > measure for the complexity? > Roughly 15 tables. > Do you use additional tools for your database for querying/editing the > data? > Custom scripts for (often one-off) importation CSV data. There are also a couple of Web forms so that users of the Web UI can import their own CSV data, in specific formats. > What additional requirements do you have, that are not fulfilled by > todays CRUD packages? > Two major requirements I can think of: The possibility to define how a relation is chosen/modified (having to choose in a drop-down of 1000 items is stupid; I need e.g. some autocomplete field based on some (supposedly unique) column of the joined table). The possibility to specify that a VARCHAR field is really an enum, and to specify what labels (on the UI side) correspond to what values (on the DB side). Then, of course, there's layout flexibility, custom validation, etc. An useful CRUD package should be something else than a smart version of phpmysql. Regards Antoine. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
