On Jan 14, 8:38 am, mdipierro <[email protected]> wrote: > On a second thought.... this is not quite the same of what the link > says. > My example defines 6 different tables.
Right & my experience of trying to import data from an external source into such a distributed set of tables is that it requires a lot fo work :/ > The link you send seems to suggest building a single table with unused > fields. web2py does not allow that and I would not consider it very > clean. Look at the Rails implementations...I'm not sure they do this? What we want is for the user to see all relevant fields together in a single form. Right now there are 3 options to achieve this: 1. Have a single table with fields for all potential cases - this means the developer can use standard T2 CRUD functions (low maintenance) & then tweak using jquery to hide/show fields as they become relevant or not (extra maintenance here). 2. Have multiple tables - 1 for each subtype. - this allows developers to use the standard T2 CRUD again, although itemize requires additional work as each subtype needs to be listed separately. We also can't change sub-type within the form...if we needed that we'd have to add a separate controller with jquery to suck in a whole new form which seems like work involved to retain field salready filled-in, etc. 3. Have multiple linked tables to handle the fields which are only relevant to certain contexts (as per your example & how current Sahana is structured). - this means the developer has to ditch T2 & use manual forms (the table with most fields could be a SQLFORM with just the extra ones handled manually). Again if subtype is to be changeable, need to use jquery to hide/show fields. This is a lot more work, especially to build into a central CRUD controller to which extra functionality like new import/export routines, authorization & auditing can be added. It is also painful when trying to import data from 3rd-party systems as each table needs to be imported separately with matching ID links (I'm fighting this exact issue currently for a live implementation). If we look at my GIS Layers example (OpenStreetMap, Google, Yahoo, etc base layers with overlays from WMS, internal features , GeoRSS feeds, etc) I implemented originally using option 3 which worked fine, but the maintenance levels required were high. I started trying to rewrite as a CLASS (extending SQLTABLE), but before I got too far with this I just implemented option 2. This is massively easier for me & I have no need to adjust subtype in the forms so I just have the hassle of maintaining the itemize list. (I'm still DRY in the model as I borrowed the T2 idea of defining the common fields once & reusing). However I need a different solution for the Person resource. A Person can be any of many & multiple contexts: * Contact for an Organisation (or Office) with a 'title' relevant to that context (could have different titles in different contexts) * Role for administering data relevant to an Organisation (or Office, or Country, or Region) * Volunteer * Donor * Victim (Missing/Dead/Beneficiary) * Public (relative/friend wanting to report or check on status of a missing person) Ideas for how to model this environment are very welcomed :) I have concerns around the scalability of the tagging-style multiple=True fields (which aren't currently working for me anyway - just producing SELECT...no MULTIPLE) when there are a huge number of options to choose from. The low developer effort on maintenance is a key requirement since the application is often rapidly-customised in the field...this isn't a single website which is polished hard & maintained by a small team of people who know the system intimately. Best Wishes, Fran. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
