felix@3038: This document describes how the datacage configuration works, from a user felix@3038: perspective. Some rather technical details are omitted and mechanisms felix@3038: simplified. felix@3038: felix@3033: The datacages behaviour is defined in the file conf/meta-data.xml . felix@3033: felix@3033: The datacage serves two purposes. felix@3033: It handles automatic 'recommendations', which are instructions felix@3033: sent by the client to add newly created artifacts to the collection. felix@3033: From a user perspective, these artifacts mainly represent curves or data felix@3033: points in the resulting diagrams. felix@3033: The second task is to let the user add already existing artifacts (i.e. felix@3033: previous calculations) or new artifacts with access to related data. felix@3033: felix@3033: Irrelevant of the type of elements (recommendations or user picked data) the felix@3033: datacage can iterate over possible artifacts by accessing its own database. felix@3033: Thus, to create a list of matching entries, database queries are used. felix@3033: felix@3033: In meta-data.xml, database queries are defined as elements, felix@3033: for example felix@3033: felix@3033: SELECT id AS prot_id, felix@3033: description AS prot_description felix@3033: FROM wsts WHERE kind = 1 AND river_id = ${river_id} felix@3033: felix@3033: felix@3033: As can be seen from the example, the datacage configuration file can maintain felix@3033: its own stack of variables (${river_id} in above example). felix@3038: felix@3038: The database query will usually deliver one or many results, over which is felix@3038: iterated using the elements. felix@3038: felix@3038: Information from this results can be used for two goals. felix@3038: It can be taken as output, in which felix@3038: case the client will either request the creation of these artifacts (considering felix@3038: recommendations), or shown by the client in a the 'datacage widget', felix@3038: the graphical representation of data which can be added in the current felix@3038: context. The later is seen when the user clicks on the Datacage button in felix@3038: a diagram. felix@3038: Or information can be used to feed a second (or third...) database query. felix@3038: Following above example: felix@3038: felix@3038: felix@3038: SELECT id AS prot_id, felix@3038: description AS prot_description felix@3038: FROM wsts WHERE kind = 1 AND river_id = ${river_id} felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: SELECT id AS prot_column_id, felix@3038: name AS prot_column_name, felix@3038: position AS prot_rel_pos felix@3038: FROM wst_columns WHERE wst_id = ${prot_id} felix@3038: ORDER by position felix@3038: felix@3038: felix@3038: felix@3038: In both cases, an element makes database queries available. felix@3038: Also felix@3038: note how the variables are defined in the first query and reused in the second felix@3038: query (${prot_it}). felix@3038: felix@3038: Any alement not prefixed with "dc" represents a (sub-) node in the resulting felix@3038: tree. The client will display these nodes and maybe subnodes in the datacage felix@3038: widget - in above example. The elements name is translated by felix@3038: the client. felix@3038: felix@3038: While iterating the final results, have to be specified felix@3038: to define how the artifact is to be created. felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: felix@3038: The "name" attribute is what is to be displayed in the client, the "ids" are given felix@3038: to the server and pass important information about the chosen data. felix@3038: The "factory" is chosen according to the type of data displayed.