Mercurial > dive4elements > river
comparison flys-artifacts/doc/datacage.txt @ 3038:6a37a0134409
Added accidentally ommitted changed to datacage conf doc.
flys-artifacts/trunk@4607 c6561f87-3c4e-4783-a992-168aeb5c3f6f
author | Felix Wolfsteller <felix.wolfsteller@intevation.de> |
---|---|
date | Wed, 06 Jun 2012 11:53:55 +0000 |
parents | aba4104f41c9 |
children | eabecbdd5ade |
comparison
equal
deleted
inserted
replaced
3037:6093781582b9 | 3038:6a37a0134409 |
---|---|
1 This document describes how the datacage configuration works, from a user | |
2 perspective. Some rather technical details are omitted and mechanisms | |
3 simplified. | |
4 | |
1 The datacages behaviour is defined in the file conf/meta-data.xml . | 5 The datacages behaviour is defined in the file conf/meta-data.xml . |
2 | 6 |
3 The datacage serves two purposes. | 7 The datacage serves two purposes. |
4 It handles automatic 'recommendations', which are instructions | 8 It handles automatic 'recommendations', which are instructions |
5 sent by the client to add newly created artifacts to the collection. | 9 sent by the client to add newly created artifacts to the collection. |
20 FROM wsts WHERE kind = 1 AND river_id = ${river_id} | 24 FROM wsts WHERE kind = 1 AND river_id = ${river_id} |
21 </dc:statement> | 25 </dc:statement> |
22 | 26 |
23 As can be seen from the example, the datacage configuration file can maintain | 27 As can be seen from the example, the datacage configuration file can maintain |
24 its own stack of variables (${river_id} in above example). | 28 its own stack of variables (${river_id} in above example). |
29 | |
30 The database query will usually deliver one or many results, over which is | |
31 iterated using the <dc:elements> elements. | |
32 | |
33 Information from this results can be used for two goals. | |
34 It can be taken as output, in which | |
35 case the client will either request the creation of these artifacts (considering | |
36 recommendations), or shown by the client in a the 'datacage widget', | |
37 the graphical representation of data which can be added in the current | |
38 context. The later is seen when the user clicks on the Datacage button in | |
39 a diagram. | |
40 Or information can be used to feed a second (or third...) database query. | |
41 Following above example: | |
42 | |
43 <dc:statement> | |
44 SELECT id AS prot_id, | |
45 description AS prot_description | |
46 FROM wsts WHERE kind = 1 AND river_id = ${river_id} | |
47 </dc:statement> | |
48 <dc:elements> | |
49 <additional> | |
50 <dc:attribute name="name" value="${prot_description}"/> | |
51 <dc:context> | |
52 <dc:statement> | |
53 SELECT id AS prot_column_id, | |
54 name AS prot_column_name, | |
55 position AS prot_rel_pos | |
56 FROM wst_columns WHERE wst_id = ${prot_id} | |
57 ORDER by position | |
58 </dc:statement> | |
59 <!-- ... --> | |
60 | |
61 In both cases, an <dc:elements> element makes database queries available. | |
62 Also | |
63 note how the variables are defined in the first query and reused in the second | |
64 query (${prot_it}). | |
65 | |
66 Any alement not prefixed with "dc" represents a (sub-) node in the resulting | |
67 tree. The client will display these nodes and maybe subnodes in the datacage | |
68 widget - <additional> in above example. The elements name is translated by | |
69 the client. | |
70 | |
71 While iterating the final results, <dc:attributes> have to be specified | |
72 to define how the artifact is to be created. | |
73 | |
74 <dc:elements> | |
75 <column> | |
76 <dc:attribute name="name" value="${prot_column_name}"/> | |
77 <dc:attribute name="ids" value="additionals-wstv-${prot_rel_pos}-${prot_id}"/> | |
78 <dc:attribute name="factory" value="staticwkms"/> | |
79 </column> | |
80 </dc:elements> | |
81 | |
82 The "name" attribute is what is to be displayed in the client, the "ids" are given | |
83 to the server and pass important information about the chosen data. | |
84 The "factory" is chosen according to the type of data displayed. |