MasterDetailPlan:
DataExecutionPlan:
Die eigentliche Datenbeschaffung erfolgt über ein Master-/Detail-Dokument. Die Verarbeitung erfolgt pro Datensatz (nennen wir es hier Dokument) aus dem Hauptdatensatz (Master).
Die "Detail" Elemente können verschachtelt werden. Es gibt abhängige (Dependend) und unabhängige (Independend) Detail-Elemente.
Generiert wird daraus ein XML Dokument, die Elemente entsprechen den Feldnamen. Für Testszwecke kann dieses hier mit der Option "Xml" untransformiert ausgegeben werden.
Das XML Dokument hat immer den Aufbau:
ButtonRow
+ ButtonOptions xmlns="http://schemas.webs.idu.de/cardo3/Button
+ ExcecutionPlanOption xmlns=""
+ ExcecutionPlanOption xmlns=""
+ xmlElementName {xmlElementName aus ButtonMasterDetailDocument
+ Detail ...
--->>> aus beiden zusammen wird bei der Planausführung xml, html und pdf generiert.
case sensitiv!
Standardnamespaces:
xmlns="http://schemas.webs.idu.de/cardo3/Button"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://webs.idu.de/xsdschemas/Cardo/Button/Button.xsd"
weitere Namespaces:
xmlns:iXHR="http://schemas.webs.idu.de/iwan/iXRH"
xsi:schemaLocation="iXRH http://webs.idu.de/xsdschemas/Iwan/iXRH.xsd"
--> ExecutionPlan: Definition der Schemata, Start der Planausführung
--> ButtonMasterDetailDocument
--> MasterRecord
--> DatabaseQuery
--> InternalAlias: Alias, der bei der Einrichtung der Datenbankverbindung vergeben wurde (siehe folgende Abbildung)
--> BaseQuery: SQL Abfrage
Festlegung von Parametern, die die Abfrage begrenzen oder hinsichtlich Ausgabeformat konkretisieren. Sie beschreiben die Eigenschaften des Plans und werden von der Oberfläche der Ausführung ausgewertet. Sie werden vor dem ButtonMasterDetailDocument in das xml eingebunden. Dies können sein:
Erläuterung zum Beispiel
--> Author: Ersteller des Plans
--> Description: Beschreibung des Plans
(weitere Elemente siehe Beschreibung oben)
--> Arguments: Startparameter für den Plan
--> Webservice
Einzubinden im Xslt mit der Deklaration xmlns:cardoButton="eo:cardoButton"
Hinweis: In XML muss alles als Baum abbildbar sein!
Verknüpfung von Ausdrücken mit AND oder OR
Beispiel:
Tag-Standardname ‚Row‘ kann über das Attribut ‚xmlElementName‘ geändert werden
Achtung: linker Wert eines Vergleichs muss immer ein Einzelwert sein, soll z.B. ein Array-Parameter verglichen werden, muss dieser immer auf der rechten Seite des Ausdrucks stehen.
Bei den abhängigen Details wird die Variable %PARENT_ID_VALUE% zur Ersetzung im Sql vom System bereitgestellt
Da Verknüpfung 1:n sein kann, immer Collection-Tag (hier Datum) und darin n Element-Tags (hier MassnahmeExposeData)!
Nachfolgend soll gezeigt werden, wie das Planergebnis über eine Verschneidung mit einer vorgegebenen Geometrie (z.B. Freihandgeometrie aus dem GIS-Viewer) ermittelt werden kann.
Definition des Parameters für die Filtergeometrie:
Wird als Datenquelle eine Datenbank-Tabelle mit Geometriespalte verwendet, muss darauf geachtet werden, dass die Geometriespalte in der cardo-Projektprojektion vorliegt oder gegebenenfalls in diese Projektion transformiert wird.
Beispiel:
Erläuterung:
Im Beispiel (Postgres) liegt die Geometriespalte der Tabelle km_meta.bl25_sa in GK4 vor, die cardo-Projektion ist aber auf GK5 eingestellt. Deswegen wird hier die Spalte vor der Abarbeitung des Plans explizit in die cardo-Projektion transformiert. Das ist nötig, da aus der Geomtriespalte der Datenbank die Projektion nicht eindeutig ermittelt werden kann und damit keine automatische Transformation erfolgen kann.
Verwenden Sie als Datenquelle eine cardo-Ebene, dann ist die Projektion bekannt und es findet gegebenenfalls eine automatische Transformation statt.
--> gibt alle Fotos zurück, die innerhalb der definierten Geometrie liegen
Hinweis: Filter immer nach den Detail Plänen
--> Rückgabe aller Fotos innerhalb der Nutzergeometrie, die im Naturschutzgebiet und zusätzlich im Trinkwasserschutzgebiet liegen
Referenz auf diese Datenquelle über die interne ID
DataExecutionPlan:
Prozessor
Zwischentabellen:
Ergebnis: Erstellung eines Datenblattes zu einem Radweg, auf welchem neben den Daten zum Radweg auch alle Ärzte in einem bestimmten Umkreis, alle LSG’s, welche berührt werden und die Teillänge des Radweges, welche durch die LSG führt, ausgegeben wird.
Die Kommentare entnehmen Sie bitte dem Beispiel XML.
Ergebnis XML:
Am Pdf-Tag kann als Attribut die Orientierung und als Untertags die Papiergröße (WellKnownPageSize
) und Seitenrand (MarginMm
mit einem Wert für alle Seiten oder Margins
mit Attributen für jede Seite) angegeben werden. Soll die Papiergröße frei definiert werden, kann diese über den Tag PageSize
mit Breiten- und Höhenangabe definiert werden.
Allerdings ist es nicht möglich, hier auf die vom Benutzer abgefragten Argumente zuzugreifen, so dass die Auswahl von Orientierung und Format an dieser Stelle nicht dynamisch erfolgen können. Um dies zu erreichen können die Erweiterungsfunktionen aus eo:iduPdf verwendet werden. In der Transformation besteht über das Ergebnis-XML Zugriff auf die vom Benutzer abgefragten Argumente.