Mercurial > dive4elements > river
comparison flys-artifacts/doc/datacage.txt @ 3041:eabecbdd5ade
More datacage conf doc.
flys-artifacts/trunk@4610 c6561f87-3c4e-4783-a992-168aeb5c3f6f
| author | Felix Wolfsteller <felix.wolfsteller@intevation.de> |
|---|---|
| date | Wed, 06 Jun 2012 12:19:19 +0000 |
| parents | 6a37a0134409 |
| children |
comparison
equal
deleted
inserted
replaced
| 3040:79d1db7797e6 | 3041:eabecbdd5ade |
|---|---|
| 80 </dc:elements> | 80 </dc:elements> |
| 81 | 81 |
| 82 The "name" attribute is what is to be displayed in the client, the "ids" are given | 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. | 83 to the server and pass important information about the chosen data. |
| 84 The "factory" is chosen according to the type of data displayed. | 84 The "factory" is chosen according to the type of data displayed. |
| 85 | |
| 86 So far, three other elements have not yet been mentioned: <dc:comment>, | |
| 87 <dc:if> and the <dc:when><dc:otherwise> structure. | |
| 88 <dc:comment> is an element to allow comments. Choose these over standard | |
| 89 <!-- --> xml comments, because they are not transferred to the client. | |
| 90 <dc:if> and <dc:when> allow control (rather: definition) flow within | |
| 91 the configuration and work in analogy to the XSL-elements <xsl:if> | |
| 92 and <xsl:when>. | |
| 93 | |
| 94 When dealing with the behaviour specification of the datacage, multiple | |
| 95 interpretations for the term "context" are possible. | |
| 96 A <dc:context> element essentially means a database binding. Thus each | |
| 97 query (<dc:statement>) needs to be nested in its own context. | |
| 98 Furthermore, two types of databases with own bindings exist: | |
| 99 The "system" (default for <dc:context>, <dc:context connection="system">) | |
| 100 context allows queries related to the backend database with existing | |
| 101 data (e.g. measurements). | |
| 102 The "user" context (<dc:context connection="user">) allows queries against | |
| 103 the database which stores information about already existing artifacts and | |
| 104 calculations. | |
| 105 | |
| 106 Another connotation for the term "context" is the situation from which | |
| 107 the datacage is queried. The standard case is a from the datacage widget. | |
| 108 When the user opens the datacage from the graphical client, this is done | |
| 109 from one of possible multiple diagrams. | |
| 110 When the datacage is queried, it gets as an argument the "out" of | |
| 111 the current artifact. The out corresponds to the diagram type. | |
| 112 | |
| 113 For example the inner block of | |
| 114 | |
| 115 <dc:if test="dc:contains($artifact-outs, 'longitudinal_section')"> | |
| 116 <longitudinal_section> | |
| 117 <dc:call-macro name="annotations"/> | |
| 118 </longitudinal_section> | |
| 119 </dc:if> | |
| 120 | |
| 121 will only be executed if called from the datacage within a | |
| 122 longitudinal_section diagram. | |
| 123 | |
| 124 In the given example another concept of the datacage configuration is | |
| 125 encountered: Macros. | |
| 126 | |
| 127 Macros help to avoid duplication of parts of the document. As the datacage | |
| 128 of some diagrams should include the same type of data, the same query should | |
| 129 be executed in multiple situations. | |
| 130 | |
| 131 Therefore a macro can be defined, like in | |
| 132 | |
| 133 <dc:macro name="basedata_4_heightmarks-wq"> | |
| 134 <heightmarks> | |
| 135 <dc:context> | |
| 136 <dc:statement> | |
| 137 SELECT id AS prot_id, | |
| 138 description AS prot_description | |
| 139 FROM wsts WHERE kind = 4 AND river_id = ${river_id} | |
| 140 </dc:statement> | |
| 141 <dc:elements> | |
| 142 <!-- ... --> | |
| 143 </dc:macro> | |
| 144 | |
| 145 and invoked from another location within the document, e.g. with | |
| 146 | |
| 147 <dc:call-macro name="basedata_4_heightmarks"/> | |
| 148 . |