Das MyCoRe-Editor-Framework

Funktionalität

Das Metadatenmodell einer MyCoRe Anwendung ist frei konfigurierbar. Dementsprechend benötigt ein MyCoRe System auch einen Online-Editor für diese Metadaten, der frei konfigurierbar ist. Aus dieser Anforderung heraus entstand das MyCoRe Editor Framework, das aus einem XSL Stylesheet und einer Menge von Java-Klassen besteht.

Verschiedene MyCoRe Anwendungen können über XML-Definitionsdateien nahezu beliebige Online-Eingabemasken für Metadaten gestalten. Das Framework verarbeitet diese Editor-Definitionsdateien und generiert daraus den HTML-Code der Webseite, die das Online-Formular enthält. Nach Abschicken des Formulars generiert das Framework aus den Eingaben ein dem Metadatenmodell entsprechendes XML-Dokument, das an ein beliebiges Servlet zur endgültigen Verarbeitung (z.B. zur Speicherung) weitergereicht wird. Ebenso können existierende XML-Dokumente als Eingabe in die Formularfelder des Editors dienen, so dass sich vorhandene Metadaten bearbeiten lassen. Das Framework regelt dabei die Abbildung zwischen den XML-Elementen und –Attributen und den Eingabefeldern der resultierenden HTML-Formularseite, indem es die in der Editor-Definitionsdatei hinterlegten Abbildungsregeln verarbeitet.

Inzwischen ist das Editor Framework auch in der Lage, einzelne Dateien zusammen mit den Formulareingaben in das System hochzuladen und zur Weiterverarbeitung an ein Servlet durchzureichen. Die Validierung der Eingabefelder ist strukturell vorbereitet, aber derzeit noch nicht implementiert. Prinzipiell erlaubt das Editor Framework, beliebige XML-Dokumente in HTML-Formularen zu erzeugen oder zu bearbeiten.

Architektur

Die folgende Abbildung zeigt die Architektur des MyCoRe Editor Frameworks:

[ToDo]: Bild folgt

Ein HTML Formular, das man mit Hilfe des Frameworks realisieren möchte, wird im folgenden Editor genannt. Jeder Editor besitzt eine eindeutige ID (z.B. document (in den MyCoRe-Applikationen meist eine Mischung aus dem MCRObjectID-Typ und der Bezeichnung eines Verarbeitungsschrittes [editor-commit-document.xml]). und eine Definitionsdatei im XML-Format (editor-document.xml). In dieser Definitionsdatei ist festgelegt, aus welchen Eingabefeldern in welcher optischen Anordnung der Editor besteht und wie die Abbildung zwischen den Eingabefeldern und der zugrunde liegenden XML-Darstellung der Daten aussieht.

Ein Editor ist üblicherweise in eine umgebende Webseite eingebunden, die das Formular enthält. Die umgebenden Webseiten referenzieren über die Editor ID den Editor, der an einer bestimmten Stelle der sichtbaren Webseite eingebunden werden soll. Der HTML-Code der Webseite selbst wird in einem MyCoRe System aus einem beliebigen XML-Dokument (z.B. anypage.xml [z.B. editor_form_...xml in DocPortal]) mittels eines dazu passenden XSL Stylesheets (anypage.xsl [z.B. MyCoReWebPage.xsl in DocPortal]) generiert. Um in eine solche Webseite einen Editor integrieren zu können, muss anypage.xml ein XML-Element enthalten, das auf den einzubindenden Editor verweist, zusätzlich muss anypage.xsl das Stylesheet editor.xsl einbinden. Das Stylesheet verarbeitet die Referenz auf den Editor und integriert den HTML-Code des Formulars in die umgebende Webseite. So ist es möglich, Editor-Formulare in beliebige Webseiten einzubinden, unabhängig von ihrem Layout oder ihrer Struktur.

Editor einbinden

Abbildung 2.10: Einbindung des Editors in eine Webseite

Das Stylesheet editor.xsl aus dem Framework verarbeitet die Definition in editor-document.xml und erzeugt daraus eine HTML-Tabelle mit den entsprechenden Beschriftungen und Formularfeldern für die Eingabe der Metadaten. Es lassen sich jedoch nicht nur neue Daten eingeben, auch existierende Metadatenobjekte können bearbeitet werden. Das Stylesheet kann dazu von einer beliebigen URL ein XML-Dokument einlesen, verarbeitet dieses dann entsprechend den Abbildungsregeln aus editor-person.xsl und füllt die Eingabefelder des Formulars mit den Inhalten der XML-Elemente und –Attribute.

Wenn der Benutzer im Browser die Eingaben in die Formularfelder getätigt hat und das Formular abschickt, werden die Eingaben durch das Servlet MCREditorServlet aus dem Framework verarbeitet. Das Servlet generiert aus den Eingaben ein XML-Dokument, entsprechend den Regeln aus editor-document.xml. Dieses XML-Dokument wird anschließend an ein beliebiges anderes Servlet weitergereicht, welches in der Formulardefinition angegeben ist und welches dann die Daten endgültig verarbeiten kann und z.B. das XML-Dokument als MyCoRe Metadaten-Objekt speichert.

MCREditorServlet übergibt dabei dem Ziel-Servlet (z.B. AnyTargetServlet) ein Objekt vom Typ MCREditorSubmission, das nicht nur das XML-Dokument, sondern auch eventuell gemeinsam mit den Formulardaten übertragene Dateien als InputStream enthält. Damit ist es möglich, auch einfache Datei-Upload-Formulare über das Editor Framework zu realisieren.

Das Ziel-Servlet erhält zusätzlich auch die ursprünglichen HTTP Request Parameter aus dem abgeschickten Formular, so dass es bei Bedarf auch direkt auf die Werte bestimmter Eingabefelder zugreifen kann und nicht zwingend unbedingt das resultierende XML-Dokument beachten muss. Dadurch ist es möglich, das Editor Framework auch mit bereits existierenden Servlets zu nutzen, die bisher keine XML-Dokumente als Eingabe verarbeiten. Das Framework ist daher auch in der Lage, die Eingaben an eine beliebige URL statt an ein Servlet zu senden, so dass das Ziel der Eingaben an sich auch ein externes CGI-Skript oder ein Servlet in einem entfernten System sein könnte. Das schafft ein hohes Maß an Flexibilität, durch das das Editor Framework auch genutzt werden kann, um z.B. Suchmasken oder Login-Formulare zu erzeugen. Die Nutzung ist nicht allein auf die Realisierung von Metadaten-Editoren beschränkt.

Beschreibung der Editor-Formular-Definition

Die Grundstruktur

Im Folgenden soll die Gestaltung eines Editor-Formulars näher beschrieben werden. Als Beispiel ist ein Formular für ein Dokument gedacht. Die Daten werden z.B. in der Datei editor-document.xml gespeichert.

Editor Rahmen

Abbildung 2.11: Rahmen der Formular-Definition

Als nächstes definieren wir die Eingabefelder des Editors. Ein Editor besteht aus verschiedenen Komponenten, die innerhalb des Elements components deklariert werden. Dies können einfache Komponenten z.B. für Auswahllisten und Texteingabefelder sein, oder aber zusammengesetzte Panels, mit deren Hilfe man einfache Komponenten in einer Tabellengitterstruktur anordnen kann. Panels können wiederum andere Panels beinhalten, so dass sich komplexere Layouts erzeugen lassen. Jede Komponente besitzt eine innerhalb des Editors eindeutige ID, über die sie referenziert werden kann. Jeder Editor besitzt ein Root-Panel, die äußerste Struktur, mit der die Anordnung der Komponenten begonnen wird. Die ID dieses Root-Panels wird als Attribut im Element components angegeben.

Root-Panel

Abbildung 2.12: Definition eines einfachen Formulares

Innerhalb eines Panels lassen sich andere Komponenten oder Panels anordnen. Solche Komponenten werden im einfachsten Fall einfach in die Gitterzellen eines Panels eingebettet. Jede Zelle entspricht einem cell-Element innerhalb des Panels. Jede Zelle besitzt eine row- und col-Koordinate, mit deren Hilfe die Zelleninhalte von links nach rechts in Spalten (col) und von oben nach unten in Zeilen (row) angeordnet werden. Dabei ist für Textfelder noch die Angabe der Sprache möglich.

Innerhalb der Gitterzellen füllen die Komponenten in der Regel nicht den gesamten Platz aus, daher können sie in ihren Zellen mittels des anchor-Attributs anhand der Himmelsrichtungen (NORTH, NORTHEAST, EAST, ... bis CENTER) angeordnet werden. Wir ordnen die Beschriftungen rechtsbündig, die Texteingabefelder linksbündig an. Außerdem wird nun in der untersten rechten Zelle rechtsbündig ein "Speichern" Button zum Absenden des Formulars ergänzt.

Root-Panel-Auslagerung

Abbildung 2.14: Auslagern von Definitionen aus dem Root-Panel

Im nächsten Schritt soll nun die Definition aus dem Root-Panel ausgegliedert werden. Sie verwenden dazu ein eigenes Panel. Diese Technik wird verwendet, um Panels mehrfach zu nutzen und den Quellcode des Formulars zu strukturieren. Dabei wird gezeigt, wie sich Panels untereinander aufrufen (Abbildung 2.14).

Soll das Panel form nun mehrfach genutzt werden,z.B. in mehreren Formularen, so ist es sinnvoll das Panel in eine gemeinsame Definitionsdatei imports-common.xml auszulagern. Im eigentlichen Formular wird dann nur noch auf das form-Panel verwiesen. Die Einbindung der ausgelagerten Panels erfolgt mit der include-Anweisung (Abbildung 2.15). Die einzufügende Datei (Abbildung 2.16) wird nun im System mittels EntityResolver gesucht und eingebunden. Auf diese Weise lassen sich elegante und wartungsarme Formulare gestalten.

Editor-Auslagerung

Abbildung 2.15: Auslagern von Definitionen aus dem Editor-Formular

imports

Abbildung 2.16: Die imports-Formular-Definition

Abbildung zwischen Eingabefeldern und XML-Strukturen

Als nächstes definieren wir, wie die Eingabefelder auf XML-Elemente abgebildet werden. Dies geschieht über das Attribut var verschiedener Elemente der Editor-Definition. Zunächst wird im var-Attribut des components-Elements der Name des Root-Elements der XML-Darstellung (document) festgelegt. Die Abbildung zwischen Eingabefeldern oder Panels und ihrer Zuordnung zu XML-Elementen geschieht über das var>-Attribut in den cell-Elementen, welche die Eingabekomponente enthalten (Abbildung 217).

XML-Main-Tag-Namen

Abbildung 2.17: Einfügen des XML-Main-Tag-Namen

Es gibt für Tags und Attribute innerhalb der Root-Komponente verschiedene Möglichkeiten der Gestaltung des Ausgabe-XML-Baumes. Die einfachste Art ist die direkte Zuordnung. Hier werden die Werte des Eingangs-XML-Files dem Feld in der Editormaske zugeordnet. Weiterhin kann dem Feld noch ein Standardwert durch das Attribut default mitgegeben werden. Zudem können Felder, welche von der Dateneingabe ausgenommen werden sollen, deren Inhalte aber an die Ausgabeseite durchgereicht werden sollen, als hidden-Felder mitgeführt werden. Auch hier können Standardwerte angegeben werden, welche eingesetzt werden, wenn keine Daten für das Tag/Attribut vorhanden sind.

XML-Tag Integration

Abbildung 2.18: Integration von einfachen XML-Tags

Sollten Sie mehrere gleiche XML-Strukturen im Editor zur Bearbeitung anbieten wollen, so wird dies über eine Integer-Zahl in Klammer organisiert. Achtung, es werden immer nur soviel XML-Elemente übernommen und an die Ausgabe weitergereicht, wie angegeben sind. Um eine beliebige Anzahl zu präsentieren und zu bearbeiten nutzen sie die weiter unten angegebene Möglichkeit des Repeaters. Für hidden-Felder gibt es noch die Variante, mittels des descendants="true" - Attributs alle Kindelemente, Attribute und Wiederholungen des Elementes an die Ausgabe durchzureichen.

XML-Tag Integration

Abbildung 2.19: Integration von mehrfachen XML-Tags

Wenn das zu bearbeitende Quell-XML-Dokument oder das Zieldokument Namespaces verwendet, können die Werte der var-Attribute auch Namespace-Prefixes enthalten. Dazu müssen sämtliche Namespaces in der Editor-Definition im Element components als zusätzliche Namespaces mit ihrem Prefix registriert werden. Wird in einem var-Attribut ein Namespace-Prefix verwendet, das hier nicht deklariert ist, oder erfolgt die Deklaration an einer anderen Stelle, führt dies zu einem Verarbeitungsfehler! Ein Beispiel:

     
       <components root="/mycoreobject" xmlns:xlink="http://www.w3.org/1999/xlink">
         ...
         <cell row="1" col="1" var="@xlink:href">
           ...
         </cell>
         ...
       </components>
     
     

Integration und Aufruf des Editor Framework

Bereits am Anfang des Kapitels wurde eine einfache Syntax zum Aufruf des Editor Framework vorgestellt. Dieser Abschnittinformiert umfassend zu diesem Thema.

Editor einbinden

Abbildung 2.20: Einbindung des Editors in eine Webseite

Das Editor Framework ist so konzipiert, dass es als XML-Sequenz in einer durch das MCRLayoutServlet darzustellenden Webseite integriert werden kann. D.h. Sie erstellen eine XML Seite, welche durch das Servlet und die zugehörigen XSLT-Stylesheets nach HTML konvertiert wird. Durch den Import (include) der Editor-Framework-XSL-Dateien in das Layout zum Erzeugen der HTML-Seiten ermöglichen Sie die Einbindung ihrer Editor-Formulare. In der oben gezeigten XML-Sequenz wird jedoch nur die Definitionsdatei des Formulars beschrieben: „nimm aus der Web-Applikation die Datei editor-document.xml aus dem Verzeichnis editor“. Dabei ist noch nichts über die Datenquelle bekannt. Hierfür existieren noch einige Parameter, welche durch das Framework ausgewertet werden. Diese können sowohl direkt im Browser in der Aufrufsequenz oder über Parametereinstellungen in einem Servlet mitgegeben werden.

http://.../document.xml?XSL.editor.source.new=true&type=...

Oder in einem Servlet als Codestück, wie Abbildung 2.21 zeigt.

Codesequenz

Abbildung 2.21: Codesequenz zum Aufruf des Editor Framework

Start-Parameter für das Lesen der zu bearbeitenden XML-Quelle:

Über Request Parameter kann beim Aufruf des Editors gesteuert werden, ob bzw. aus welcher Quelle die zu bearbeitenden XML-Daten gelesen werden. Die zu bearbeitenden XML-Daten werden von einer beliebigen URI gelesen, die durch den MyCoRe URI Resolver unterstützt wird, z. B. mcrobject:[ID] um die Metadaten eines MyCoRe Objektes einzulesen, oder webapp:[Pfad], um eine statische XML-Datei aus der Web Applikation einzulesen.

In der Editor-Definition gibt man dazu ein oder mehrere URIs an, die als Quelle gelesen werden. Wenn keine Source URI definiert wird, startet das Formular leer. In der Regel werden die URIs ein oder mehrere Platzhalter für Parameter enthalten, die beim Aufruf durch HTTP Request Parameter ersetzt werden. Die erste Source URI, bei der alle Parameter durch den Aufruf ersetzt werden können, wird verwendet. Man kann auch die gesamte URI als Parameter übergeben, d.h. eine Source URI definieren, die nur aus einem Parameter besteht. Dazu einige Beispiele:

<source uri="{sourceUri}" />
liest die zu bearbeitende XML-Quelle aus dem HTTP Request Parameter sourceUri, wenn dieser der bei Aufruf übergeben wird.
<source uri="mcrobject:{mcrId}" />
liest die Metadaten eines MyCoRe-Objektes als zu bearbeitende XML-Quelle. Die ID wird als Request Parameter mcrId übergeben.
<source uri="webapp:templates/document.xml" />
liest die statische XML-Datei document.xml, die im Verzeichnis templates der Web-Applikation hinterlegt ist.
Start-Parameter für die Definition des Abbrechen-Buttons:

Diese Parameter werden im Abschnitt zur Verwendung eines Cancel-Buttons (Abbrechen-Knopf) erläutert, sie steuern die URL, zu der bei Klick auf einen „Abbrechen“ Button zurückgekehrt wird. Auch hier ist die Verwendung von Request Parametern in der URL möglich.

Start-Parameter für die Weitergabe an das Zielservlet:

In der Regel werden die Eingaben nach der Bearbeitung mit dem Editor an ein Zielservlet gesendet (target type="servlet"). Man kann diesem Zielservlet auch HTTP Parameter mitschicken, die der Editor bei Abschicken des Formulars mitsendet. So können Informationen an das Zielservlet weitergegeben werden, die nicht Teil des zu bearbeitenden XML-Dokumentes sind, z.B. die Information, ob es sich um einen Update- oder Create-Vorgang handelt, die Objekt-ID etc. Der Editor reicht automatisch alle HTTP Request Parameter an das Zielservlet durch, deren Name nicht mit XSL beginnt.

Beispiel:http://.../editor-document.xml?XSL.editor.source.id=4711&
action=update&mode=bingoBongo

Ausgabeziele

Das Editor-Framework ist auch hinsichtlich der Verarbeitung der entstandenen Daten flexibel konfigurierbar. Wie bereits erwähnt, wird nach dem Betätigen des Submit-Buttons das MCREditorServlet für eine erste Verarbeitung angestoßen. Diese reicht die Daten dann an ein weiteres konfigurierbares Ziel weiter. Welches das ist, wird mit der target-Zeile in der Formulardefinition festgelegt. Das Attribut method definiert, ob dazu HTTP GET oder POST verwendet wird. Zu empfehlen ist in der Regel immer POST, was auch der Default-Wert ist und zwingend bei File Uploads gesetzt wird. Möglich ist:

  • die Ausgabe als HTML-Seite zum Debugging des Ergebnisses:
    <target type="debug" method="post" format="xml" />,
  • die Weiterleitung der Daten in ein nachgeschaltetes Servlet im XML-Format:
    <target type="servlet" method="post" name="MCRCheckDataServlet" format="xml" />,
  • die Weiterleitung der Daten an ein nachgeschaltetes Servlet in der Form name=value, d. h. ohne Generierung eines XML-Dokumentes:
    <target type="servlet" method="post" name="MCRCheckDataServlet" format="name=value" />,
  • die Weiterleitung an das LayoutServlet zur Anzeige des generierten XML-Dokumentes als Test:
    <target type="display" method="post" format="xml" />.

    Target

    Abbildung 2.22: Rahmen der Formular-Definition


  • die Weiterleitung an eine beliebige URL als HTTP GET oder POST Request:
    <target type="url" method="post" format="name=value" url="cgi-bin/ProcessMe.cgi" /> oder
  • die Weiterleitung an einen anderen Editor, für den dieser Editor als „Subdialog“ fungiert. Dies wird in einem separaten Abschnitt erläutert.
    <target type="subselect" method="post" format="xml" />

Mit der nachfolgenden Java-Code-Sequenz kann nun auf die vom MCREditorServlet durchgereichten XML- und -File-Daten zugegriffen werden.

Java

Abbildung 2.23: Java-Code-Sequenz für den Zugriff


Neben der Übernahme der Ausgabewerte des MCREditorServlets als XML-Baum können diese auch in der Form 'name=value' durchgereicht werden. Hierzu müssen u. a. die var-Attribute entsprechend in eine einfache Form gebracht werden. Der Ausschnitt der Editor-Definition soll das verdeutlichen.

Rahmen Editor

Abbildung 2.24: Rahmen der Formular-Definition mit name=value

Syntax der Formularelemente

Aufbau einer Zelle

Das cell-Element stellt ein elementares Gebilde innerhalb eines Formulargitters dar. Seine Position wird durch die Attribute col, row und anchor beschrieben. col gibt dabei die relative Spaltenzahl, row die relative Zeilenzahl an. Mit anchor kann die Ausrichtung gesteuert werden. Mögliche Werte sind hier NORTHWEST, NORTH, NORTHEAST, WEST, CENTER, EAST, SOUTHWEST, SOUTH und SOUTHEAST. Mit dem Attribut ref kann auf ein mehrfach verwendbares Element via ID referenziert werden. Über das Attribut sortnr kann die Reihenfolge der zu generierenden XML-Daten für die Ausgabe geregelt werden. Dieses Attribut bezieht sich dabei auf das gesamte Formular.

Syntax

Abbildung 2.25: Syntax des cell-Elements

Texteingabefelder

Ein einzeiliges Texteingabefeld wird mittels eines Elementes textfield erzeugt, ein mehrzeiliges mittels eines Elementes textarea. Das Attribut width gibt die Breite des Texteingabefeldes in Anzahl Zeichen an. Das Attribute height gibt für mehrzeilige Texteingabefelder die Anzahl Zeilen an. Das Attribut maxlength gibt bei textfield-Elementen die maximale Länge der Eingabe an.

Texteingabefelder können einen Vorgabewert enthalten, der wahlweise über ein Attribut oder ein Kindelement mit dem Namen default angegeben wird. Die Verwendung eines default-Elementes statt eines default-Attributes ist sinnvoll, wenn mehrzeilige default-Werte angegeben werden sollen.

Syntax

Abbildung 2.26: Syntax von textfield und textarea

Alternativ kann auch ein AutoFill-Wert über das Attribut bzw. Element autofill angegeben werden. Während default-Werte immer Teil der Eingabe werden, werden AutoFill-Werte nur dann als Eingabe betrachtet, wenn der Nutzer sie ergänzt oder ändert. Unveränderte AutoFill-Werte werden also ignoriert. Für alle Mitarbeiter der Universität sind z.B. Teile der Email-Adresse oder der Anschrift in den meisten Fällen identisch. Falls der Nutzer diese Angaben im Eingabefeld ändert oder ergänzt, wird dies als Eingabe betrachtet. Ansonsten wird der AutoFill-Wert ignoriert. Default-Werte dagegen werden immer als Eingabe betrachtet. Wichtig ist, dass textfield- und textarea-Elemente ein innerhalb des Editors eindeutiges ID-Attribut besitzen.

Autofill-Werte

Abbildung 2.27: AutoFill-Werte in textfield und textarea

Passwort-Eingabefelder

Passwort-Eingabefelder werden über das Element password erzeugt. Sie können keine default- oder autofill-Werte besitzen. Bei der Eingabe werden Sternchen statt der eingegebenen Zeichen angezeigt. Das Attribut width gibt die Breite des Eingabefeldes in Anzahl Zeichen an. Leider ist es bei allen Browsern so, dass dieses Feld keine vorhandenen Inhalte bearbeiten kann, d. h. Passworte sind aus Sicherheitsgründen immer neu einzugeben.

Syntax password

Abbildung 2.28: Syntax des password-Elements

Einfache Checkboxen

Das Element checkbox generiert eine alleinstehende Checkbox, bei der über einen „Haken“ ein Wert ein- oder ausgeschaltet werden kann. Das Attribut value gibt den Wert an, der gesetzt werden soll, wenn die Checkbox markiert ist. Das Attribut checked gibt mit den möglichen Werten true und false an, ob als default die Checkbox markiert sein soll oder nicht. Die Beschriftung der Checkbox erfolgt über ein Attribut label bzw. über untergeordnete mehrsprachige label-Elemente, vgl. dazu den Abschnitt zu Beschriftungen.

Syntax checkbox

Abbildung 2.29: Syntax für Checkboxen

Auswahllisten

Auswahllisten werden über das Element list erzeugt. Die in der Liste darzustellenden Werte werden über geschachtelte item-Elemente angegeben. Das Attribut type gibt an, in welchem Format die Listenwerte dargestellt werden. Der Typ dropdown stellt die Listenwerte als einzeilige Dropdown-Auswahlliste dar. Das Attribut width gibt dabei die Breite des Auswahlfeldes in CSS-Syntax an, d.h. es sind Angaben in Anzahl Zeichen oder Pixeln etc. möglich. Der Typ multirow stellt die Listenwerte als mehrzeiliges Auswahlfeld dar. Das Attribut rows gibt dabei die Anzahl Zeilen an, die maximal zu sehen sind. Enthält die Liste mehr Werte als Zeilen, werden Scrollbalken dargestellt. Das Attribut multiple mit den möglichen Werten true und false gibt an, ob eine Mehrfachauswahl möglich ist. Das Attribut default gibt ggf. eine Vorauswahl vor.

Syntax Auswahlliste

Abbildung 2.30: Syntax einer Auswahlliste

Die in einer Liste dargestellten Werte werden über item-Elemente angegeben. Diese können auch mehrstufig geschachtelt sein, um eine hierarchische Struktur darzustellen (d.h. item-Elemente können wiederum item-Elemente enthalten). Eine Schachtelung ist nur für die Listentypen dropdown und multirow erlaubt und sinnvoll. Die Hierarchie wird dabei automatisch durch Einrückungen dargestellt. Die Beschriftung der item-Elemente wird über geschachtelte label-Attribute oder Elemente definiert und kann mehrsprachig angegeben werden, vgl. dazu den folgenden Abschnitt zu Beschriftungen. Die Verwendung von <list type="multirow" multiple="true">, d.h. mehrzeiligen Auswahllisten mit Mehrfachauswahl ist nur sinnvoll, wenn das aktuelle var-Attribut der Zelle auf ein Element verweist, denn Attribute sind ja grundsätzlich in XML nicht wiederholbar.

Mehrfachauswahl

Abbildung 2.31: Beispiel für Mehrfachauswahl

Das Beispiel erzeugt eine dreizeilige Mehrfachauswahlliste, die ggf. in mehrfach generierte XML-Elemente „Programmiersprache“ resultiert.

Radio-Buttons und Checkbox-Listen

Der Typ radio stellt die Listenwerte als eine Menge von Radiobuttons dar, es kann also nur ein Wert ausgewählt werden. Der Typ checkbox stellt die Listenwerte als eine Menge von Checkboxes dar, in diesem Fall können mehrere Werte ausgewählt sein. Bei diesen beiden Typen werden alle Werte der Liste nacheinander in einer Tabellenstruktur mit einer gewissen Anzahl an Zeilen und Spalten ausgegeben. Es kann entweder die Anzahl an Zeilen (Attribut rows) oder die Anzahl an Spalten (Attribut cols) dieser Tabelle angegeben werden. Der jeweils nicht angegebene Wert folgt automatisch aus der Anzahl der Werte in der Liste. Der Spezialfall rows="1" entspricht also einer Anordnung aller Listenwerte von links nach rechts in einer Zeile, der Fall cols="1" entspricht einer Anordnung von oben nach unten in nur einer Spalte.

Radio-Button

Abbildung 2.32: Syntax von Radio-Button und Checkbox-Listen

Analog zu multirow/multiple Listen ist die Verwendung von Checkbox-Listen nur sinnvoll für die Abbildung auf XML-Elemente, da XML-Attribute nicht wiederholbar sind (vgl. vorangehenden Abschnitt).

Beschriftungen

Beschriftungen von Eingabefeldern lassen sich mit den Elementen text und label definieren. Das Element text erzeugt eine frei platzierbare Beschriftung etwa für eine Texteingabefeld. Beschriftungen dürfen auch XHTML Fragmente enthalten, etwa um eine fette, kursive oder mehrzeilige Darstellung zu erreichen. Mehrsprachige Beschriftungen von Elementen können über mehrere label-Elemente realisierte werden, wobei das Attribut xml:lang die Sprache angibt.

Die aktive Sprache wird wie bei anderen MyCoRe-Stylesheets über den XSL.Lang Parameter definiert. Wenn ein label existiert, bei dem xml:lang der aktiven Sprache entspricht, wird dieses ausgegeben. Ist dies nicht der Fall, wird als erster Rückfallschritt das label der Default-Sprache (Parameter XSL.DefaultLang) ausgegeben. Existiert auch dies nicht, wird das Label ausgegeben, das im label-Attribut oder im ersten label-Element enthalten ist, das kein xml:lang-Attribut enthält. In alles anderen Fällen wird das erste label-Element verwendet, das überhaupt existiert.

Syntax Textfeld

Abbildung 2.33: Syntax eines Textfeldes

Internationalisierung

Das Editor-Framework verfügt über mehrere Möglichkeiten der Mehrsprachigkeit einzelner Auswahl- oder Textfelder. Bis MyCoRe-Version 1.2 war hier nur der Einsatz von <label xml:lang="...">-Tags (wie oben beschrieben) möglich. Mit Version 1.3 ist die direkte Nutzung von I18N (http://www.debian.org/doc/manuals/intro-i18n/) möglich. Um eine Abwärts-Kompatibilität zu erreichen sind die <label>-Tags auch weiterhin im Framework gültig. Es ist aber zu empfehlen, langfristig ältere MyCoRe-Anwendungen entsprechend umzustellen. damit wird eine strikte Trennung von Layout und sprachabhängigem Text erreicht.

Mit MyCoRe v1.3 wurde das i18n-Attribut in alle Editor-Framework-Stellen eingebaut, in den bisher <label>-Tags vorgesehen waren. Entsprechend der I18N- Spezifikation sind alle Texte nun über eine Property-Variable bekannt zu machen und in sprachabhängigen Dateien anzulegen. Diese tragen die Namen messages_{lang}.properties und sind bei MyCoRe im config-Verzeichnis untergebracht. Sollte das System für die angegebene Sprache keine solche Datei finden, so wird als Fallback die Datei messages.properties> gesucht. Sind beide Angaben vorhanden, hat das i18n-Attribut Vorrang. Die nachfolgende Abbildung verdeutlicht die neue Funktion.

I18N

Abbildung 2.34: Beschriftung mit I18N

Abstandshalter

Ein Abstandshalter erzeugt leeren Raum als Platzhalter zwischen Elementen. Die Attribute width und height geben Breite und Höhe des Abstandes in CSS-Syntax, etwa in Anzahl Pixeln, an.

Abstand

Abbildung 2.35: Syntax eines Abstandhalters

Externes Popup-Fenster

Ein externes Popup-Fenster kann z.B. ein Hilfetext zu einem Eingabefeld im HTML-Format enthalten. Es können aber auch beliebige andere Informationen und Funktionalitäten wie Eingabehilfen dargestellt werden. Der Startpunkt ist ein Button im Formular, der mit einer frei wählbaren Beschriftung versehen werden kann. Standardmäßig wird er als [?] Button im Formular dargestellt. Bei Anklicken des Buttons erscheint das codierte HTML in einem Popup-Fenster. Die Attribute width und height steuern die Breite und Höhe dieses Fensters. Das Attribut css gestattet die Verwendung eines externen CSS-Files. Wichtig ist, dass jedes helpPopup Element eine eindeutige ID besitzt. Optional kann das Popup-Fenster auch von einer externen URL geladen werden. Falls die URL mit „http://“ oder „https://“ beginnt, wird sie als absolute URL direkt verwendet, andernfalls wird die URL als relativ zur WebApplicationBaseURL (context root), dem Startpunkt der WebApplication, interpretiert.

Innerhalb des helpPopup-Tags gibt es mehrere Tags, welche das Aussehen und den Inhalt des Aufruf-Buttons und des Popup-Fensters bestimmen. Jedes Tag verfügt über das xml:lang-Attribut. Somit kann jedes Tag für die im Projekt benötigten Sprachen implementiert werden. Zusätzlich gibt es das Konstrukt xml:lang="all", das anzeigt, dass das entsprechende Tag immer unabhängig von der Spracheinstellung des Systems präsentiert werden soll.

Im Einzelnen sind die Tags wie folgend definiert:

  • button gibt die Zeichenkette an, welche der Start-Button haben soll,
  • title gibt den Titel des Popup-Fensters an,
  • close gibt den Text zum Schließen des Popup-Fensters an,
  • label beinhaltet den eigentlichen darzustellenden HTML-Code oder Text.
Popup-Fenster

Abbildung 2.36: Syntax eines Popup-Fensters

Buttons

Über das Element button wird ein Knopf erzeugt, der bei Anklicken zu einer externen URL wechselt. Das Attibut width legt die Breite des Knopfes fest, das Attribut label oder ggf. mehrsprachige enthaltene label-Elemente legen die Beschriftung des Knopfes fest. Falls die URL mit „http://“ oder „https://“ beginnt, wird sie als absolute URL direkt verwendet, andernfalls wird die URL als relativ zur WebApplicationBaseURL (context root), dem Startpunkt der WebApplication, interpretiert.

Syntax Button

Abbildung 2.37: Syntax eines einfachen Buttons

SubmitButton

Über das Element submitButton wird ein Knopf erzeugt, der beim Anklicken die Eingaben an das in der Konfiguration angegebene Ziel sendet. Das Attribut width legt die Breite des Knopfes fest, das Attribut label oder ggf. mehrsprachige enthaltene label-Elemente legen die Beschriftung des Knopfes fest.

Syntax Submit-Button

Abbildung 2.38: Syntax des Submit-Buttons

CancelButton

Über das Element cancelButton wird ein Knopf erzeugt, der bei Anklicken die Bearbeitung des Formulars abbricht. Das Attibut width legt die Breite des Knopfes fest, das Attribut label oder ggf. mehrsprachige enthaltene label-Elemente legen die Beschriftung des Knopfes fest.

Syntax Cancel-Button

Abbildung 2.39: Syntax des Cancel-Buttons

Die Ziel-URL des Buttons kann auf verschiedene Weisen gebildet werden, z. B. im einfachsten Fall als statische URL, die in der Editor-Definition als Top-Level-Element angegeben ist (d.h. auf gleicher Ebene wie die target-Deklaration), z.B.
<cancel url="pages/goodbye.html" />

Alternativ oder zusätzlich ist auch die Verwendung von Request Parametern wie bei der Source URI möglich, so dass die URL dynamisch gebaut wird. Gegeben sei z. B. ein Formular zur Bearbeitung von Objekt-Metadaten.

<cancel url="receive/{mcrId}" />

<cancel url="content/main/authorsArea.xml" />
  • Wenn das Formular ohne Request Parameter aufgerufen wird, wird die zweite URL verwendet, und bei Klick auf den Abbrechen-Button auf die Seite content/main/authorsArea.xml geleitet.
  • Wenn das Formular beim Aufruf mit dem Request Parameter formular.xml?mcrId=DocPortal_document_00410901 aufgerufen wird, wird dieser in die erste URL eingesetzt und diese verwendet. Es wird dann auf die Anzeige der Metadaten eines bestimmten Objektes geleitet: receive/DocPortal_document_00410901

Ausgabe von Werten aus dem Quelldokument

Das Element output kann bei der Bearbeitung einer existierenden XML-Quelle verwendet werden, um den Inhalt von Attributen oder Elementen im Formular als nicht bearbeitbaren Text auszugeben. Dabei ist zu beachten, dass der ausgegebene Wert bei Abschicken des Formulars nicht weitergegeben wird. Hierfür muss ggf. ein hidden-Element verwendet werden. Das Attribut default gibt den Wert an, der ggf. ausgegeben wird, wenn das Dokument keinen Wert enthält.

Beispiel:

<text><label>Dokument-ID:</label></text>
<output var="@id" default="(neu) />

gibt den Wert des Attributes id aus, sofern dieses im XML-Quelldokument existiert, ansonsten wird „(neu)“ ausgegeben.

Wiederholbare Elemente mit Repeatern erstellen

Häufig sind einzelne Eingabefelder oder ganz Panels wiederholbar. Das Element repeater schachtelt auf einfache Weise ein Eingabeelement oder ein ganzes Panel und macht dieses wiederholbar. Das var-Attribut der umgebenden Zelle muss auf ein Element verweisen, da Attribute nicht wiederholbar sind. Das Attribut min gibt an, wie oft minimal das wiederholte Element im Formular dargestellt wird, das Attribut max gibt die Maximalzahl an Wiederholungen an. In jedem Fall wird das Element minimal so oft dargestellt, wie es in der Eingabe auftritt.

Das Beispiel wiederholt die Komponente mit der ID pcreator. Wiederholbare Elemente werden mit +/- Buttons dargestellt, mit denen neue Eingabefelder hinzugefügt bzw. dargestellte gelöscht werden können. Bei mehr als einer aktuell dargestellten Wiederholung werden Pfeile angezeigt, mit deren Hilfe die Reihenfolge der Elemente vertauscht werden kann.

Repeater

Abbildung 2.40: Beispiel Repeator

Der Framework-interne FileUpload

Das Element file erlaubt es, eine einzelne Datei zusammen mit den Formulareingaben hochzuladen oder eine auf dem Server vorhandene Datei zu löschen oder zu aktualisieren. Voraussetzung ist hierfür die vollständige Integration des Upload-Services in den jeweiligen Java-Klassen. Das Attribut maxlength gibt optional die maximale Grösse der hochzuladenen Datei an. Der FileUpload über ein HTML-Formular ist nur für relativ kleine Dateien mit wenigen MB zu empfehlen, andernfalls ist der in MyCoRe implementierte externe FileUpload zu nutzen. Das Attribut accept gibt optional den akzeptierten MIME Typ an. Ob diese Angaben beachtet werden, ist jedoch vom Browser abhängig und daher nicht verlässlich. Die Darstellung eines Datei-Upload Feldes hängt ebenfalls sehr stark vom Browser ab und kann nicht über CSS gestaltet werden. In der Regel bestellt ein solches Feld aus einem Texteingabefeld (dessen Breite in Anzahl Zeichen das width-Attribut angibt) und einem Button „Durchsuchen“. Beschriftung und Layout dieser Elemente sind nicht steuerbar und fest vom Browser vorgegeben, CSS Angaben funktionieren nicht zuverlässig. Über den Durchsuchen-Button kann eine Datei von der lokalen Festplatte gewählt werden, alternativ kann der Dateipfad im Texteingabefeld eingegeben werden. Mit Abschicken des Formulars wird der Dateiinhalt und der Dateiname an den Server übertragen, was unter Umständen lange dauern kann.

FileUpload

Abbildung 2.41: Syntax des FileUpload

Zu beachten ist noch, dass für den FileUpload einige Property-Werte des Systems von Bedeutung sind.

  • Dateien bis zu dieser Größe werden im Hauptspeicher des Servers gehalten:
    MCR.Editor.FileUpload.MemoryThreshold=1000000
  • Dateien bis zu dieser Größe werden für HTTP Uploads akzeptiert:
    MCR.Editor.FileUpload.MaxSize=5000000
  • Temporärer Speicherort für hochgeladene Dateien:
    MCR.Editor.FileUpload.TempStoragePath=/tmp/upload

Das Auslesen der Dateien zur weiteren Verarbeitung kann z.B. wie folgt durchgeführt werden.

FileUpload

Abbildung 2.42: Abbildung 42: Java-Code zum Lesen des FileUpload

Weitere Hinweise zum Auslesen der hochgeladenen Dateien finden Sie in der JavaDoc-Dokumentation der Klassen org.mycore.frontend.editor2.MCREditorSubmission und MCREditorVariable sowie in der Online-Dokumentation des Apache File Upload Paketes (http://jakarta.apache.org/commons/fileupload/).

Die Methode MCREditorSubmission.listFiles() liefert eine java.util.List von hochgeladenen FileItem-Objekten. Die Apache-Klasse FileItem besitzt Methoden getName() und getInputStream(), die den Dateinamen und den hochgeladenen Dateiinhalt liefern. Die Methode getFieldName() liefert den Pfad im XML-Dokument, zu dem die hochgeladene Datei gehört.

Alternativ kann auch über diesen Pfad auf eine bestimmte hochgeladene Datei direkt zugegriffen werden: Die Eingaben aus dem Editor werden als JDOM-Dokument an das Zielservlet übergeben und stehen über MCREditorSubmission.getXML() zur Verfügung. Mit JDOM-Operationen kann man nun zu dem JDOM-Element oder -Attribut navigieren, für das ggf. eine Datei im Formular hochgeladen wurde. Die Methode MCREditorSubmission.getFile()erwartet als Argument dieses JDOM-Objekt und liefert das dazu gehörende FileItem.

FileItem-Objekte sollten unmittelbar verarbeitet werden, da die Dateiinhalte nur temporär gespeichert werden. Der hochgeladene Inhalt kann mittels FileItem.write() in ein persistentes java.io.File kopiert werden oder in einem MCRFile gespeichert werden.

Zu beachten ist, dass FileUploads nicht in Editoren verwendet werden sollten, die Repeater enthalten. Will man mehr als eine Datei hochladen, sollte das file-Element „manuell“ mehrfach im Editor definiert werden, es darf jedoch kein Repeater verwendet werden.

Integration externer Datenquellen

Das Editor-Framework gestattet es, Teile der Formular-Definition auszulagern und über eine include Anweisung einzubinden. Dies ermöglicht es, in mehreren Formularen oder an verschiedenen Stellen eines Formulars verwendete Teile wiederzuverwenden und nur einmal zu definieren. Eine include Anweisung kann an beliebiger Stelle eines Formulars stehen.

Die include Anweisung liest einen Teil der Editor-Definition von einer beliebigen URI, die durch den MyCoRe URI Resolver unterstützt wird. Beispiele:

<include uri="classification:editor:-1:children:marcrelator" />
liest über den Klassifikations-Resolver die Kategorien der Klassifikation mit ID "marcrelator" ein, um sie in das Formular als Auswahlwerte einer Dropdown-Liste anzubieten.
<include uri="webapp:editor-includes.xml" ref="cancel.submit" />
liest die statische XML-Datei editor-includes.xml aus der Webapplikation, und nimmt daraus den Inhalt eines XML-Elementes mit der ID "cancel.submit". Dies könnte etwa die Definition des Speichern- und Abbrechen-Buttons sein, der in mehreren Formularen verwendet wird und in der Datei editor-includes.xml nur einmal definiert wird..
Einfügen eines Request aus einem Servlet

Dieses Beispiel zeigt den Zugriff auf ein Servlet zur Laufzeit. Dabei werden die Ausgabedaten der Servlet-Antwort vor der Integration in das Framework mittels XSLT in eine passende Form gebracht. Im Beispiel wird eine MyCoRe-Klassifikation in eine Auswahlliste eingefügt.

Servlet-Request

Abbildung 2.43: Include Servlet-Request

Einfügen eines Definitionsabschnittes aus der Session

Es besteht auch die Möglichkeit, Daten dynamisch in der MCRSession zu hinterlegen und von dort in die Gestaltung des Formulars zu integrieren. Im ersten Schritt wird in einer Java-Klasse ein JDOM-Element erzeugt, welches dann im zweiten Schritt in das Formular eingebaut wird. Das Attribut cacheable spezifiziert dabei, ob die Daten permanent vorgehalten werden sollen. Für ständig wechselnde Daten ist hier false anzugeben.

Java-Code

Abbildung 2.44: Java-Code

Formularteile dynamisch abhängig von Request Parametern integrieren

Ähnlich wie bei der Source URI und Cancel URI kann auch bei der include Anweisung ein HTTP Request Parameter verwendet werden, um Formularteile abhängig davon nachzuladen und so ein dynamisch aufgebautes Formular zu erzeugen. In diesem Fall muss allerdings der Request Parameter immer übergeben werden. Beispiel:

<include uri="webapp:editor-includes.xml" ref="{mode}" />

Wird das Formular mit dem Parameter ?mode=simple aufgerufen, wird an dieser Stelle aus der Datei editor-includes.xml der Inhalt eines Elementes mit der ID "simple" eingebunden. Wird das Formular mit dem Parameter ?mode=advanced aufgerufen, wird an dieser Stelle der Inhalt eines Elementes mit der ID "advanced" eingebunden.

Platzhalter für Request Parameter stehen in geschweiften Klammern und können sowohl im uri Attribut als auch im ref Attribut verwendet werden.

Eingabevalidierung

Einführung

Die Eingabefelder von Editor-Formularen können durch Integration von Validierungsregeln direkt durch das Editor-Servlet geprüft werden, noch bevor die Eingaben an das weiterverarbeitende Zielservlet weitergegeben werden. Wenn eine Eingabe fehlerhaft ist, wird das Formular noch einmal angezeigt. Es erscheint eine Fehlermeldung. Eingabefelder mit fehlerhaften Eingaben werden im Formular optisch markiert. Zunächst ein einfaches Beispiel:

Eingabevalidierung

Abbildung 2.45: Einfaches Beispiel für Eingabevalidierung

Das Element validationMessage enthält die Meldung, die am Kopf des Formulars erscheint, wenn ein oder mehrere Eingabefelder fehlerhaft ausgefüllt wurden. Dieses Element ist optional, es kann ein sprachunabhängiges label-Attribut oder ein oder mehrere sprachabhängige label-Elemente enthalten.

Jedes zu validierende Eingabefeld muss eine eindeutige ID besitzen. Neben Texteingabefeldern können auch alle anderen Feldtypen wie z.B. Auswahllisten validiert werden. Nur hidden-Felder können momentan nicht validiert werden.

Das zu validierende Feld muss ein oder mehrere condition-Elemente enthalten, die wiederum eine eindeutige ID besitzen müssen. Die Attribute dieser condition-Elemente enthalten die zu prüfenden Validierungsregeln. Ein condition-Element kann ein sprachunabhängiges label-Attribut oder ein oder mehrere sprachabhängige label-Elemente enthalten, die eine Meldung für den Benutzer enthalten. Bei einer fehlerhaften Eingabe wird diese Meldung angezeigt, wenn der Benutzer mit der Maus über das Fehlersymbol fährt, das neben dem Eingabefeld angezeigt wird.

Fehlgeschlagene Eingabevalidierung

Abbildung 2.46: Fehlgeschlagene Eingabevalidierung

Ein Eingabefeld kann mehr als ein condition-Element enthalten. Dadurch können komplexe Validierungsregeln schrittweise geprüft werden, und der Nutzer bekommt eine exaktere Rückmeldung, welche dieser Regeln verletzt wurde. Wenn die Validierungsregeln auf mehrere condition-Elemente aufgeteilt wird, sollte die „required“ Regel ggf. die erste sein.

Regeln

Abbildung 2.47: Beispiel für eine Reihenfolge von Regeln

Oder

Regeln in einer condition

Abbildung 2.48: Beispiel für Regeln in einer condition

Validierungsregeln für einzelne Felder

Die Validierungsregeln für Eingabefelder werden über Attribute oder Attributkombinationen des condition-Elements definiert. Die folgenden Regeln können geprüft werden:

required="true"
Es ist eine Eingabe erforderlich. Auch Eingaben, die nur aus Leerzeichen bestehen, werden abgewiesen. Ist diese Regel verletzt, werden ggf. weitere vorhandene Regeln nicht mehr geprüft.
minLength="10"
Die Eingabe muss aus minimal 10 Zeichen bestehen.
maxLength="250"
Die Eingabe darf aus maximal 250 Zeichen bestehen.
type="integer" min="0" max="100"
Die Eingabe muss eine ganze Zahl sein. Optional kann über die Attribute min und/oder max der Wertebereich eingeschränkt werden.
type="decimal" format="de" min="0" max="3,5"
Die Eingabe muss eine Zahl (ggf. mit Nachkommastellen) sein. Optional kann über die Attribute min und/oder max der Wertebereich eingeschränkt werden. Das Attribut format muss einen ISO 639 Sprachcode enthalten (z.B. „de“ oder „en“), der bestimmt, wie Kommazahlen formatiert werden. Die min- und max-Werte müssen diesem Format entsprechend angegeben werden.
type="datetime" format="dd.MM.yyyy" min="01.01.1970" max="31.12.2030"
type="datetime" format="dd.MM.yyyy;yyyy-MM-dd" min="21.08.2009"
Die Eingabe muss ein Datums- oder Zeitwert sein. Optional kann über die Attribute min und/oder max der Wertebereich eingeschränkt werden. Das Attribut format muss ein java.text.SimpleDateFormat Pattern enthalten (z.B. „dd.MM.yyyy“), das bestimmt, wie der Wert formatiert sein muss. Erlaubt sind auch mehrere durch Semikolon getrennte Formate. Die min- und max-Werte müssen im ersten angegebenen Format spezifiziert werden.
type="string" min="a" max="zzz"
Eine Eingabe kann ein beliebiger Text sein. Optional kann über die Attribute min und/oder max der Wertebereich eingeschränkt werden.
regexp=".+@.+\..+"
Die Eingabe muss den angegebenen regulären Ausdruck erfüllen. Die Syntax des regulären Ausdrucks ist durch die Klasse java.util.regex.Pattern definiert.
xsl="contains(.,'@')"
Die Eingabe wird gegen eine XSL Bedingung geprüft, wie sie in XSL if oder when Elementen verwendet werden kann. Der Eingabewert wird in der Bedingung durch einen Punkt referenziert.
class="foo.bar.Validator" method="validateFooBar"
Die Eingabe wird durch Aufruf einer beliebigen Java-Methode validiert, die true oder false zurückgibt. Im oben gezeigten Beispiel würde die Methode public static boolean validateFooBar( String value ) aus der Klasse foo.bar.Validator aufgerufen. Es sind so sehr spezielle Validierungsregeln wie z.B. das Prüfen einer ISBN implementierbar.

Validierungsregeln für Feldkombinationen

Es ist ebenfalls möglich, die Eingaben zweier Felder gegeneinander zu prüfen. Dazu wird ein condition-Element in das die beiden Felder enthaltende Panel eingefügt. Die Werte der beiden Felder können dann über Vergleichsoperatoren gegeneinander geprüft werden. Beispiele:

  • Ein Eingabeformular zum Ändern eines Passwortes enthält zwei Passwortfelder, so dass das Passwort wiederholt eingegeben werden muss. Die Eingaben in diesen beiden Feldern müssen identisch sein.
  • Ein Eingabeformular enthält zwei Eingabefelder für einen Datumsbereich. Das Datum im Feld validFrom muss kleiner oder gleich dem Datum im Feld validTo sein.
Codebeispiel

Abbildung 2.49: Codebeispiel

Zunächst werden die Werte beider Eingabefelder validFrom und validTo nach den gleichen Regeln auf die Eingabe eines korrekten Datums geprüft. Wenn mindestens eines der Felder eine Eingabe enthält (was ggf. über ein required->Attribut erzwungen werden könnte), werden die Werte der Felder miteinander verglichen.

field1="validFrom"

Erstes zu vergleichende Feld. Syntax und Funktionsweise entsprechen dem Verhalten des Attributes var für Zellen.

field2="validTo" >

Zweites zu vergleichende Feld. Syntax und Funktionsweise entsprechen dem Verhalten des Attributes var für Zellen.

operator="&lt;="

Vergleichsoperator (hier >=). Es können die Operatoren =, >, <, >=, <=, != (für ungleich) verwendet werden.

type="datetime"
format="dd.MM.yyyy"

Datentyp und Format der Eingabe, analog zu den gleichnamigen Attributen, die im vorangehenden Abschnitt bereits erläutert wurden.

Alternativ kann auch hier über eine externe Java-Methode validiert werden. Das folgende Beispiel würde für zwei Zahlen prüfen, ob die eine das Quadrat der anderen ist:

<condition id="cond.quadrat" field1="zahl1" field2="zahl2"
class="math.Validator" method="validateSquare">
<label>Zahl 1 muss gleich dem Quadrat der Zahl 2 sein!</label>
</condition>

In der Klasse math.Validator könnte die Methode zur Validierung wie folgt aussehen:

public static boolean validateSquare( String value1, String value2 )
{
int zahl1 = Integer.parseInt( value1 );
int zahl2 = Integer.parseInt( value2 );
return ( zahl1 == (zahl2 * zahl2) );
}

Bitte beachten Sie, dass bei externer Validierung die Werte immer als String übergeben werden. Durch Vorschalten einer weiteren Validierungsregel kann aber z.B. leicht erreicht werden, dass nur Zahlen oder bestimmte Datentypen eingegeben werden können.

Validierung ganzer Panels oder XML-Bereiche

Mehrere Eingabefelder können gemeinsam über eine XSL-Bedingung oder eine externe Java-Methode validiert werden. So kann im Extremfall das gesamte aus der Eingabe resultierende XML-Dokument validiert werden. Die Eingabevalidierung bezieht sich in diesem Fall auf ein Panel der Editor-Definition und dem daraus resultierendem XML-Element. Dies kann auch das Wurzelpanel sein. Das condition-Element für die Validierungsregel muss dabei ein Kindelement dieses Panels sein.

Über die Attribute class und method kann eine externe Java-Methode angegeben werden, die ein XML-Element validiert:

    

<components var="/input" root="root" ... <panel lines="off" id="root"> <condition id="validateExt" class="foo.bar.Validator" method="validateInput"> <label xml:lang=</code><code>"de"> Eingabefehler! </label> </condition> ... Sie ruft dann zur Validierung in der Klasse foo.bar.Validator die folgende Methode auf: public static boolean validateInput( Element input )

Über das Attribut xsl kann eine XSL-Bedingung angegeben werden. Im folgenden Beispiel wird in einer Suchmaske sichergestellt, dass mindestens ein Eingabefeld mit einem Wert ausgefüllt ist. Dies entspricht der XSL-Bedingung: „Die Anzahl der Elemente, bei denen das value-Attribut nicht leer ist, ist größer null“.

     

<components var="/query" root="root"> ... <panel lines="off" id="root"> <condition id="someInputNeeded" xsl="count(conditions/boolean/*[string-length(@value) &gt; 0]) &gt; 0"> <label xml:lang="de">Bitte einen Suchausdruck eingeben!>/label> </condition> ...