Mercurial > dive4elements > river
view flys-artifacts/doc/datacage.txt @ 3035:b388d888330d
Implemented facets and splitted up the event facet.Implemented facets and splitted up the event facet.
flys-artifacts/trunk@4604 c6561f87-3c4e-4783-a992-168aeb5c3f6f
author | Raimund Renkert <raimund.renkert@intevation.de> |
---|---|
date | Wed, 06 Jun 2012 11:35:32 +0000 |
parents | aba4104f41c9 |
children | 6a37a0134409 |
line wrap: on
line source
The datacages behaviour is defined in the file conf/meta-data.xml . The datacage serves two purposes. It handles automatic 'recommendations', which are instructions sent by the client to add newly created artifacts to the collection. From a user perspective, these artifacts mainly represent curves or data points in the resulting diagrams. The second task is to let the user add already existing artifacts (i.e. previous calculations) or new artifacts with access to related data. Irrelevant of the type of elements (recommendations or user picked data) the datacage can iterate over possible artifacts by accessing its own database. Thus, to create a list of matching entries, database queries are used. In meta-data.xml, database queries are defined as <dc:statement> elements, for example <dc:statement> SELECT id AS prot_id, description AS prot_description FROM wsts WHERE kind = 1 AND river_id = ${river_id} </dc:statement> As can be seen from the example, the datacage configuration file can maintain its own stack of variables (${river_id} in above example).