On Jan 14, 8:38 am, mdipierro <mdipie...@cs.depaul.edu
> On a second thought.... this is not quite the same of what the link
> 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
> 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
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
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
- 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)
* Victim (Missing/Dead/Beneficiary)
* Public (relative/friend wanting to report or check on status of a
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.