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 (Menüpunkt links unten) zu finden.
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="http://www.mycore.de/xeditor"
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 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.
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.
|
|
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.
|
|
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
|
|
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 angeleht.
|
|
<form>
-Element von HTML.mcrobject:
Resolver ein MyCoRe Metadaten-Objekt (Dokument, Publikation o.ä.) zu laden.
Wenn das Formular im Browser über simpledoc.xed?id=skeleton_simpledoc_00000001
aufgerufen wird, wird das Objekt mit dieser ID geladen.
<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.
messages-*.properties
Dateien, verwendet.
UpdateObjectServlet
, das die Änderungen speichert.
... umschliesst das gesamte XEditor-Formular, entspricht dem HTML <form />
Element und wird in ein solches transformiert.
Das XEditor-Framework setzt das Attribut @action
des <form />
Elementes, damit die Formularwerte an das XEditor-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.
Syntax:
|
|
Beispiel:
|
|
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 Attribut @uri kann eine beliebige URI sein, die der MyCoRe URI Resolver unterstützt (z. B. mcrobject:, resource:, webapp:, file:, http:.) und gibt die Quelle an, von der das XML-Dokument gelesen wird.
Das Attribut @uri 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.
|
|
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.
Beispiel:
|
|
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:bind />
Legt die Abbildung zwischen Eingabe-Komponenten im HTML-Formular und -Knoten im XML-Dokument fest.
|
|
Das Attribut @xpath 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.
Beispiel:
|
|
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
, email
, month
, number
, range
, search
, tel
, time
, url
, week
automatisch die
@name
und @value
Attribute, für HTML checkbox- und radio-Elemente die @name
und @checked
Attribute, sowie für HTML select/option Elemente die @name
bzw. @selected
Attribute. Das Attribut @name 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 Attribute @value
bzw. @selected
oder @checked
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, dann die @name, @value, @checked, @selected
Attribute der
Eingabekomponenten entfernt und diese funktional duch umgebende <xed:bind />
Elemente ersetzt.
Beispiel:
XML-Dokument, das durch das Formular bearbeitet wird:
|
|
XEditor, der dieses Dokument bearbeitet:
|
|
Resultierendes HTML:
|
|
Der XPath-Ausdruck kann beliebige Prädikate enthalten, z. B.
|
|
Falls der angegebene XPath-Ausdruck keinen bereits existierenden XML-Knoten selektiert, wird dieser automatisch generiert. Dabei werden auch alle angegebenen 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.
Beispiel:
|
|
erzeugt, falls kein mods:name
Element existiert, das alle Prädikate erfüllt, folgende XML-Elemente:
|
|
Gleichzeitig wird dem Eingabefeld das Attribut @name=".../mods:name/mods:displayForm"
zugewiesen.
Beispiel: <xed:bind xpath="mods:name[@type='personal'][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. Beispiel:
|
|
Das optionale Attribut @default 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:
|
|
|
|
Das optionale Attribut @initially 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 zu @default 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:
|
|
@publish
im bearbeiteten XML noch nicht existiert, wird es als @publish="true"
generiert. Die Checkbox ist dann aktiviert, da sie den @value="true"
hat.@publish
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.@publish="false"
, da das Attribut leer übermittelt wird.Das optionale Attribut @set
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. Beispiel:
|
|
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. Beispiel:
|
|
<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.
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 Attribut @name spezifiziert den Namen der Variablen. Beispiel:
|
|
Im Beispiel wird der Wert von mods:name/@ID
in der Variablen $id_name
abgelegt, und später das entsprechende mods:note
Element selektiert, das
in seinem Attribut @xlink:href
diese ID referenziert.
<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.
Syntax:
|
|
Das Attribut @xpath 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 Attribut @min angegeben, wird der Bereich mindestens so oft wie darin angegeben wiederholt. Selektiert der XPath-Ausdruck weniger als @min Elemente,
werden weitere Elemente erzeugt, bis @min Elemente vorhanden sind.
Beispiel:
|
|
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, da @min="2", und es werden zwei Bereiche für Personennamen im Formular dargestellt.
Das optionale Attribut @method
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 Attribut @method nicht angegeben ist, wird das Default-Verhalten durch das Property MCR.XEditor.InsertTarget.DefaultMethod=build
festgelegt.
Das Attribut @max
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.
<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.
<xed:repeat />
umschlossenen Bereiches frei bestimmt werden.<xed:controls />
wird an der Position eingefügt, wo die Buttons erscheinen sollen.<xed:controls />
bestimmt, welche Buttons an der jeweiligen Stelle erscheinen. Möglich sind ein oder mehrere durch Leerzeichen getrennte Werte:
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.
Beispiel:
|
|
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.
Beispiel:
|
|
Ü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.
Syntax:
|
|
Im folgenden Beispiel wird für jede Wiederholung des Eingabefeldes für mods:namePart
eine eindeutige ID generiert:
|
|
<xed:output />
Syntax:
|
|
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.
Wenn kein Attribut angegeben ist, wird der erste durch das aktuelle Binding ausgewählte Wert ausgegeben. Beispiel:
|
|
Wenn das Attribut @value 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:
|
|
|
|
Wenn das Attribut @i18n angegeben ist, wird der mehrsprachige Bezeichner aus den messages-*.properties Dateien ausgegeben, dessen Schlüssel angegeben ist. Beispiel:
|
|
Das Attribut @i18n kann auch Variablen enthalten, die dann, wie in einem XPath-Ausdruck, ersetzt werden.
Wenn sowohl das Attribut @value als auch das Attribut @i18n angegeben ist, wird zunächst der XPath-Ausdruck aus dem Attribut @value ausgewertet, und der resultierende Wert in den mehrsprachigen Bezeichner eingesetzt. Der Bezeichner in den messages-*.properties Dateien muss einen entsprechenden Platzhalter vorsehen. Beispiel:
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}.
|
|
Syntax:
|
|
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:
|
|
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:
|
|
<xed:multi-lang>
Ermöglicht es, abhängig von der aktuell verwendeten Sprache (Variable $CurrentLang der MCRSession), Teile des Formulars in verschiedenen Varianten anzubieten.
Syntax:
|
|
Das Attribut @xml:lang 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.
Beispiel:
|
|
<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.
Syntax:
|
|
Das Attribut @name gibt den Namen der Variablen an, unter dem das XML-Element bereitgestellt werden soll. Das Attribut @uri 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:, http:.) Innerhalb des Attributes @uri 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:
|
|
lädt die Klassifikation "modsgenre" und stellt sie in einer Variablen $genres bereit.
|
|
wählt das Element mods:genre und stellt es in der Variablen $genre bereit.
|
|
gibt dann die Bezeichnung der Kategorie aus der Klassifikation aus, deren ID der Wert von <mods:genre />
ist, in der aktuellen Sprache.
<xed:cancel />
Syntax:
|
|
Beispiel:
|
|
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.
Das Attribut @url 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.
|
|
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.
Beispiel:
|
|
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:
|
|
Syntax:
|
|
Submit-Buttons schicken das Formular ab. Das Attribute @xed:target 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" | Bearbeitung abbrechen |
xed:target="debug" | Für das Debugging, zeigt das bearbeitete XML und die Bearbeitungsschritte im Browser an |
xed:target="layout" | Für das Debugging, zeigt das bearbeitete XML über den MyCoRe LayoutService an (d.h. durch einen Transformer, der üblicherweise via XSL Stylesheet zu HTML rendert) |
xed:target="servlet" | Sendet das resultierende XML-Dokument an ein Servlet |
xed:target="subselect" | Externe Auswahl von Werten, siehe unter Subselects |
Syntax:
|
|
Abbrechen-Buttons können auf verschiedene Weise gestaltet werden.
Das Attribut @xed:target="cancel" 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.
Beispiel:
|
|
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.
Syntax:
|
|
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 Attribut @xed:target="debug" weist die Buttons als Abbrechen-Buttons aus. Alle weiteren Eigenschaften der Buttons werden über gewöhnliche HTML Syntax gestaltet.
Beispiel:
|
|
Syntax:
|
|
Das Attribut @xed:target="servlet" definiert, dass beim Absenden des Formulars das resultierende XML via Request Dispatching an ein Ziel-Servlet gesendet werden soll. Das Attribut @xed:href 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.
Beispiel:
|
|
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:
|
|
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.
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.
<xed:validate>
Setzt eine Validierungsregel. Die Validierungsmethode wird durch ein oder mehrere kombinierbare Attribute spezifiziert.
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. Beispiel:
|
|
oder auch unabhängig von der Position des konkreten Eingabefeldes
|
|
|
|
Globale Validierungsregeln stehen an beliebiger Stelle im Formular und beziehen sich auf die durch das Attribut @xpath
ausgewählten XML-Knoten. Beispiel:
|
|
validiert die Syntax aller auftretenden mods:identifier[@type='issn']
Elemente. Globale Validierungsregeln erleichtern die Wiederverwendung und können bevorzugt für
Syntaxprüfungen verwendet werden.
Ist das Attribut @required="true"
gesetzt, ist das gewählte Element ein Pflichfeld, d.h. es muss mindestens ein nicht leerer Wert (bei wiederholten Elementen) auftreten.
Das Attribut @matches
gibt einen regulären Ausdruck in der Syntax von java.util.regex.Pattern
an. Der Text des XML-Elementes oder Attributes muss dem Muster entsprechen.
Beispiel:
|
|
Das Attribut @matches-not
gibt einen regulären Ausdruck in der Syntax von java.util.regex.Pattern
an. Der Text des XML-Elementes oder Attributes darf dem Muster nicht entsprechen.
Beispiel:
|
|
Das Attribut @test
gibt einen XPath Test an, gegen den ein XML-Knoten validiert wird. Beispiel:
|
|
prüft, ob /document/validTo
>= /document/validFrom
ist.
|
|
prüft, ob das eingegebene Passwort mit dessen Wiederholung identisch ist.
Die Attribute @maxLength
, @minLenght
, @min
, @max
, @type
, @class
, @method
und @format
validieren auf die gleiche Weise wie im alten Editor Framework (siehe dort).
|
|
stellt sicher, dass es sich beim Erscheinungsjahr um eine ganze Zahl >= 2000 handelt.
|
|
validiert alle Datumsangaben, so dass sie entweder nur das Jahr, Jahr plus Monat oder Jahr, Monat und Tag in MODS W3CDTF Syntax enthalten.
In bestimmten Situationen kann es vorkommen, dass eine Validierungsregel ausgelassen werden soll.
Syntax:
|
|
Das Attribut @relevant-if
gibt in Form eines XPath-Tests an, unter welchen Bedingungen diese Validierungsregel geprüft werden soll. Hat das Attribut keinen Wert, wird
die Validierungsregel immer geprüft.
Beispiel: Die Validierungsregel, die prüft, dass ein übersetzter Titel einen Untertitel haben muss, soll nur dann überprüft werden, wenn der übersetzte Titel vorhanden ist und der Originaltitel einen Untertitel hat. Andernfalls soll die Validierung ausgelassen und das zugehörige Feld weder als gültig noch als ungültig markiert werden.
|
|
In bestimmten Situationen kann es vorkommen, dass einzelne der genannten Parameter von <xed:validate/>
veränderbar sein sollen, ohne dass jedes Mal die xed
-Datei verändert werden muss.
Syntax:
|
|
Das Attribut enable-replacements
muss auf true
gesetzt werden. Anschließend kann in allen Attributen mit der Syntax {$MCR.Parameter.XXX}
auf Werte aus der MyCoRe-Konfiguration zugegriffen werden.
Beispiel: Es wird sichergestellt, dass es sich beim Erscheinungsjahr um eine ganze handelt, die mindestens den in MCR.Validation.YearIssued.Min
konfigurierten Wert hat.
|
|
Wenn die Eingabevalidierung fehlschlägt, wird die Variable $xed-validation-failed='true'
gesetzt. Beispiel:
|
|
Das Attribut xed:validate/@display
definiert, an welcher Stelle die Validierungsnachricht ausgegeben werden soll, falls die Validierungsregel nicht erfüllt ist.
@display="here"
Ausgabe der Meldung an genau dieser Stelle, d.h. dort, wo die Validierungsregel im Formular definiert ist.
@display="local"
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. Beispiel:
|
|
@display="global"
Ausgabe der Meldung an globaler Stelle, gesammelt mit anderen Meldungen. Die Meldung wird dort ausgegeben, wo das Element <xed:display-validation-message />
auftritt. Beispiel:
|
|
Es ist auch möglich, die Fehlermeldung an mehreren Stellen auszugeben, indem man mehrere Werte im Attribut @display 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. Beispiel:
|
|
|
|
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. Beispiel:
|
|
umgibt alle ausgegebenen Fehlermeldungen mit einem <span class="help-inline" />
.
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 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:
|
|
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.
Beispiel:
|
|
Wenn das Element <year />
nicht eingegeben wird, bekommt das umgebende <div />
Element die CSS-Klassen @class="form-group 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 CSS-Klassen @class="form-group 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. Beispiel:
|
|
Syntax:
|
|
Cleanup-Rules sind Bereinigunsregeln, die logisch leere XML-Elemente oder -Attribute vor Übergabe an das Zielservlet aus dem resultierenden XML herauslöschen. Das Attribut @xpath gibt in Form eines XPath-Ausdruckes an, auf welche Elemente oder Attribute sich die Regel bezieht. Das Attribut @relevant-if gibt in Form eines XPath-Tests an, unter welchen Bedingungen diese XML-Knoten als relevant erachtet werden.
Es gelten die folgenden Standard-Regeln:
|
|
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):
|
|
entfernt alle <condition />
Elemente, deren @value Attribut leer ist. In einer MyCoRe Suchmaske werden die Suchfelder als <condition />
Elemente dargestellt, mit den Attributen @field für das zu durchsuchende Feld, @operator für den zu verwendenden Suchoperator, und @value für den eingegebenen und zu suchenden Wert, z. B.
|
|
Die Attribute @field und @operator 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):
|
|
Im MODS Datenmodell werden Personennamen z. B. wie folgt dargestellt:
|
|
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 Attribut @type ist nicht relevant, da die Standard-Regel für mods Elemente überschrieben wurde.
Bereinigungsregeln werden rekursiv und iterativ auf das resultierende XML-Dokumente angewandt, bis sich das Dokument nicht mehr ändert, d.h. aufgrund der Regeln keine weiteren Knoten als zu entfernen identifiziert werden.
Syntax:
|
|
Gibt mit dem Attribut @xsl ein Stylesheet an, das zur Nachbearbeitung des resultierenden XML-Dokumentes verwendet werden soll. Über ein solches XSL-Stylesheet kann das XML-Dokument nach Bearbeitung im Formular, aber noch vor Übergabe an das Zielservlet transformiert werden.
Über die XEditor-Syntax können Eingabefelder flexibel auf XML-Elemente und Attribute abgebildet werden. In einigen Fällen kann die XML-Struktur aber zu komplex sein, um sie einfach auf Eingabefelder abzubilden. In solchen Fällen kann man das zu bearbeitende XML-Dokument
<xed:source uri="xslStyle:mods-preprocessor:mcrobject:{$id}" />
<xed:post-processor xsl="mods-postprocessor.xsl" />
Beispiel:
Im MODS Datenmodell wird eine Publikation, die auf einer einzelnen Seite veröffentlicht wird, dargestellt als
|
|
Wenn sich die Publikation über mehrere Seiten erstreckt, wird ein von-bis Bereich angegeben:
|
|
Angenommen, das Eingabeformular soll grundsätzlich nur die Eingabefelder "Seite von" und "Seite bis" anbieten, dann könnte man den Sonderfall einer einzelnen Seite abbilden, indem
Fügt an der verwendeten Stelle Komponenten in das Formular ein, indem sie über eine ID referenziert werden, und/oder von einer externen URI nachgeladen werden.
Syntax:
|
|
Wird das Attribut @uri angegeben, wird ein XML-Element von der angegebenen URI geladen, und der Inhalt (nicht das Wurzelelement selbst) an dieser Stelle eingefügt. @uri kann jede URI sein, die der MyCoRe URI Resolver unterstützt (z. B. classification:, resource:, webapp:, file:, http:, xslStyle:).
Wird das Attribut @ref angegeben, wird der Inhalt desjenigen XML-Elements eingefügt, dessen ID (@id) dem Wert von @ref entspricht.
Die Attribute @uri und @ref sind kombinierbar. Sie können XPath-Ausdrücke oder Verweise auf Variablen enthalten. D.h. man kann über <xed:include />
Teile des Formulars
dynamisch nachladen, die abhängig vom bearbeiteten XML und/oder von Request Parametern bei Aufruf des Formulars sind.
Beispiel: Nachladen von Klassifikationskategorien als Auswahl in einer Select-Box:
|
|
Die URI "xslStyle:items2options:classification:editor:-1:children:modsgenre" lädt die Klassifikation "modsgenre" und transformiert alle Kategorien in
<option />
Auswahloptionen in der HTML-Syntax.
Beispiel: Nachladen von Teilen eines Formulars abhängig von Request Parametern:
|
|
Wird das Formular z. B. mit [Seite].xed?genre=article aufgerufen, wird an dieser Stelle der Inhalt des Elementes mit @id='article' eingefügt.
Das inkludierte XML sollte von einem Element <xed:template />
umschlossen sein.
Der XEditor ignoriert solche Bereiche, wenn sie nicht durch <xed:include />
referenziert werden.
Beispiel: Suchmaske, Auswahl Erscheinungsjahr
|
|
Hier wird eine Vorlage für die Auswahl des Suchoperators (<, >, = etc.) und die Eingabe der Jahreszahl an zwei Stellen wiederverwendet.
Häufig verändern sich über eine URI inkludierte Vorlagen über die gesamte Laufzeit der Anwendungen nicht. Solche statischen Vorlagen können mit
|
|
markiert werden. Der XEditor wird die externe Ressource (z. B. eine statische XML-Datei aus der Webapplikation) nur einmal einlesen, in einem Cache aufbewahren und wiederverwenden.
Für Ressourcen, die sich über die Laufzeit der Applikation ändern, z. B. Klassifikationen, bei denen nachträglich Kategorien online ergänzt werden, sollte @static nicht gesetzt sein.
Syntax:
|
|
Ermöglicht es, einen Teil des Formulars nur unter einer bestimmten Bedingung auszuführen, die durch einen XPath-Test bestimmt wird. Der XPath-Test kann die XML-Struktur des bearbeiteten Dokumentes, sowie Variablen verwenden, die aus HTTP Request Parametern, Konfigurationsparametern aus mycore.properties oder MCRSession Variablen stammen. Nur wenn die Testbedingung erfüllt ist, wird der durch <xed:if />
umschlossene Formularabschnitt verarbeitet und angezeigt.
Beispiele:
|
|
|
|
Syntax:
|
|
Ermöglicht es, abhängig von ein oder mehreren Bedingungen unterschiedliche Teile oder Varianten eines Formulars auszuführen.
Jedes <xed:when />
Element definiert einen XPath-Test. Der XPath-Test kann die XML-Struktur des bearbeiteten Dokumentes, sowie Variablen verwenden, die aus HTTP Request Parametern, Konfigurationsparametern aus mycore.properties oder MCRSession Variablen stammen. Nur wenn die Testbedingung erfüllt ist, wird der durch <xed:when />
umschlossene Formularabschnitt verarbeitet und angezeigt. Wenn mehrere <xed:when />
Elemente angegeben sind, wird nur das erste Element berücksichtigt, dessen Testbedingung erfüllt ist.
Das Element <xed:otherwise />
ist optional. Es wird nur dann ausgeführt, wenn keine der Testbedingungen der vorangehenden <xed:when />
Elemente erfüllt ist. In diesem Fall wird der duch <xed:otherwise />
umschlossene Formularabschnitt verarbeitet und angezeigt.
Beispiel:
|
|
Über die Funktion xed:call-java()
können statische, externe Java-Methoden aufgerufen werden. Als Parameter können dabei auch Variabeln
aus Request Parametern oder Knoten aus dem gerade bearbeiteten XML-Dokument übergeben werden.
Syntax:
|
|
Ein solcher Java-Aufruf kann z. B. verwendet werden, um Teile eines Formulars abhängig von der Rolle des aktuell angemeldeten Benutzers anzuzeigen oder zu verbergen. Administratoren könnten z. B. andere oder komplexere Such- und Eingabefelder verwenden als andere Benutzer. Beispiel:
|
|
Hier ein Beispiel für einen Aufruf mit Parametern und der dazugehörigen Implementierung in Java. XPath-Ausdrücke geben in der Regel einen Menge von Elementen zurück, auch wenn der konkrete Ausdruck nur ein einzelnes Element selektiert. Der XEditor versucht analog zum Überladen von Methoden die am besten passende Methode zu selektieren.
|
|
|
|
Erwartet die aufgerufene Java-Methode einen Übergabeparameter vom Typ String, muss die xpath-Angabe entsprechend als String string(/mycoreobject/@ID)
übergeben
werden. Nachfolgend ein Beispiel bei dem außerdem ein Property aus der Datei mycore.property
geprüft wird.
|
|
Subselects dienen der externen Auswahl ein oder mehrerer Werte, z. B. Suche einer Person im Personalverzeichnis der Einrichtung, und Übername von Name und Personalnummer in das Autorenfeld einer Publikation.
Subselects werden als spezielle Submit-Buttons im Formular definiert. Bei Klick auf den Button werden alle aktuellen Formularwerte serverseitig zwischengespeichert. Dann wird zu einer beliebigen externen URL umgeleitet. Diese URL kann durch ein eigenes Servlet implementiert sein, das die Auswahl oder Eingabe von Werten geeignet steuert. Die resultierenden Werte werden nach Abschluss der Auswahl als Request an das XEditor-Servlet zurückübermittelt. Dieses baut die Werte in das bearbeitete XML-Dokument ein und stellt das Formular erneut dar.
Syntax:
|
|
Das Attribut @xed:href gibt die URL an, die aufgerufen werden soll. Diese kann auch XPath-Ausdrücke enthalten, die auf das bearbeitete XML-Dokument zugreifen, oder Variablen referenzieren, die aus Aufruf- oder Konfigurationsparametern stammen. Beispiel:
|
|
Das Beispiel veranschaulicht die externe Auswahl einer Person zur Übernahme in ein mods:name
Element. Das <xed:output />
Element gibt, sofern bereits vorhanden oder
schon zuvor ausgewählt, Vor- und Nachname der Person im Formular aus.
Bei Klick auf den Button wird das Formular abgeschickt, die Werte zwischengespeichert und die URL ../ubo/lsfSearch.html aufgerufen.
Dabei wird auch ein Request Parameter übermittelt, der den aktuell im XML gesetzten Nachnamen überträgt: ?lastName={mods:namePart[@type='family']}
Die externe Seite könnte den übermittelten Namen suchen und/oder ein Suchfeld bereitstellen. Neben dem angegebenen Parameter lastName bekommt die Seite einen weiteren Parameter _xed_subselect_session übermittelt, der als Rückreferenz dient und die Session ID des Formulars enthält, z. B.
|
|
Nach erfolgter Auswahl muss die externe Seite diesen Parameter zusammen mit den gewünschten Werten als Request an das XEditorServlet rückübermitteln. Das passende xed wird dann aus der Session ausgelesen, dahin darf nicht verlinkt werden! Der Aufruf kann beispielsweise wie folgt aussehen:
|
|
Zur besseren Lesbarkeit sind die Parameter in obiger URL hier nicht URL-encodiert dargestellt. Eine reale Anwendung müsste sowohl Namen als auch die Werte der Parameter URL encoded übermitteln.
Alle Parameter außer _xed_submit_return
und _xed_session
(mit dem Wert von _xed_subselect_session
) werden als relative XPath-Ausdrücke interpretiert.
Im Beispiel sind diese relativ zu der Stelle im Formular, an der der Subselect Button auftritt, und zu dem dort via <xed:bind />
selektierten XML-Element.
In diesem Fall ist das ein mods:name[@type='personal'] Element, in dem Werte eingefügt werden. Die Parameternamen verhalten sich damit so, als ob sie
XPath-Ausdrücke in einem <xed:bind />
Element unterhalb von <mods:name /></xed:bind>
wären.
Das XEditor-Servlet baut die übermittelten Werte in das bearbeitete XML-Dokument ein
|
|
und stellt das Formular per Redirect im Anschluss erneut dar. Das <xed:output />
Element würde im Beispiel dann an dieser Stelle neben dem Subselect-Button den
Wert "Doe, John" ausgeben.