Das MyCoRe XEditor-Framework

Transkript

1 by Frank Lützenkirchen Das MyCoRe XEditor-Framework stellt Funktionalität zur Gestaltung von HTML-Formularen bereit, die XML-Dokumente bearbeiten oder erstellen. Die Formulardefinition enthält dazu Regeln zur Abbildung zwischen Eingabefeldern im Formular und XML-Elementen und -Attributen im bearbeiteten Dokument. Solche Formulare werden insbesondere zur Gestaltung von Eingabemasken für Metadaten und für komplexe Suchformulare verwendet. Eine Anleitung zum alten Editor Framework ist unter dem Punkt 'Veraltete Komponenten -> Editorframework' (Menüpunkt links unten) zu finden. Table of contents 1 Architektur und Funktionsweise Grundkonfiguration des XEditor-Frameworks Ein erstes Beispiel Formulare definieren <xed:form /> Zu bearbeitendes XML laden: <xed:source /> Abbildung zwischen XML und HTML: <xed:bind /> Wiederholbare Bereiche Ausgabe von Werten und mehrsprachigen Bereichen Das Formular absenden Eingabevalidierung und Nachbearbeitung Komplexe Strukturen mit Includes und Fallunterscheidungen Externe Auswahl oder Eingabe über Subselects Das XEditor-Framework erweitern... 28

2 1 Architektur und Funktionsweise XEditor-Formulare werden als MyCoReWebPage mit der Endung *.xed definiert. Die statische Webseite enthält neben anderen Elementen an einer Stelle ein <xed:form / > -Element, das das gesamte XEditor-Formular umschließt. Es ist derzeit nicht möglich, mehr als ein XEditor-Formular in der gleichen Webseite zu verwenden. Ein XEditor-Formular besteht aus einer Kombination von HTML-Elementen und speziellen XEditor-Elementen. Die HTML-Elemente definieren Struktur und Layout des Formulars und werden vom XEditor-Framework weitgehend unverändert belassen. Zusätzliche XEditor-Elemente und -Attribute mit Namespace xmlns:xed=" definieren die Abbildung zwischen Eingabefeldern im HTML-Formular und Elementen und Attributen in dem XML-Dokument, das mit dem Formular bearbeitet oder erstellt wird. Weitere XEditor-Elemente regeln die Nachbearbeitung des resultierenden XMLs, steuern die Eingabevalidierung oder stellen Funktionen für dynamische Elemente wie z. B. wiederholbare Bereiche bereit. Wird eine Seite aufgerufen, die ein XEditor-Formular enthält, werden die speziellen XEditor- Element serverseitig in HTML-Strukturen transformiert und jedem Eingabefeld ein Element oder Attribut im bearbeiteten XML-Dokument zugeordnet. Browserseitig erscheint ein reines HTML-Formular. Das Formular kann entweder leer starten, so dass beim Aufbau des Formulars ein neues XML-Dokument generiert wird, oder es kann ein vorhandenes XML-Dokument aus beliebiger Quelle laden und dessen Werte in den Eingabefeldern zur Bearbeitung bereitstellen. Elemente und Attribute, die nicht bestimmten Eingabefeldern im Formular zugeordnet sind, bleiben dabei unverändert im XML-Dokument erhalten. Bestimmte Bereiche des Formulars, einzelne Eingabefelder oder ganze Panels können wiederholt werden und entsprechen wiederholbaren Elementen im XML-Dokument. In einem Formular für Publikationsdaten kann z. B. ein Bereich zur Eingabe der Autoren wiederholbar gestaltet werden. Der Benutzer kann über Buttons Felder hinzufügen, entfernen oder vertauschen. Beim Abschicken des Formulars werden die Werte zunächst an das XEditor-Servlet übermittelt. Dort werden sie in das XML-Dokument eingefügt. Das resultierende XML wird zusammen mit den abgeschickten Request-Parametern aus dem Formular via Request Dispatching an das eigentliche Zielservlet weitergeleitet. Wenn Validierungsregeln definiert sind, erfolgt zuvor eine serverseitig Eingabevalidierung. Schlägt die Validierung fehl, wird die Formularseite erneut angezeigt und dabei konfigurierbare Meldungen ausgegeben, damit der Benutzer die Eingabefehler korrigieren kann. Die Eingabevalidierung erfolgt immer serverseitig nach Abschicken des Formulars. Der Entwickler kann jedoch zusätzlich mit den üblichen Mitteln (HTML5, JavaScript) eine clientseitige Eingabevalidierung im Browser implementieren. Bereinigungsregeln (Cleanup Rules) dienen der Nachbearbeitung des resultierenden XML-Dokumentes und ermöglichen es, logisch leere Elemente und Attribute zu Seite 2 von 28

3 entfernen, für die z. B. zwar ein Eingabefeld angeboten wurde, aber kein Wert eingegeben wurde. Bei Aufruf der Seite können Request Parameter verwendet werden. Diese Parameter sind, zusammen mit Konfigurationswerten aus mycore.properties oder Variablen aus der Session des Benutzers (MCRSession) an vielen Stellen im Formular verwendbar, um dessen Aufbau zu steuern. Alle Request Parameter aus dem ursprünglichen Aufruf der Seite werden zusätzlich zu den Formularwerten auch an das Zielservlet durchgereicht. Über die Elemente <xed:if />, <xed:choose /> und <xed:include /> können Formular dynamisch gestaltet werden, so dass sie abhängig von Aufruf- oder Konfigurationsparametern Teilbereiche unterschiedlich darstellen oder aus Teilen zusammensetzen. Beschriftungen und Texte im Formular können über messages-*.properties Dateien mehrsprachig ausgegeben werden. 2 Grundkonfiguration des XEditor-Frameworks In einer eigenen Anwendung müssen nur wenige Properties ggf. angepasst werden. Wird ein XEditor-Formular aufgerufen, speichert das Framework das bearbeitete XML und weitere Informationen serverseitig in der Session des Benutzers. MCR.XEditor.MaxEditorsInSession=50 definiert, wie viele Formulare maximal vorgehalten werden. Das Layout von Validierungsmeldungen und Buttons zur Steuerung wiederholter Bereiche ist frei anpassbar. Hierzu kann die vorhandene Datei xeditor-custom.xsl aus dem MyCoRe Kern überschrieben oder durch ein anderes Stylesheet ersetzt werden, das eigene Templates für diese Elemente enthält. MCR.URIResolver.xslIncludes.xeditor=xeditor-custom.xsl Webseiten, die XEditor-Formulare enthalten, müssen bei Aufruf durch das MCRStaticXEditorFileServlet verarbeitet werden. Das Standard-Mapping, welches bereits beim Aktivieren des Moduls mit bereitgestellt wird, ist hierfür <servlet-mapping> <servlet-name>mcrstaticxeditorfileservlet</servlet-name> <urlpattern>*.xed</url-pattern> </servlet-mapping> 3 Ein erstes Beispiel Das folgende Beispiel zeigt ein einfaches XEditor-Formular, das den Titel eines Dokumentes bearbeitet. Es ist an das Formular simpledoc.xed aus dem MyCoRe Skeleton Projekt (../../documentation/getting_started/skeleton.html) angeleht. <?xml version="1.0" encoding="utf-8"?> <MyCoReWebPage> <section xml:lang="all" title="erfassungsmaske"> <xed:form xmlns:xed=" xeditor" role="form" class="form-horizontal"> <xed:source uri="mcrobject: Seite 3 von 28

4 {$id}" /> <xed:bind xpath="/mycoreobject"> <xed:bind xpath="metadata"> <xed:bind <div class="formgroup"> <label class="col-md-4 control-label" for="title"> <xed:output i18n="editor.label.title" /> </label> <div class="col-md-6"> <input id="title" placeholder="{i18n:editor.placeholder.title}" class="form-control input-md" type="text" /> </div> </div> </xed:bind> <div class="form-group"> <label class="col-md-4 control-label" for="save"></label> <div class="col-md-8"> <button id="save" class="btn btn-success updateobject" type="submit" xed:target="servlet" xed:href="updateobjectservlet"> <xed:output i18n="common.button.save" /> </button> </div> </div> </xed:bind> </xed:bind> </xed:form> </section> </MyCoReWebPage> xed:form / Zeile 6 bildet den äusseren Rahmen jedes XEditor-Formulars und entspricht dem <form>- Element von HTML. xed:source / Zeile 7 lädt das zu bearbeitende XML-Dokument von einer Quelle, die als URI angegeben wird. In diesem Fall wird der Parameter id verwendet, um über den mcrobject: Resolver (../../documentation/frontend/uri_resolver.html) ein MyCoRe Metadaten- Objekt (Dokument, Publikation o.ä.) zu laden. Wenn das Formular im Browser über simpledoc.xed?id=skeleton_simpledoc_ aufgerufen wird, wird das Objekt mit dieser ID geladen. xed:bind / Zeilen 9, 10 und 12 regelt die Abbildung zwischen Bereichen im XML-Dokument und den zugehörigen Bereichen im Eingabeformular. Verschachtelte <xed:bind> Elemente werden verwendet, um hierarchisch einzelne Metadaten-Felder auf einzelne Eingabefelder abzubilden. In diesem Fall wird das Texteingabefeld für den Titel in Zeile 18 auf das XML-Element mit dem XPath /mycoreobject/metadata/def.title/ title abgebildet. xed:output / i18n: / Zeilen 15, 18 und 27 wird für die Ausgabe von Werten oder Bezeichnungen, in diesem Fall mehrsprachige Beschriftungen für das Eingabefeld und einen Platzhalter aus den messages- *.properties Dateien (../../documentation/frontend/i18n.html), verwendet. xed:target / xed:href / Zeile 26 definiert für den Absenden-Button des Formulars, wohin das resultierende XML- Dokument geschickt werden soll, in diesem Fall an das UpdateObjectServlet, das die Änderungen speichert. 4 Formulare definieren 4.1 <xed:form />... umschliesst das gesamte XEditor-Formular, entspricht dem HTML <form /> Element und wird in ein solches transformiert. Das XEditor-Framework setzt das des <form /> Elementes, damit die Formularwerte an das XEditor- Seite 4 von 28

5 Servlet gesendet werden. Bei Absenden des Formulars werden die Werte zunächst vom XEditor-Servlet verarbeitet und danach ggf. an das eigentliche Zielservlet per Request Dispatching als XML-Dokument weitergegeben. Weitere optionale Attribute werden 1:1 von <xed:form /> zu <form /> kopiert. Die Standard Submit-Methode ist "post", kann aber über <xed:form method="get"... überschrieben werden. Sollen im bearbeiteten XML-Dokument zusätzliche Namespaces verwendet werden, sollten diese als Namespace Attribute (xmlns:...) beim <xed:form /> Element definiert werden. Die in MyCoRe häufig verwendeten Namespaces für MyCoRe, MODS, METS, XLink etc. sind bereits vordefiniert und müssen nicht angegeben werden. 4.2 Zu bearbeitendes XML laden: <xed:source /> <xed:source uri="..." /> <xed:source uri="mcrobject:{$id}" /> Lädt das in diesem Formular zu bearbeitende XML-Dokument von einer URI. <xed:source /> ist nur erforderlich, wenn das Formular nicht "leer" starten soll, sondern ein existierendes XML-Dokument zur Bearbeitung laden soll. Das können z. B. die Metadaten eines MyCoRe-Objektes sein, oder auch eine XML-Datei, die als Template (Vorlage) dient. Das kann eine beliebige URI sein, die der MyCoRe URI Resolver unterstützt (z. B. mcrobject:, resource:, webapp:, file:, und gibt die Quelle an, von der das XML-Dokument gelesen wird. Das kann optional ein oder mehrere Variablen enthalten, die bei Aufruf des Formulars durch Parameter ersetzt werden. Variablen stehen in geschweiften Klammern und beginnen mit einem $ Zeichen, z. B. <xed:source uri="mcrobject:{$id}" /> Die Variablen werden bei Aufruf des Formulars durch den konkreten Wert ersetzt, wobei als Quelle die HTTP Request Parameter aus der URL des Aufrufs, Konfigurationswerte aus mycore.properties oder Werte aus der MCRSession verwendet werden können. <xed:source /> ist wiederholbar. Wenn mehrere <xed:source /> Elemente angegeben sind, wird das erste Element verwendet, das keine Variablen enthält, oder bei dem alle angegebenen Variablen durch konkrete Werte ersetzt werden können. So kann man z. B. abhängig von Aufruf- oder Konfigurationsparametern XML-Dokumente aus verschiedenen Quellen laden. Seite 5 von 28

6 <xed:source uri="xslstyle:mcrobject2{$type}:mcrobject:{$id}" /> <xed:source uri="mcrobject:{$id}" /> <xed:source uri="webapp:template.xml" /> Wenn das Formular mit [Seite].xed?id=DocPortal_document_ aufgerufen wird, wird die zweite URI verwendet, denn der Parameter $type ist nicht gegeben. Die URI mcrobject:docportal_document_ lädt die Metadaten des MyCoRe- Objektes mit der ID DocPortal_document_ zur Bearbeitung. Wenn das Formular stattdessen mit [Seite].xed? type=similar&id=docportal_document_ aufgerufen wird, wird die erste URI verwendet, und ein XML-Dokument von xslstyle=mcrobject2similar:mcrobject:docportal_document_ geladen, d.h. die Metadaten des MyCoRe-Objektes mit der ID DocPortal_document_ werden geladen, durch das XSL Stylesheet mcrobject2similar.xsl transformiert und in das Formular geladen. Wenn das Formular ohne Parameter aufgerufen wird, wird die dritte URI verwendet, und eine statische Vorlage aus der Datei template.xml der Webapplikation geladen. Es wäre auch denkbar, die komplette URI als Parameter zu übergeben. Davon kann nur abgeraten werden, da es die Aufruf-URLs unnötig lang macht, Implementierungsdetails offenlegt und potentiell zu Sicherheitslücken führt: <xed:source uri="{$uri}" /> Aufruf mit [Seite].xed? uri=mcrobject:docportal_document_ Abbildung zwischen XML und HTML: <xed:bind /> Legt die Abbildung zwischen Eingabe-Komponenten im HTML-Formular und -Knoten im XML-Dokument fest. <xed:bind xpath="..." default="..." initially="..." set="..." name="..."> Abbildung auf XML-Knoten über XPath-Ausdrücke Das kann ein beliebiger XPath 1.0 Ausdruck sein, der ein oder mehrere Elemente oder Attribute im zu bearbeiteten XML selektiert. Das Element drückt aus, dass alle durch das <xed:bind /> umschlossenene Bereiche des Formulars sich auf die selektierten Elemente und Attribute beziehen. Innerhalb des <xed:bind /> Elementes können beliebige HTML- oder XEditor-Elemente ineinander geschachtelt werden, so dass sich eine hierachische Abbildung zwischen XML-Dokumente und HTML-Formular ergibt. <xed:bind xpath="mods:titleinfo"> <xed:bind xpath="mods:title"> <div> <label for="title">titel:</label> <input id="title" type="text" /> </div> </xed:bind> <xed:bind xpath="mods:subtitle"> <div> <label for="subtitle">untertitel:</label> <input id="subtitle" type="text" /> </div> </xed:bind> </xed:bind> Seite 6 von 28

7 In diesem Beispiel bezieht sich das Eingabefeld mit der ID "title" auf das XML-Element mods:titleinfo/mods:title, das Eingabefeld mit der ID "subtitle" auf das XML-Element mods:titleinfo/mods:subtitle. Der XEditor setzt dabei für HTML input-elemente vom Typ text, password, hidden, file, color, date, datetime, datetime-local, , month, number, range, search, tel, time, url, week automatisch Attribute, für HTML checkboxund radio-elemente Attribute, sowie für HTML select/ option Elemente Attribute. Das der Eingabekomponente wird dabei auf den absoluten XPath des XML-Knotens gesetzt, der durch das aktuelle Bindung durch die verschachtelten <xed:bind /> Elemente ausgewählt wurde. Die werde so gesetzt, dass ihr Wert dem Inhalt des selektierten Knotens entspricht. Ein XEditor-Formular kann also so gestaltet werden, dass man den Entwurf mit einem HTML-Formular beginnt, Attribute der Eingabekomponenten entfernt und diese funktional duch umgebende <xed:bind /> Elemente ersetzt. XML-Dokument, das durch das Formular bearbeitet wird: <document> <title>titel der Publikation</title> <services> <service>oai</service> <services> </document> XEditor, der dieses Dokument bearbeitet: <xed:bind xpath="document"> <xed:bind xpath="title"> <div> <label>titel:</label> <input type="text" /> </div> </xed:bind> <xed:bind xpath="services/service"> <div> <label>dienste:</label> <input type="checkbox" value="oai" />Über OAI-Schnittstelle publizieren <input type="checkbox" value="pod" />Print on Demand anbieten </div> </ xed:bind> </xed:bind> Resultierendes HTML: <div> <label>titel:</label> <input type="text" name="/document/title" value="titel der Publikation" /> </div> <div> <label>dienste:</label> <input type="checkbox" value="oai" name="/document/service" checked="checked" />Über OAI-Schnittstelle publizieren <input type="checkbox" value="pod" name="/document/service" />Print on Demand anbieten </div> Prädikate und Generieren von XML-Knoten Der XPath-Ausdruck kann beliebige Prädikate enthalten, z. B. <xed:bind <div> <label for="title_en">englische Übersetzung des Titels:</label> <input id="title_en" type="text" /> </div> </xed:bind> Falls der angegebene XPath-Ausdruck keinen bereits existierenden XML-Knoten selektiert, wird dieser automatisch generiert. Dabei werden auch alle angegebenen Seite 7 von 28

8 Prädikate berücksichtigt. Es gilt die Einschränkung, dass der XPath-Ausdruck nur Elemente und Attribute auf der Child-Achse generieren kann und keine XPath- Funktionen oder -Operatoren (bis auf den Vergleichsoperator) verwenden darf. Ausdrücke oder Prädikate, die nicht generiert werden können, werden ignoriert. <xed:bind <label>autor:</label> <input type="text"... /> </xed:bind> erzeugt, falls kein mods:name Element existiert, das alle Prädikate erfüllt, folgende XML-Elemente: <mods:name type="personal"> <mods:role> <mods:roleterm type="code" authority="marcrelator">aut</mods:roleterm> </mods:role> <mods:displayform /> </ mods:name> Gleichzeitig wird dem Eingabefeld das mods:displayform" zugewiesen. <xed:bind [contains('aut edt',mods:role/mods:roleterm)]" /> Falls kein mods:name Element existiert, das alle diese Prädikate erfüllt, wird ein neues Element <mods:name type="personal" /> generiert. Aus dem zweiten Prädikat kann wegen der Verwendung der contains() Funktion nicht allgemeingültig abgeleitet werden, welche XML-Knoten zu generieren wären, damit es erfüllt ist. Dieses Prädikat wird daher ignoriert. Bei der Implementierung des Formulars muss der Entwickler selbst sicherstellen, dass diese Bedingung nachträglich auch für neu generierte Knoten erfüllt wird, in diesem Fall z. B. indem für mods:roleterm eine Auswahlliste angeboten wird. Die Generierung fehlender XML-Elemente und -Attribute erfolgt bereits im Moment der Verarbeitung des XEditor-Formulars, schon vor der Darstellung im Browser. D.h. dass sich zum Zeitpunkt der Anzeige des HTML-Formulars alle im Formular enthaltenen Eingabekomponenten auf bereits existierende oder neue, leer generierte Elemente oder Attribute beziehen. Beim Abschicken des Formulars werden die Textknoten der XML-Element bzw. die Werte der Attribute entsprechend aus den abgeschickten Formularwerten gesetzt. Es ist auch möglich, leere <xed:bind /> Elemente zu verwenden, um XML-Knoten nur zu generieren oder deren Existenz sicherzustellen, ohne dafür Eingabekomponenten im HTML-Formular zu definieren. <xed:bind xpath="sortby"> <xed:bind /> <xed:bind / > </xed:bind> Seite 8 von 28

9 4.3.3 Default- und Initialwerte Das optionale legt einen Wert fest, der als Default-Wert verwendet wird, wenn der XML-Knoten neu generiert wird, oder aber vor oder nach der Bearbeitung im Formular leer ist, d.h. keinen Textwert hat. Beispiele: <xed:bind default="10"> <select id="numperpage"> <option>5</option> <option>10</option> <option>20</option> <option>50</option> </ select> </xed:bind> <xed:bind xpath="mods:genre" default="article" /> Das optionale legt einen Wert fest, der nur dann als initialer Wert verwendet wird, falls der XML-Knoten nicht bereits existiert und neu generiert wird. Im Gegensatz wird dieser Wert aber nicht gesetzt, wenn der Knoten existiert oder wenn er durch die Eingabe leer gesetzt wird. Das ist insbesondere bei einzeln stehenden Checkboxen als Sonderfall erforderlich: <xed:bind initially="true" default="false"> <input type="checkbox" value="true" /> Dokument publizieren </xed:bind> Sofern das im bearbeiteten XML noch nicht existiert, wird es generiert. Die Checkbox ist dann aktiviert, da sie hat. Sofern das im bearbeiteten XML schon existiert (mit entweder "true" oder "false", wird es mit dem existierenden Wert im Formular übernommen. Die Checkbox ist aktiviert, falls das existierende Attribut den Wert "true" hat, ansonsten ist sie nicht aktiviert. Wenn vor Absenden des Formulars die Checkbox deaktiviert wurde, übermittelt der Browser beim Absenden keinen Wert. In diesem Fall setzt der XEditor als Default- da das Attribut leer übermittelt wird. Das optionale legt einen Wert fest, der beim Aufbau des Formulars immer als initialer Wert gesetzt wird, und der den bisherigen Wert überschreibt, auch wenn der XML-Knoten bereits existiert. <xed:bind xpath="version" set="2.0" /> setzt in jedem Fall das XML-Element auf <version>2.0</version>, auch wenn bereits ein <version /> Element mit anderem Wert existierte. Der XPath-Ausdruck und die weiteren Attribute von <xed:bind /> können auch auf Variablen zugreifen, wobei HTTP Request Parameter aus der URL des Aufrufs, Konfigurationswerte aus mycore.properties oder Werte aus der MCRSession verwendet werden können. <xed:bind <xed:bind xpath="mods:genre" initially="{$genre}" / > setzt bei Aufruf des Formulars mit [Seite].xed?genre=article das Element <mods:genre>article</mods:genre>, sofern noch kein mods:genre Element existiert. Seite 9 von 28

10 Die durch <xed:bind /> ausgewählten XML-Elemente oder Attribute können unter einer Variablen abgelegt werden, die an nachfolgender Stelle in XPath-Ausdrücken wiederverwendet werden kann. Das spezifiziert den Namen der Variablen. <xed:bind xpath="mods:name"> <xed:bind name="id_name" /> Name: <input type="text" /> <xed:bind Notiz: <input type="text" /> </xed:bind> </xed:bind> Im Beispiel wird der Wert von in der Variablen $id_name abgelegt, und später das entsprechende mods:note Element selektiert, das in seinem diese ID referenziert. 4.4 Wiederholbare Bereiche Bereiche mit <xed:repeat /> wiederholbar machen <xed:repeat /> ist eine Variante von <xed:bind /> für wiederholbare Formularbereiche, die einem wiederholbaren Element im bearbeiteten XML-Dokument entsprechen. In einem Formular für Publikationsdaten können so z. B. Eingabebereiche für die Daten mehrerer Autoren wiederholt werden. Der Benutzer kann über Buttons die wiederholten Abschnitte vertauschen, einzelne entfernen oder weitere einfügen. <xed:repeat xpath="..." min="..." max="..." method="...">...</xed:repeat> Das kann ein beliebiger XPath 1.0 Ausdruck sein, der ein oder mehrere wiederholte Elemente im zu bearbeiteten XML selektiert. Der durch <xed:repeat /> umschlossene Bereich wird so oft im Formular wiederholt eingefügt, wie die Anzahl der durch den XPath-Ausdruck selektierten Elemente. Ist das angegeben, wird der Bereich mindestens so oft wie darin angegeben wiederholt. Selektiert der XPath-Ausdruck weniger Elemente, werden weitere Elemente erzeugt, Elemente vorhanden sind. <xed:repeat min="2"> <div> <xed:bind <label>vorname:</label><input type="text" / > </xed:bind /> <br /> <xed:bind xpath="mods:namepart[@type='family']"> <label>nachname:</label><input type="text" /> </xed:bind> </div> </xed:repeat> Das Beispiel wiederholt einen Bereich zur Eingabe von Personen im MODS Datenmodell mit Vorname und Nachname. Wenn im bearbeiteten XML drei mods:name[@type='personal'] Elemente vorhanden sind, wird der Bereich dreimal wiederholt und jeder wiederholte Abschnitt an das entsprechende XML-Element gebunden. Wenn aktuell nur ein mods:name[@type='personal'] vorhanden ist, wird ein weiteres Element erzeugt, und es werden zwei Bereiche für Personennamen im Formular dargestellt. Seite 10 von 28

11 Das optionale gibt an, auf welche Weise neue Elemente erzeugt werden. Mit method="build" wird ein neues Element über den XPath- Ausdruck gebaut, analog zum Verhalten von xed:bind, d.h. alle über Prädikate angegebenen Attributwerte (und ggf. weitere Unterstrukturen) werden erzeugt. Mit method="clone" wird ein neues Element durch Klonen des vorangehenden Elementes inkl. aller Kindelemente, Attribute und Textknoten erzeugt. Wenn das nicht angegeben ist, wird das Default-Verhalten durch das Property MCR.XEditor.InsertTarget.DefaultMethod=build festgelegt. Das gibt an, wie oft der Bereich maximal wiederholt werden kann, wenn der Benutzer einen Button zum Einfügen einer weiteren Wiederholung klickt. Allerdings wird immer mindestens so oft wiederholt, wie bereits Elemente im bearbeiteten XML- Dokument vorhanden sind Buttons zum Bearbeiten wiederholter Bereiche: <xed:controls /> <xed:controls /> bestimmt Art und Position der Buttons zur Bearbeitung des wiederholten Bereiches. Diese Buttons werden als Submit Buttons implementiert, d.h. bei Klick auf den Button wird das Formular abgeschickt, die Änderung serverseitig durchgeführt und im Anschluss das veränderte Formular neu dargestellt. Die Position der Buttons kann an beliebiger Stelle innerhalb des durch <xed:repeat /> umschlossenen Bereiches frei bestimmt werden. Das Element <xed:controls /> wird an der Position eingefügt, wo die Buttons erscheinen sollen. Der Text von <xed:controls /> bestimmt, welche Buttons an der jeweiligen Stelle erscheinen. Möglich sind ein oder mehrere durch Leerzeichen getrennte Werte: Ein "up" Button erscheint ab dem zweiten Element und vertauscht es im Formular und im bearbeiteten XML-Dokument mit seinem Vorgänger. Ein "down" Button erscheint bei allen bis auf das letzte Element und vertauscht es im Formular und im bearbeiteten XML-Dokument mit seinem Nachfolger. Ein "remove" Button entfernt das aktuelle Elemente im Formular und im XML- Dokument. Ein "insert" Button fügt hinter dem aktuellen Element einen neues Element ein und stellt es im Formular dar. Ein "append" Button kann als Alternative zu "insert" verwendet werden und erscheint nur für das letzte Element, um nur am Ende ein weiteres Element einzufügen. Ein leeres <xed:controls /> Element entspricht der Standard-Auswahl <xed:controls>insert remove up down</xed:controls> Sollen keine Buttons erscheinen, lässt man das <xed:controls /> Element weg. Sollen nur bestimmte Buttons erscheinen, gibt man diese im Text des Elementes an. Seite 11 von 28

12 <xed:repeat min="2"> <div>... <xed:controls>append remove up down</xed:controls> </div> </xed:repeat> HTML-Formatierung und Layout der Buttons werden durch ein XSL-Template in xeditor-custom.xsl definiert und können durch lokales Überschreiben in der eigenen Webanwendung beliebig angepasst werden. Das Template wird für jeden Button einzeln aufgerufen. Das Template muss einen Parameter $name als Name des Buttons setzen und so beim Absenden des Formulars durchreichen. Die Buttons können als HTML <button />, <input type="submit" /> oder <input type="image" /> implementiert werden. <xsl:template match="text()" mode="xed.control"> <!-- append insert remove up down --> <xsl:param name="name" /> <!-- name to submit as request parameter when button/image is clicked --> <xsl:if test=".='append'"> <input type="submit" value="+" name="{$name}" /> </xsl:if>... </xsl:template> IDs generieren Über die Funktion xed:generate-id() kann eine eindeutige ID für den gerade via xed:bind / xed:repeat ausgewählten XML-Knoten generiert werden. Diese IDs benötigt man, um im HTML Quellcode z. B. eindeutige Referenzen für die zugehörigen Labels zu haben. xed:generate-id([xpath]) Im folgenden Beispiel wird für jede Wiederholung des Eingabefeldes für mods:namepart eine eindeutige ID generiert: <xed:repeat xpath="mods:name[@type='personal']" min="2"> <div> <xed:bind xpath="mods:namepart[@type='given']"> <label for="{xed:generate-id()}">vorname:</ label> <input type="text" id="{xed:generate-id()}" /> </xed:bind />... </div> </ xed:repeat> 4.5 Ausgabe von Werten und mehrsprachigen Bereichen Werte ausgeben mit <xed:output /> <xed:output value="..." i18n="..." /> Ermöglicht die Ausgabe eines Wertes. Der Wert kann über einen XPath-Ausdruck definiert werden und/oder das aktuelle Binding im bearbeiteten XML-Dokument verwenden. Auch eine Kombination mit mehrsprachigen Bezeichnern aus messages- *.properties Dateien ist möglich. Seite 12 von 28

13 Wenn kein Attribut angegeben ist, wird der erste durch das aktuelle Binding ausgewählte Wert ausgegeben. <xed:bind xpath="title"> <label>titel:</label> <xed:output /> </xed:bind> Wenn das angegeben ist, wird der darin enthaltene XPath-Ausdruck ausgewertet und ausgegeben. Der XPath-Ausdruck kann die XML-Struktur des bearbeiteten Dokumentes, sowie Variablen verwenden, die aus HTTP Request Parametern, Konfigurationsparametern aus mycore.properties oder MCRSession Variablen stammen. Beispiele: <label>name: </label> <xed:output /> <xed:bind xpath="title"> Diese Publikation mit dem Titel "<xed:output />" dürfen Sie als <xed:output value="$someuser" /> bearbeiten. </xed:bind> Wenn das angegeben ist, wird der mehrsprachige Bezeichner aus den messages-*.properties Dateien ausgegeben, dessen Schlüssel angegeben ist. <label> <xed:output i18n="edit.title" />: </label> Das kann auch Variablen enthalten, die dann, wie in einem XPath- Ausdruck, ersetzt werden. Wenn sowohl das als auch das angegeben ist, wird zunächst der XPath-Ausdruck aus dem ausgewertet, und der resultierende Wert in den mehrsprachigen Bezeichner eingesetzt. Der Bezeichner in den messages-*.properties Dateien muss einen entsprechenden Platzhalter vorsehen. In messages-de.properties: edit.datepublished=das Dokument wurde am {0} veröffentlicht. In messages-en.properties: edit.datepublished=the document was publised at {0}. <label> <xed:output i18n="edit.datepublished" /> </ label> Ausgabe eines Wertes innerhalb von HTML-Attributen {XPath} oder {i18:key} oder {i18n:key,xpath} oder {i18n:translate(...)} Enthält ein Attribut einen Ausdruck, der durch geschweifte Klammern umschlossen ist, wird dieser Ausdruck ausgewertet und an dieser Stelle im Attribut eingesetzt. Bei dem Ausdruck kann es sich um einen XPath-Ausdruck handeln, oder um einer mehrsprachigen Bezeichner aus den messages-*.properties Dateien. Der XPath-Ausdruck kann die XML- Struktur des bearbeiteten Dokumentes, sowie Variablen verwenden, die aus HTTP Request Parametern, Konfigurationsparametern aus mycore.properties oder MCRSession Variablen stammen. Beispiele: Seite 13 von 28

14 <img /> <a href="{$webapplicationbaseurl}receive/ zum reverenzierten Objekt</a> Wenn der Ausdruck mit "i18n:" beginnt, wird der mehrsprachige Bezeichner aus den messages-*.properties Dateien ausgegeben, dessen Schlüssel angegeben ist. Es ist möglich, einen XPath-Ausdruck mit einem i18n Schlüssel zu kombinieren, indem Schlüssen und XPath Ausdruck durch ein Komma getrennt werden. In diesem Fall wird zunächst der XPath-Ausdruck ausgewertet, und der resultierende Wert in den mehrsprachigen Bezeichner eingesetzt. Der Bezeichner in den messages-*.properties Dateien muss einen entsprechenden Platzhalter vorsehen. Alternativ kann - wie in XSL Stylesheets - die Funktion i18n:translate(...) aufgerufen werden, die einem Aufruf der Methoden der Java-Klasse org.mycore.services.i18n.mcrtranslation entspricht. Beispiele: <input type="submit" xed:target="cancel" value="{i18n:label.cancel}" /> <input type="text" placeholder="{i18n:translate('placeholder.date.issued')}" /> <img alt="{i18n:image.title,title[@type='main']}" src="{@href}" /> Mehrsprachige Formularbereiche: <xed:multi-lang> Ermöglicht es, abhängig von der aktuell verwendeten Sprache (Variable $CurrentLang der MCRSession), Teile des Formulars in verschiedenen Varianten anzubieten. <xed:multi-lang> <xed:lang xml:lang="..."></xed:lang> <xed:lang xml:lang="..."></ xed:lang> </xed:multi-lang> Das definiert die Sprache (nach IETF BCP 47), für die der umschlossene Block verarbeitet und angezeigt werden soll. Wenn kein <xed:lang / > Bereich für die aktuelle Sprache definiert ist, wird der Bereich verwendet, der für die Default-Sprache (MCR.Metadata.DefaultLang aus mycore.properties) definiert ist. Wenn auch für die Default-Sprache kein Bereich definiert ist, wird der erste <xed:lang /> Bereich verwendet. <xed:multi-lang> <xed:lang xml:lang="de"> <label>straße:</label>... <label>hausnummer:</label>... <label>plz:</label>... <label>ort:</label>... </ xed:lang> <xed:lang xml:lang="en"> <label>number:</label>... <label>street:</label>... <label>city:</label>... <label>zip Code:</label>... </xed:lang> </xed:multi-lang> Ausgabe mittels externer XML Ressourcen: <xed:load-resource> Lädt ein XML-Dokument von einer URI und stellt es in einer Variablen bereit, um in XPath-Ausdrücken darauf zuzugreifen. Seite 14 von 28

15 <xed:load-resource name="..." uri="..." /> Das gibt den Namen der Variablen an, unter dem das XML-Element bereitgestellt werden soll. Das gibt die URI an, von der das XML geladen werden soll. Dies kann eine beliebige URI sein, die der MyCoRe URI Resolver unterstützt (z. B. classification:, resource:, webapp:, file:, Innerhalb des kann auch auf XPath Ausdrücke oder Variablen zugregriffen werden. <xed:load-resource /> kann in Kombination mit <xed:output /> verwendet werden, um Werte im Formular auszugeben, die sowohl vom bearbeiteten XML als auch von Parametern oder externen XML-Ressourcen abhängen. Beispielsweise kann man Bezeichnungen von Klassifikationskategorien im Formular ausgeben, wobei die IDs der Kategorien im im bearbeiteten XML-Dokument liegen, die Bezeichnungen aber in der Klassifikation verwaltet werden: <xed:load-resource name="genres" uri="classification:metadata:-1:children:modsgenre" / > lädt die Klassifikation "modsgenre" und stellt sie in einer Variablen $genres bereit. <xed:bind xpath="mods:genre" name="genre" /> wählt das Element mods:genre und stellt es in der Variablen $genre bereit. <xed:output value="$genres//category[@id=$genre]/label[lang($currentlang)]/@text" / > gibt dann die Bezeichnung der Kategorie aus der Klassifikation aus, deren ID der Wert von <mods:genre /> ist, in der aktuellen Sprache. 4.6 Das Formular absenden Abbruch-URL definieren: <xed:cancel /> <xed:cancel url="..." /> <xed:cancel url="/receive/{$id}" /> Definiert die URL, zu der bei Abbruch zurückgekehrt werden soll, z. B. bei Betätigen eines Abbrechen-Buttons, um die Bearbeitung aus dem Formular heraus abzubrechen. <xed:cancel /> sollte angegeben werden, wenn das Formular einen Abbrechen- Button enthält. Wenn eine relative URL angegeben ist, wird diese als relativ zu der Seite interpretiert, die das Formular enthält. Wenn ein absoluter Pfad angegeben ist, wird dieser als relativ zur Basis-URL der Webanwendung interpretiert. Wenn eine vollständige URL angegeben ist, wird diese unverändert verwendet. Wenn keine URL angegeben ist, wird zur Basis-URL der Webanwendung geleitet. Seite 15 von 28

16 Das kann optional ein oder mehrere Variablen enthalten, die bei Aufruf des Formulars durch Parameter ersetzt werden. Variablen stehen in geschweiften Klammern und beginnen mit einem $ Zeichen, z. B. <xed:cancel url="/receive/{$id}" /> Die Variablen werden bei Aufruf des Formulars durch den konkreten Wert ersetzt, wobei als Quelle die HTTP Request Parameter aus der URL des Aufrufs, Konfigurationswerte aus mycore.properties oder Werte aus der MCRSession verwendet werden können. <xed:cancel /> ist wiederholbar. Wenn mehrere <xed:cancel /> Elemente angegeben sind, wird das erste Element verwendet, das keine Variablen enthält, oder bei dem alle angegebenen Variablen durch konkrete Werte ersetzt werden können. So kann man z. B. abhängig von Aufrufparametern bei Abbruch zu verschiedenen Zielseiten zurückkehren. <xed:cancel url="/receive/{$id}" /> <xed:cancel url="/index.xml" /> Wenn das Formular mit [Seite].xed?id=DocPortal_document_ aufgerufen wird, wird bei Abbruch zur Seite /receive/docportal_document_ zurückgekehrt. Wenn das Formular ohne Parameter aufgerufen wird, wird zur Seite index.xml zurückgekehrt. Es wäre auch denkbar, die komplette URL als Parameter zu übergeben. Davon kann nur abgeraten werden, da es die Aufruf-URLs unnötig lang macht, Implementierungsdetails offenlegt und potentiell zu Sicherheitslücken führt: <xed:cancel url="{$cancelurl}" /> Aufruf mit [Seite].xed?cancelURL=receive/ DocPortal_document_ Submit-Buttons definieren <input type="submit image" xed:target="..."... /> oder <button type="submit" xed:target="..."... /> Submit-Buttons schicken das Formular ab. Das gibt das Ziel an und kann verschiedene Werte annehmen. Alle weiteren Eigenschaften der Buttons werden über gewöhnliche HTML Syntax gestaltet. Vordefiniert sind die folgenden Ziele: xed:target="cancel" xed:target="debug" xed:target="layout" Bearbeitung abbrechen Für das Debugging, zeigt das bearbeitete XML und die Bearbeitungsschritte im Browser an Für das Debugging, zeigt das bearbeitete XML über den MyCoRe LayoutService an (d.h. durch Seite 16 von 28

17 einen Transformer, der üblicherweise via XSL Stylesheet zu HTML rendert) xed:target="servlet" xed:target="subselect" Sendet das resultierende XML-Dokument an ein Servlet Externe Auswahl von Werten, siehe unter Subselects Abbrechen-Buttons definieren <input type="submit image" xed:target="cancel"... /> oder <button type="submit" xed:target="cancel"... /> Abbrechen-Buttons können auf verschiedene Weise gestaltet werden. Das weist die Buttons als Abbrechen-Buttons aus. Alle weiteren Eigenschaften der Buttons werden über gewöhnliche HTML Syntax gestaltet. Die URL, zu der bei Betätigen des Buttons zurückgekehrt wird; wird über das Element <xed:cancel /> definiert. <input type="submit" class="roundedbutton" xed:target="cancel" value="{i18n:button.cancel}" /> In diesem Beispiel wird die sprachabhängige Beschriftung des Buttons mit value="{i18n:button.cancel}" aus dem Schlüssel button.cancel aus den messages- *.properties Dateien gelesen Debug-Buttons definieren <input type="submit image" xed:target="debug"... /> oder <button type="submit" xed:target="debug"... /> Ein Debug-Button ist während der Implementierung eines Formulars nützlich, um anzuzeigen, welches XML-Dokument aus der Bearbeitung im Formular resultiert, ohne dieses an das Zielservlet zu senden. Das weist die Buttons als Abbrechen-Buttons aus. Alle weiteren Eigenschaften der Buttons werden über gewöhnliche HTML Syntax gestaltet. <input type="submit" class="roundedbutton" xed:target="debug" value="debug" /> Submit-Buttons zum Absenden an ein Servlet <input type="submit image" xed:target="servlet" xed:href="..."... /> oder <button type="submit" xed:target="servlet" xed:href="..."... /> Seite 17 von 28

18 Das definiert, dass beim Absenden des Formulars das resultierende XML via Request Dispatching an ein Ziel-Servlet gesendet werden soll. Das gibt die URL oder den Namen dieses Servlets an, so wie er in der web.xml der Anwendung definiert ist. Alle weiteren Eigenschaften der Buttons werden über gewöhnliche HTML Syntax gestaltet. <input type="submit" class="roundedbutton" xed:target="servlet" xed:href="mcrsearchservlet" value="{i18n:button.search}" /> In diesem Beispiel wird die sprachabhängige Beschriftung des Buttons mit value="{i18n:button.search}" aus dem Schlüssel button.search aus den messages- *.properties Dateien gelesen. Der Button schickt das resultierende XML-Dokument, hier angenommen die XML-Darstellung einer Suchanfrage, an das MCRSearchServlet, um eine Suche auszuführen. Das Ziel-Servlet erhält das resultierende XML-Dokument als JDOM Document in einem Request Attribut mit dem Schlüssel MCRXEditorSubmission übergeben: HttpServletRequst request; org.jdom.document xml = (org.jdom.document) (request.getattribute("mcrxeditorsubmission")); Sofern Validierungsregeln angegeben sind, wird das Zielservlet nur aufgerufen, wenn die Validierung erfolgreich ist. Wenn sie nicht erfolgreich ist, wird zum Formular zurückgekehrt und auf die fehlerhafte Eingabe hingewiesen. 4.7 Eingabevalidierung und Nachbearbeitung Eingabevalidierung Die Eingabevalidierung erfolgt im XEditor-Framework serverseitig nach Absenden des Formulars. Davon unberührt bleibt die Möglichkeit, mit eigenen Mitteln (HTML5, JavaScript) zusätzlich eine clientseitige Validierung im Browser zu implementieren. Die Validierungsregeln beziehen sich auf die Knoten des bearbeiteten XML-Dokumentes, d.h. auf die Werte von XML-Elementen und Attributen im resultierenden XML, nicht auf einzelne Eingabefelder. Dies erleichtert es besonders, Validierungsregeln an unterschiedlichen Stellen oder in verschiedenen Formularen wiederzuverwenden. Wenn das Formular abgeschickt wird, werden alle gesetzten Validierungsregeln serverseitig geprüft. Schlägt die Validierung fehl, wird das Formular erneut angezeigt. Es besteht die Möglichkeit, an beliebiger Stelle Meldungen auszugeben, um anzuzeigen, welche Regeln nicht erfüllt sind Validierungsregeln mit <xed:validate> Setzt eine Validierungsregel. Die Validierungsmethode wird durch ein oder mehrere kombinierbare Attribute spezifiziert. Seite 18 von 28

19 Auf welchen XML-Knoten sich die Validierungsregel bezieht, kann auf zwei Weisen festgelegt werden: Lokale Validierungsregeln stehen innerhalb eines <xed:bind /> Elementes und beziehen sich auf das dadurch gebundene XML. <xed:bind xpath="mods:dateissued"> <input type="text"... /> <xed:validate required="true" /> </xed:bind> oder auch unabhängig von der Position des konkreten Eingabefeldes <xed:bind xpath="mods:dateissued"> <xed:validate required="true" /> </xed:bind>... <xed:bind xpath="mods:dateissued"> <input type="text"... /> </xed:bind> Globale Validierungsregeln stehen an beliebiger Stelle im Formular und beziehen sich auf die durch das ausgewählten XML-Knoten. <xed:validate matches="[\dx]{4}\-[\dx]{4}" /> validiert die Syntax aller auftretenden Elemente. Globale Validierungsregeln erleichtern die Wiederverwendung und können bevorzugt für Syntaxprüfungen verwendet werden. Ist das gesetzt, ist das gewählte Element ein Pflichfeld, d.h. es muss mindestens ein nicht leerer Wert (bei wiederholten Elementen) auftreten. Das gibt einen regulären Ausdruck in der Syntax von java.util.regex.pattern an, gegen den der Text des XML-Elementes oder Attributes validiert wird. <xed:validate matches="[\dx]{4}\-[\dx]{4}" /> Das gibt einen XPath Test an, gegen den ein XML-Knoten validiert wird. <xed:validate xpath="/document/validto" test="(string-length(.) = 0) or (number(.) >= number(../validfrom))" /> prüft, ob /document/validto >= /document/validfrom ist. <xed:validate xpath="/user" test="password = passwordrepeated" /> prüft, ob das eingegebene Passwort mit dessen Wiederholung identisch ist. @type, validieren auf die gleiche Weise wie im alten Editor Framework (siehe dort). Beispiele: <xed:validate xpath="document/yearissued" min="2000" type="integer" /> stellt sicher, dass es sich beim Erscheinungsjahr um eine ganze Zahl >= 2000 handelt. <xed:validate xpath="//mods:*[@encoding='w3cdtf']" matches="\d{4}(\-d{2}(\- d{2})?)?" type="datetime" format="yyyy;yyyy-mm;yyyy-mm-dd" /> validiert alle Datumsangaben, so dass sie entweder nur das Jahr, Jahr plus Monat oder Jahr, Monat und Tag in MODS W3CDTF Syntax enthalten. Seite 19 von 28

20 Validierungsmeldungen ausgeben Wenn die Eingabevalidierung fehlschlägt, wird die Variable $xed-validation-failed='true' gesetzt. <xed:if test="$xed-validation-failed"> Bitte korrigieren Sie die fehlerhaften Eingaben! </ xed:if> Das Attribut definiert, an welcher Stelle die Validierungsnachricht ausgegeben werden soll, falls die Validierungsregel nicht erfüllt Ausgabe der Meldung an genau dieser Stelle, d.h. dort, wo die Validierungsregel im Formular definiert Ausgabe der Meldung an einer lokalen Stelle in der Nähe der Eingabekomponente. Die Meldung wird dort ausgegeben, wo das umgebende <xed:bind /> den nicht validen XML-Knoten selektiert, und wo darin enthalten das Element <xed:display-validation-message /> angegeben ist. <xed:bind xpath="title"> <xed:display-validation-message /> <input type="text" / > <xed:validate display="local" required="true">bitte geben Sie einen Titel ein!</ xed:validate> Ausgabe der Meldung an globaler Stelle, gesammelt mit anderen Meldungen. Die Meldung wird dort ausgegeben, wo das Element <xed:display-validation-message /> auftritt. <xed:if test="$xed-validation-failed"> Bitte korrigieren Sie die folgenden fehlerhaften Eingaben: <xed:display-validation-messages /> </xed:if>... <xed:bind xpath="title"> <input type="text" /> <xed:validate display="global" required="true">bitte geben Sie einen Titel ein!</xed:validate> </xed:bind> Es ist auch möglich, die Fehlermeldung an mehreren Stellen auszugeben, indem man mehrere Werte im durch Leerzeichen getrennt angibt. Die Fehlermeldung wird entweder durch das von <xed:validate /> umschlossene HTML gebildet, oder über einen i18n-schlüssel mehrsprachig aus den messages- *.properties Dateien gelesen. <xed:validate... required="true" i18n="editor.title.required" /> <xed:validate... required="true"> Dieses Feld ist ein <strong>pflichtfeld</strong>! </xed:validate> HTML-Formatierung und Layout der Fehlermeldung werden durch XSL-Templates in xeditor-custom.xsl definiert und können durch lokales Überschreiben in der eigenen Webanwendung beliebig angepasst werden. <xsl:template match="xed:validate" mode="message"> <span class="help-inline"> <xsl:apply-templates select="node()" mode="xeditor" /> </span> </xsl:template> umgibt alle ausgegebenen Fehlermeldungen mit einem <span class="helpinline" />. Eingabekomponenten mit fehlerhaften Eingaben können ausserdem markiert werden, z. B. mit eigenen CSS-Klassen oder Stilen. Dazu wird für jeden validierten XML-Knoten Seite 20 von 28

21 die Variable $xed-validation-marker gesetzt. Der Wert, der in dieser Variable enthalten ist, ist über die mycore.properties konfigurierbar und wird typischerweise ein oder mehrere CSS-Klassen enthalten: MCR.XEditor.Validation.Marker.error=has-error MCR.XEditor.Validation.Marker.success=has-success MCR.XEditor.Validation.Marker.default= Wenn die Validierungsregel verletzt ist, wird die Variable $xed-validation-marker auf den Wert von MCR.XEditor.Validation.Marker.error gesetzt. Der Wert von MCR.XEditor.Validation.Marker.success wird gesetzt, wenn die Validierungsregel erfüllt ist, d.h. es wurde validiert und der XML-Knoten ist valide. Der Wert von MCR.XEditor.Validation.Marker.default wird gesetzt, wenn die Eingabekomponente nicht validiert wurde (z. B. weil keine Regel angegeben ist). Die Werte können auch leer sein, um z. B. nur fehlerhafte Komponenten zu markieren. <xed:bind xpath="year"> <div class="form-group {$xed-validation-marker}"> <input type="text" /> <xed:validate display="here" required="true">bitte Jahr eingeben!</ xed:validate> </div> </xed:bind> Wenn das Element <year /> nicht eingegeben wird, bekommt das umgebende <div /> Element die has-error". Wenn das Jahr eingegeben und validiert wurde, aber das Formular noch einmal angezeigt wird, z. B. weil andere Komponenten nicht valide sind, bekommt das umgebende <div /> Element im Beispiel die has-success". Die Anwendung beschränkt sich nicht auf CSS-Klassen oder Stile. Je nach Definition in mycore.properties könnte z. B. auch ein placeholder gesetzt oder anderes HTML generiert werden. <xed:bind xpath="year"> <xed:if test="$xed-validation-marker = 'has-error'"> Vielleicht sollten Sie mal die <a href="anleitung.html">anleitung</a> lesen. </xed:if>... </ xed:bind> Resultierendes XML bereinigen: Cleanup-Rules <xed:cleanup-rule xpath="..." relevant-if="..." /> Cleanup-Rules sind Bereinigunsregeln, die logisch leere XML-Elemente oder -Attribute vor Übergabe an das Zielservlet aus dem resultierenden XML herauslöschen. Das gibt in Form eines XPath-Ausdruckes an, auf welche Elemente oder Attribute sich die Regel bezieht. Das gibt in Form eines XPath-Tests an, unter welchen Bedingungen diese XML-Knoten als relevant erachtet werden. Es gelten die folgenden Standard-Regeln: Seite 21 von 28

22 <xed:cleanup-rule relevant-if="string-length(.) > 0" /> <xed:cleanuprule xpath="//*" or * or (string-length(text()) > 0)" /> <xed:cleanuprule xpath="/mycoreobject/structure /mycoreobject/service" relevant-if="true()" /> Die Standard-Regeln entfernen leere Attribute und Elemente aus dem resultierenden XML-Dokument. Ein Element ist leer, wenn es keine Kindelemente, keine Attribute und keinen Text enthält. Ausnahmen bilden die <structure /> und <service / > Elemente eines MyCoRe-Objektes, die immer -auch leer- erhalten bleiben, um den Vorgaben des XML-Schemas zu entsprechen. Diese Regeln lassen sich durch eigene Regeln ergänzen oder auch ganz oder teilweise überschreiben. Die Regeln werden in der Reihenfolge der Deklaration angewandt, d.h. die zuletzt angegebene Regel "gewinnt"". Beispiel (Suchmaske): <xed:cleanup-rule xpath="//condition" relevant-if="string-length(@value) > 0" /> entfernt alle <condition /> Elemente, Attribut leer ist. In einer MyCoRe Suchmaske werden die Suchfelder als <condition /> Elemente dargestellt, mit den für das zu durchsuchende für den zu verwendenden Suchoperator, für den eingegebenen und zu suchenden Wert, z. B. <condition field="title" operator="contains" value="optik" /> Die werden in der Suchmaske durch hidden-felder oder Auswahllisten festgelegt. Wenn aber kein zu suchender Wert eingegeben wird, ist die gesamte Suchbedingung nicht relevant, und sie wird durch die Bereinigungsregel entfernt. Beispiel (MODS): <xed:cleanup-rule xpath="//mods:*" relevant-if="(string-length(text()) > 0) or mods:* or (string-length(@xlink:href) > 0)" /> <xed:cleanup-rule xpath="//mods:name" relevant-if="mods:namepart" /> Im MODS Datenmodell werden Personennamen z. B. wie folgt dargestellt: <mods:name type="personal"> <mods:namepart type="given">john</namepart> <mods:namepart type="family">huston</namepart> <mods:role> <mods:roleterm type="code" authority="marcrelator">aut</roleterm> </mods:role> </mods:name> Angenommen, ein Eingabeformular besitzt für an einer Publikation beteiligte Personen Eingabefelder für Vor- und Nachname (mods:namepart), sowohl eine Auswahlliste für die Rolle (Autor, Herausgeber etc. entsprechend mods:roleterm). Dann entfernt die zweite Bereinigungsregel das mods:name Element, wenn keine mods:namepart Elemente vorhanden sind, d.h. keine Namensteile eingegeben wurden. Die erste Bereinigungsregel entfernt alle mods Elemente, die keine anderen mods Elemente enthalten, oder kein xlink:href Attribut. Somit wird das mods:namepart Element entfernt, wenn kein Text enthalten ist. Das ist nicht relevant, da die Standard-Regel für mods Elemente überschrieben wurde. Seite 22 von 28