Update: This may not be necessary for GIS
,52 has a rewritten approach to Layers where 'gis_layer_%s' % type are SQLTables (inheriting from a base set) which we can use t2.*() on

  • this seems to give us most (all?) of the benefits below.

However I think that PERSON won't be solvable in the same way :/

The GIS module may benefit from writing a LAYER class.
Layer Types would extend this base class.

Each Layer Type would be a single Table & hence could use the standard RESTlike controller.
This should ease maintenance compared to the current process.

Have the Map Service Catalogue have a tab per Type(*).
Each has its own self-processing SQLFORM (generated by T2)
(This would make it like S2, which works well)

It should make us friendlier to non-JavaScript browsers (such as Mobile devices), since currently we rely on gis_layers.js to show us only relevant fields. (An alternative use for this script would be to pull in new SQLFORM object via ?format=plain instead of adjusting fields displayed/hidden).

This gives us better control of the display order for Layers & better modularity of Layer-processing JS code (1 file per layer type).

  • Alternatives could be collapsible sections (like appadmin) or submenus on left-hand navigation.
  • JQuery-Tabs: "if the markup is well designed, it will automatically degrade nicely without JavaScript enabled"

Objects contain both data and functionality together.
A Class in essence defines a new data type.

=> The Class is not the Controller alone, but the Resource (including Controller)
=> Each Resource type should extend a base Resource (which extends...?)

Currently our resources are defined in the model & hence of type gluon.sql.SQLTable (inc SQLFields)
LAYER extends RESOURCE extends SQLTable? or has an attribute SQLTable?
Other attributes:

  • Controller
  • crud_strings

NB A similar solution probably applies for 'PERSON' as well.

GIS BluePrints

Last modified 13 years ago Last modified on 01/05/09 20:49:06
Note: See TracWiki for help on using the wiki.