sd-Elemente zur Erstellung von Ausgabeseiten

• » Home
• »Server-Daten
• »Ausgabeseiten / sd-Elemente

1. Wohlgeformte Ausgabeseiten

Ein wesentliches Merkmal des Projekts Server-Daten besteht darin, daß die von Nutzern erstellten Tabellen und Abfragen in Html-Seiten verwendbar sind. Es können Login, Eingabe- und Suchmasken sowie die Ausgabe von Suchergebnissen exportiert werden. Zur Bereitstellung dieser Funktionalität erstellt der Nutzer im Hauptmenü eine Ausgabeseite. Bei dieser handelt es sich zunächst um eine gewöhnliche Html-Seite, die allerdings im Xml-Sinne wohlgeformt sein muß: Elemente sind korrekt zu schachteln, jedes geöffnete Element muß geschlossen werden, Attributen muß immer ein Wert in Anführungszeichen zugewiesen werden. Benannte Entities (&uuml; für ü) sind mit Ausnahme der Xml-Standard-Entities (&lt;, &gt;, &amp;, &quot;, &apos; entspricht <, >, & ", ') nicht gestattet. Es können jedoch Character-Entities (&#x00A; für das Copyright-Zeichen) oder direkt Unicode-Zeichen verwendet werden. Heutige Browser unterstützen UTF-8, so daß die ohne eine zusätzliche Deklaration in Xml unbekannten benannten Entities nicht mehr notwendig sind.

 

2. Html erweitern: sd-Elemente

Zusätzlich können Ausgabeseiten diverse sd-Elemente (server-daten-Elemente) enthalten. Sie beginnen immer mit dem Präfix sd, gefolgt von einem Doppelpunkt sowie einem vorgegebenen Namen. Sie werden wie Html-Elemente verwendet:

<sd:rs sd:source-type='table' sd:source-name='Artikel'
	sd:name='sample-output'>

	...

</sd:rs>

Zusammen mit einer Namespace-Deklaration im Html-Wurzelelement entspricht diese Verwendung den Regeln von Xml-Namespaces, so daß ein Html-Dokument mit sd-Elementen weiterhin ein wohlgeformtes Xml-Dokument ist. Jedem sd-Element entspricht eine zusätzliche, für dieses Projekt charakteristische Bedeutung. So dient das sd:rs -Element (= row-set) dazu, das Ergebnis einer Suche auszugeben, sd:input-table dient als Container zur Erstellung einer Eingabemaske für eine Tabelle, sd:result-steps liefert Buttons zum Durchblättern der Suche. Aufgrund der rekursiven Auflösung der Ausgabeseite mittels XSLT können diese Hauptelemente sowohl Html- als auch weitere sd-Elemente enthalten. Letztere sind nur im Kontext eines geeigneten Hauptelements sinnvoll: So stellt das sd:rs -Element das Ergebnis einer Tabelle bereit. Mit den beiden sd:normal - und sd:alternate -Elementen wird festgelegt, wie die ungeraden (1, 3, 5) und die geraden (2, 4, 6) Zeilen formatiert werden sollen. Das sd:cell-value -Element mit dem Attribut sd:col liefert schließlich den Wert einer einzelnen Zelle aus und ist nur im Kontext eines sd:normal - oder sd:alternate -Elements wirksam. Diese Hierarchie von Elementen, die innerhalb des Html-body-Abschnitts notiert werden können, internen Elementen, die noch keinen zusätzlichen Output liefern und Elementen, welche eine minimalisierte Ausgabe erzeugen, wird als Folge von Haupt-, Zwischen- und Schlußelementen bezeichnet. Alle sd-Elemente werden verarbeitet, so daß der erzeugte Html-Output niemals mehr sd-Elemente enthält.

 

3. Child-/Parent- und innere/äußere Elemente

In diesem Beispiel ist es sinnvoll, zwischen sd:rs und sd:normal /sd:alternate keine Html-Elemente zuzulassen. Alles, was sämtliche Zeilen aus der Datenbank gemeinsam betrifft, kann außerhalb des sd:rs -Elements festgelegt werden. Alles, was nur einen der beiden Zeilentypen betrifft, gehört in den Content dieses Elements. Für dieses Verhältnis eines sd-Elements zu seinen direkten sd-Unterelementen wurde deshalb der Begriff Child festgelegt: Zwischen einem sd-Element und seinen Child-Elementen ist kein weiterer Html-Code erlaubt. Vom unteren Element her wird das übergeordnete Element als Parent-Element bezeichnet.

 

Innerhalb des sd:normal -Elements ist es dagegen sinnvoll, beliebigen Html-Code sowie mehrere der eigentlichen Ausgabeelemente sd:cell-value zuzulassen. Einmal mag ein sd:normal definiert werden als eine Tabellenzeile <tr>, für jede Ausgabezelle wird eine zugeordnete <td> festgelegt, so daß als Ergebnis eine Html-Tabelle ausgeliefert wird. Ein anderes Mal wird gewünscht, die Datenbankzeile durch wenige <div>-Elemente sowie erläuternden Text zu gliedern. Eine dritte Ausgabe ordnet Datenbank-Zeilen als Liste und transferiert die in einer Spalte abgelegten Urls in Attribute von <a>-Elementen, so daß die Html-Darstellung als kommentierte Linkliste erscheint. Es sollen also innerhalb des sd:normal -Elements sowohl Html-Elemente als auch, an passender Stelle, sd:cell-value -Elemente zulässig sein. Letztere werden deshalb als innere Elemente in bezug auf sd:normal beschrieben. Umgekehrt hat das sd:normal -Element den Status eines äußeren Elements in bezug auf das sd:cell-value -Element.

 

4. Links ins Ausgabeseiten

Ausgabeseiten können gewöhnliche Links als a-Elemente enthalten. Links auf andere Domains beginnen wie gewohnt mit 'http'. Für Links auf andere Ausgabeseiten innerhalb derselben Subdomain ist nur zu beachten, daß diese mit einem führenden '/' beginnen. Eine Ausgabeseite

eintrag.html

kann also wie folgt verlinkt werden:

<a href='/eintrag.html'>Zur Seite Eintrag</a>

Der führende Slash ist notwendig, da der Link ansonsten bei angehängten Sortierwerten (eintrag.html/rs-output/so/1) nicht korrekt wäre. Aufgrund der Verwendung von Cookies kann der Nutzer von der Subdomain auf andere Domains wechseln und wieder zurückkehren, ohne seine Anmeldesitzung zu verlieren.

5. Hinweise zur Dokumentation

5.1 Attribute

Pflichtattribute sind mit  *  markiert. Maßgeblich ist immer der Eintrag beim Element. Denn es gibt Attribute (etwa sd:for ), welche für ein Element Pflicht, für ein anderes Element fakultativ sind. Ferner kann ein Attribut in einem Kontext wirksam, in einem anderen Kontext ignoriert werden. Das sd:for -Attribut innerhalb des sd:cell-value -Elements wird ignoriert, falls das Element im Kontext eines sd:cell-set -Elements genutzt wird. Denn dieser Kontext wird für jede Spalte einmal aufgerufen, so daß der aktuelle Spaltenname von der Laufzeitumgebung ermittelt und bereitgestellt wird. Gibt es dagegen die direkte Hierarchie sd:rs , sd:normal , so wird das letztere Element für jede Zeile einmal ausgeführt und muß für jede Spalte ein eigenes sd:cell-value -Element mit passendem Attribut bereitstellen. Ansonsten fehlt der Spaltenwert in der Ausgabe.

 

5.2 Elemente

Innere Elemente sind immer fakultativ, so daß sie niemals Pflichtelemente sind. Dies ist bsp. wichtig für sd:result-steps zum Einfügen der Links, mit welchen durch das Suchergebnis geblättert werden kann. Die Unterelemente, welche Links zum Beginn/Ende oder zum vorherigen/nächsten Ergebnis erzeugen, können zugunsten einer reinen Seitenauflistung entfernt werden. Hauptelemente können mehrfach mit demselben Bezug auf derselben Ausgabeseite eingefügt werden. So mögen zwei sd:result-steps -Elemente auf dasselbe sd:rs -Element verweisen, der eine Container gibt nur globale Links aus (Beginn, Ende, zurück, weiter), der zweite Container stellt die Seitennummern zur Verfügung.

 

Bei Child-Elementen gibt vier Möglichkeiten:

• (1): Dies ist die Kennzeichnung von Pflichtelementen, die genau einmal genutzt werden dürfen (sd:normal innerhalb von sd:rs ).
•  * : Das markiert Pflichtelemente, die einmal oder mehrfach auftreten dürfen (sd:when innerhalb von sd:choose oder sd:choose-lang - es muß mindestens eine Prüfung geben, es dürfen jedoch auch mehr sein).
• (0/1): Die so markierten Elemente können kein oder einmal genutzt werden (sd:alternate im sd:rs oder sd:otherwise im sd:choose ).
• (0 - *): Diese Elemente können fehlen oder mehrfach verwendet werden. Eine solche Verwendung für Child-Elemente ist derzeit nur für das sd:with-param -Element innerhalb von sd:rs erlaubt. Mit diesem Element können einer benutzerdefinierten Abfrage keine oder mehrere Sql-Parameter übergeben werden.

5.3 Content

Elemente, welche in ihrem Content innere Elemente zulassen, erlauben zusätzlichen Text, also '#PCDATA' im Xml-Sinn. Dieser Text wird statisch in die eigentliche Html-Ausgabe übernommen. Im Regelfall sind in solchen Elementen auch ergänzende Elemente gestattet, so daß das sd:choose-lang -Element für Sprachverzweigungen zur Verfügung steht. Damit läßt sich an einer Position Text nicht hart deklariert einsprachig, sondern mehrsprachig in Abhängigkeit von der Sprache des Clientbrowsers ausgeben. Eine erweiterte Technik besteht darin, solche Sprachverzweigungen in externe Libraries auszulagern und sie mittels sd:call-template in die aktuelle Seite einzubinden. Damit ist es möglich, in vielen Ausgabeseiten dieselben Beschriftungen zu nutzen, ohne diese redundant in jeder Ausgabeseite neu definieren zu müssen.

5.4 Html-Attribute

In wenigen, durch den Zusatz Html-Attribute erlaubt markierten sd-Elementen sind, zusätzlich zu den sd-Attributen, die offiziellen Html-Attribute erlaubt. Diese sd-Elemente fügen der Ausgabe vordefinierte Html-Elemente hinzu. Die bei den sd-Elementen gefundenen Html-Attribute werden an diese Html-Elemente weitergereicht und stellen eine Möglichkeit dar, die Html-Elemente zu formatieren.

5.5 Möglichkeiten und Grenzen der Validierung der Ausgabeseite

Bei der Speicherung einer Ausgabeseite wird zunächst geprüft, ob es sich bei der Seite um eine wohlgeformte Xml-Datei handelt. Da es nicht sinnvoll ist, Nutzern eine Html-Version (4.0, 4.01, XHtml.1.0, XHtml.1.1) vorzugeben, werden Html-Elemente und -Attribute einschließlich der in sd-Elementen erlaubten Html-Attributen nicht weiter geprüft. Stattdessen werden in einem zweiten Schritt alle Html-Elemente entfernt und der verbleibende Code auf die Regeln von sd-Elementen überprüft. Enthält die Ausgabeseite Kombinationen von sd-Elementen, welche den in der Dokumentation aufgestellten Regeln widersprechen, so ist ein Speichern nicht möglich. Bei erlaubten Html-Attributen wird nur geprüft, ob die Attribute ohne Namespace-Präfix notiert sind. Enthält die Ausgabeseite Html-Elemente an Stellen, an welchen dies nicht gestattet ist, so kann dies (trotz Verwendung einer XmlSchema-Datei) nicht mehr getestet werden. Der Fehler zeigt sich später jedoch darin, daß nicht die erwartete Ausgabe erzeugt wird. Dies gilt bsp. dann, falls im sd:rs -Element Html-Elemente anstelle sd:normal /sd:alternate genutzt werden. Die im Hintergrund durchgeführte Transformation versucht, die direkten Child-Elemente aufzurufen, deren Fehlen erzeugt - im Sinne der Xsl-Logik - keinen Fehler, sondern nur eine leere Ausgabe. Analog werden verbotene Html-Elemente in Schlußelementen bei der Komprimierung auf die sd-Elemente entfernt. Also fallen sie bei der Validierung nicht mehr auf. Bei der Ausgabe werden sie jedoch ignoriert, da die interne Verarbeitung der Schlußelemente deren Content nicht mehr rekursiv weiterverarbeitet.

 

Ist ein öffnendes sd-Element fehlerhaft notiert worden und gab es denselben Schreibfehler beim schließenden Element, so werden zwei Fehlermeldungen ausgegeben: Das übergeordnete Element habe ein fehlerhaftes untergeordnetes Element und das - fehlerhaft notierte - Element sei nicht deklariert worden. Die zweite Fehlermeldung kann ignoriert werden, da es keine benutzerdefinierten sd-Elemente gibt.

 

Mittels key-Elementen in der XmlSchema-Datei wird bei sd:name-Attributen sowohl die globale als auch die elementspezifische Eindeutigkeit dieses benutzerdefinierten Elementnamens geprüft. Ferner wird mittels des keyref-Elements (einer Fremdschlüssel-Einschränkung innerhalb der XmlSchema-Datei) getestet, ob Attribute, welche auf sd:name-Attribute eines gewissen Typs verweisen, einen korrekten Wert haben. So muß das sd:source -Attribut innerhalb des sd:button -Elements denselben Wert haben wie das sd:name -Attribut eines sd:input-table -Elements. Damit legt der Ersteller der Ausgabeseite fest, daß das sd:input-table -Element als Quelle für die Aktionen dieses Buttons dient. Ist der Wert des sd:source -Attributs in diesem Sinne ungültig, ist also der angegebene Ausdruck nicht gleich einem Namen eines passenden Objektes, so scheitert das Speichern der Ausgabeseite.

6. Hinweise zum Selbststudium

Die Fülle der sd-Elemente mag zunächst einschüchternd erscheinen. Ihre Vielfalt erklärt sich so: Aufgrund der rekursiven Auflösung können alle Ebenen (bsp. Tabelle - Zeile - Spalte) voneinander getrennt werden. Gleichzeitig werden zusätzliche eigene Ebenen benötigt, um bsp. ungerade/gerade Tabellenzeilen voneinander zu unterscheiden. Damit dürfen an solchen Stellen keine Html-Elemente eingefügt werden. An allen anderen Stellen soll jedoch die maximale Gestaltungsfreiheit in Form von beliebig einschiebbarem Html-Code erhalten bleiben.

 

Für den Anfang sind die folgenden fünf Hauptelemente wesentlich:

• sd:rs : Stammelement für die Ausgabe einer Tabelle/Abfrage
• sd:result-steps : Stammelement für die Links zum Durchblättern einer Ergebnisliste
• sd:input-table : Stammelement für die Eingabemaske
• sd:button : Button zum Suchen/Speichern/Reset
• sd:switch-link : Link bzw. Button für einen neuen Datensatz oder zum Löschen des editierten Datensatzes

Für das Durchblättern der Ergebnislisten sind dem sd:result-steps -Element bsp. neun weitere Elemente zugeordnet - Beginn/Ende, Vorwärts/Rückwärts, ein Containerelement für die Zahlliste mit zwei Unterelementen für die aktuelle und die anderen Seiten sowie ein Element für den Link und ein Element für die eigentliche Zahl. Für die Formatierung einer Eingabemaske sind innerhalb des sd:input-table -Elements insgesamt 13 Unterelemente zulässig.

 

Für diese Grundelemente kann mittels der Vorlagen Beispielcode erzeugt werden, anhand dessen der hierarchische Aufbau rasch deutlich werden dürfte.

 

Ferner gibt es einige Elemente, welche Verzweigungen gestatten. Sie ermöglichen es, daß dieselbe Ausgabeseite, in Abhängigkeit von zusätzlichen Bedingungen, verschiedenartig ausgegeben wird. Mit Ausnahme des sd:ignore -Elements sind diese Fälle jedoch so speziell, daß sie nicht mehr mit Vorlagen erzeugt werden können. Hier ist die Nutzung der Dokumentation unerläßlich.