Sie können über den Webclient (Browser) Werte in der aktuellen Session speichern. Sie können so über einen Link (URL, HTTP GET) oder das Absenden eines Formulars (HTTP POST) einen Wert an den Server senden, der dann in der Session abgelegt wird. Dazu muss die folgende Syntax für den HTTP Request Parameter verwendet werden:

XSL.<name>.SESSION=<wert>

z.B.

http://.../seite.xml?XSL.mode.SESSION=active

In der MCRSession wird so z.B. der Variablenwert mode=active abgelegt. Sie können dann in Java-Code über

MCRSessionMgr.getCurrentSession().get(“mode“)

darauf zugreifen, oder in einem beliebigen Stylesheet diese Variable verwenden. Dazu muss sie im Kopf des Stylesheets deklariert werden:

<xsl:param name=“mode“ />

Das EventHandler-Modell wird beispielsweise eingesetzt, um Objekte vom Typ MCRObject persistent zu speichern. Das Klassendiagramm (Abbildung 1.6) verdeutlicht die Zusammenhänge.

1. Das MCRObject ruft in MyCoRe-Version 1.2 zuerst eine Persistence-Layer-Implementierung nach alter Konzeption auf. Hier wurde zur Nutzung des EventHandlers eine Dummy-Klasse MCRDummySearchStore geschaffen, welche keine Funktionalität ausführt.
2. Anschließend wird von MCRObject ein neues Ereignis erzeugt, welches in diesem Fall die vordefinierte Pipeline OBJECT_TYPE und das vordefinierte Ereignis CREATE_EVENT nutzt. Es können aber auch beliebige Strings eingetragen werden. Dabei ist aber auf die Konsistenz zu achten.
   MCREvent evt = new MCREvent(MCREvent.OBJECT_TYPE, MCREvent.CREATE_EVENT);
3. Nun wird dem neuen Ereignis das Datum übergeben, welches an die Handler weitergereicht werden soll. Ein Ereignis kann auch mehrere Daten beinhalten.
   evt.put("object",this);

   Abbildung 1.6: Klassendiagramm des EventHandler-Modells

4. Die folgende Zeile ruft abschließend den MCREventManager auf und stößt die Handler für die Pipeline an.
   MCREventManager.instance().handleEvent(evt);

Alle Konfigurationen befinden sich im Verzeichnis der Applikation (z.B. DocPortal) in der Datei mycore.private.properties (bzw. mycore.private.properties.template).

In der Version 1.2 von MyCoRe ist es noch erforderlich, für den jeweiligen SearchStore die dummy-Klasse anzugeben:

MCR.persistence_jdom_class_name=org.mycore.common.events.MCRDummySearchStore

Nun müssen noch die EventHandler für jede Pipeline (in diesem Fall ist es MCRObject = MCREvent.OBJECT_TYPE) in der Reihenfolge ihrer Ausführung angegeben werden. Jeder Handler bekommt dabei eine aufsteigende Nummer.

MCR.EventHandler.MCRObject.1.class=org.mycore.backend.jdom.MCRJDOMEventHandlerIndexMeta

Wollen Sie eigene EventHandler schreiben und diese einbinden, so ist es ratsam diese direkt von MCREventHandler abzuleiten und analog zu den bestehenden Handlern einzubinden. Sie können dafür auch neue Pipelines und Ereignisse definieren. Den MCREventManager können Sie nun an beliebiger Code-Stelle einbauen und ihm ein von Ihnen definiertes Ereignis übergeben. Diese Komponente ist allgemein verwendbar und nicht auf das MyCoRe-Datenmodell festgelegt.

Allgemeines

Klassifikationen sind wie bereits angedeutet Sammlungen fest stehender Begriffe, welche noch ggf. hierarchisch strukturiert sein können. In Bereichen des Bibliothekswesens werden sie auch als Normdateien bezeichnet. Der Vorteil ist, dass bei einer interaktiven Suche immer die richtigen und eindeutigen Begriffe angezeigt und gefunden werden. Für den Import und Export solcher Klassifikationen wurde in MyCoRe eine XML-Darstellung festgelegt, welche intern in SQL-Tabellen abgelegt wird. Als Schnittstelle dient hier ein Interface, welches durch verschiedene Persistence Layer implementiert werden kann. Standard ist dabei die Hibernate-Implementierung.

Elemente einer Klassifikation

Klassifikationen haben immer ein Grundgerüst, welches die ID, das Datenmodellschema und einen oder mehrere Label enthält. Ein Label wiederum enthält Informationen zur Sprache sowie einen Text und ein optionales Beschreibungsfeld. Alle Elemente einer Klassifikation sind in Kategoriefeldern gespeichert. Jede Kategorie hat wiederum eine ID als Attribut. Weiterhin enthält eine Kategorie Labels mit den Attributen Sprache, Text und Beschreibung (optional). Eine weitere Option ist ein Element URL welches eine URL als Referenz für die Kategorie enthält. Die ist z.B. bei Listen von Einrichtungen sehr interessant. Kategorien können ineinander geschachtelt auftreten.

ist in Arbeit

ist in Arbeit

ist in Arbeit

ist in Arbeit

ist in Arbeit

Aufgabe des MyCoRe Query Service ist es, gespeicherte Daten durchsuchbar zu machen. MyCoRe Anwendungen suchen dabei nicht direkt in den Metadaten von Dokumenten bzw. deren XML-Darstellung, oder den Volltexten der zugehörigen Dateien, sondern in daraus abgeleiteten Suchfeldern. Die Definition dieser Suchfelder wird für jede MyCoRe Anwendung in der Konfigurationsdatei searchfields.xml vorgenommen (vgl. docportal/config/searchfields.xml). Das XML Schema dieser Datei ist in der Datei searchfields.xsd definiert.

Mehrere Suchfelder werden zu einem Index logisch zusammengefasst. In DocPortal fasst z.B. der Index metadata alle Felder zusammen, die Dokumenten- und Personen-Metadaten durchsuchbar machen. Der Index content enthält alle Felder, die Dateien (deren Volltexte, Dateinamen, Dateigröße etc.) durchsuchbar machen. In jeder MyCoRe Anwendung ist ein Index oder mehrere solcher Indizes in der Datei searchfields.xml definiert. Jeder Index besitzt eine eindeutige ID und besteht aus einem oder mehreren Suchfeldern, die jeweils einen innerhalb der Datei searchfields.xml eindeutigen Namen besitzen.

... ]]>

Jedem Index muss ein Searcher zugeordnet werden, der die Felder dieses Index mit Hilfe eines zugrundeliegenden Datenbanksystems (z.B. SQL) oder einer Suchmaschine (z.B. Lucene) durchsuchbar macht. Ein Searcher wird durch eine Java-Klasse implementiert und ist somit zur Laufzeit eine Instanz dieser Klasse.

Searcher und Index sind prinzipiell unabhängig, d.h. es ist möglich, je nach Anwendung für den gleichen Index zwischen verschiedenen Searcher-Implementierungen zu wählen, die jeweils Vor- und Nachteile besitzen. Die gleiche Java-Klasse, z.B. die auf Apache Lucene basierende Implementierung eines Searchers, kann auch für mehrere Indizes verwendet werden, so dass zur Laufzeit mehrere Instanzen der Java-Klasse verwendet werden.

Die Zuordnung von Searchern zu Indizes wird in den mycore.properties-Konfigurationsdateien vorgenommen. Jedem Index wird ein Searcher zugeordnet. Jeder Searcher besitzt wiederum eine eindeutige ID. Dazu ein Beispiel:

# Searcher mit ID 'jdom-metadata' sucht im Index 'metadata'
MCR.Searcher.jdom-metadata.Index=metadata
# Searcher mit ID 'lucene-content' sucht im Index 'content'
MCR.Searcher.lucene-content.Index=content
also allgemein
MCR.Searcher.[SearcherID].Index=[IndexID]

Durch die Trennung von Searcher und Index kann man den für einen bestimmten Index verwendeten Searcher durch Änderung nur einer Konfigurationszeile wechseln (z.B. von Lucene auf JDOM). Sie können so in Ihrer Anwendung zu einem späteren Zeitpunkt die Suchimplementierung wechseln, ohne die Daten neu laden zu müssen.

Jeder Searcher wird durch eine bestimmte Java-Klasse implementiert. Derzeit sind zwei Implementierungen der Suche verfügbar.

• org.mycore.backend.lucene.MCRLuceneSearcher
  verwendet die Apache Lucene Suchmaschine. Dies ist die für Produktionssysteme derzeit empfohlene Implementierung, die sich sowohl für die Metadatensuche, als auch für die Suche in Volltexten eignet.
• org.mycore.backend.jdom.MCRJDOMSearcher
  verwendet einen Suchindex im Hauptspeicher, so dass keinerlei Daten auf der Festplatte bzw. einem Datenbanksystem gespeichert werden. Diese Implementierung dient als Referenz zur Entwicklung eigener Suchimplementierungen und hat den Vorteil, dass niemals Daten neu indiziert oder geladen werden müssen, eine Änderung der Suchfeld-Konfiguration ist nach Neustart der Anwendung unmittelbar wirksam. Gut geeignet für die Suche in Metadaten bei der Entwicklung einer Anwendung.

Die gleiche Implementierung (Java-Klasse) kann auch für verschiedene Searcher-Instanzen mit unterschiedlicher Konfiguration verwendet werden. Jeder Searcher kann eine eigene, individuelle Konfiguration haben, deren Parameter abhängig von der Implementierung sind. Im folgenden Beispiel wird der Searcher mit der ID lucene-content durch die Klasse MCRLuceneSearcher implementiert. Diese Searcher-Instanz verwendet das Verzeichnis lucene-index4content/, um die Daten des Suchindex zu speichern:

# Konfiguration des Searchers 'lucene-content'
MCR.Searcher.lucene-content.Class=
org.mycore.backend.lucene.MCRLuceneSearcher
MCR.Searcher.lucene-content.IndexDir=/repository/lucene-index4content/

# Konfiguration des Searchers 'jdom-metadata'
MCR.Searcher.jdom-metadata.Class=
org.mycore.backend.jdom.MCRJDOMSearcher
MCR.Searcher.jdom-metadata.Index=metadata
also allgemein
MCR.Searcher.[SearcherID].Class=[ImplementierendeJavaKlasse]
MCR.Searcher.[SearcherID].[KonfigurationsEigenschaft]=[Wert]

Damit die Metadaten bzw. die Dateien der in einer MyCoRe Anwendung gespeicherten Dokumente durchsuchbar sind, müssen diese Daten auf logische Suchfelder abgebildet werden. Diese Abbildung kann je nach Implementierung an sich auf beliebige Weise erfolgen, in der Regel werden aber aus den XML-Darstellungen der Daten die Inhalte der Suchfelder mittels XPath-Anweisungen abgeleitet. Die hierarchische XML-Struktur wird dabei quasi „verflacht“. Mittels Filter (PDF, HTML,OpenOffice etc.) können die Volltexte aus Textdateien extrahiert und einem logischen Suchfeld zugeordnet werden.

Typischerweise werden nicht alle Inhalte auf Suchfelder abgebildet. Ein Suchfeld kann auch eine Aggregation von Daten mehrerer Metadatenfelder sein. Suchfelder sind grundsätzlich auch wiederholbar, da evtl. die zugrunde liegenden Metadatenfelder oder Inhalte wiederholt auftreten. Auch kann das gleiche Metadatenfeld auf mehrere Suchfelder abgebildet werden. Dazu einige Beispiele:

Suchfelder können nicht nur aus Dokument-Metadaten und Volltexten gebildet werden. Derzeit werden die folgenden Datenquellen unterstützt:

Metadaten der Dokumente (Titel, Autor usw. je nach Datenmodell)

Metadaten der Dateien (Dateiname, Größe, Typ etc.)

Volltext der Dateien:
Dabei wird mittels der in MyCoRe bereitgestellten Filter der Volltext extrahiert und indiziert (z.B. OpenOffice, TXT, HTML, PDF Dateien).

XML-Inhalt der Dateien:
Wenn eine gespeicherte Datei eine XML-Datei ist (z.B. eine Excel-Tabelle, als XML gespeichert, oder eine SCORM-Manifest-Datei eines E-Learning Moduls), können deren XML-Elemente qualifiziert durchsuchbar gemacht werden.

Zusatzdaten der Dateien:
In speziellen Anwendungen können damit z.B. extrahierte ID3-Tags aus MP3-Dateien, EXIF-Daten aus Bildern und ähnliche Quellen durchsucht werden).

Beliebige XML-Quellen:
Eigene Anwendungen können die Inhalte beliebiger XML-Quellen indizieren, ohne dass diese XML-Quellen Teil des MyCoRe Datenmodells sein müssen.

In der Datei searchfields.xml wird für jedes Feld über das Attribut source angegeben, aus welcher Quelle es gebildet wird:

In allen Fällen außer fileTextContent und searcherHitMetadata (also immer, wenn der Feldwert aus einer XML-Quelle abgeleitet wird) wird über die Attribute xpath und value definiert, wie der Feldwert zustande kommt. Beispiele:

]]>

Das Attribut xpath kann Werte enthalten, wie sie in einem xsl:select- oder xsl:match- Attribut erlaubt sind. Die in searchfields.xml definierten Felder sind grundsätzlich wiederholbar, d. h. wenn etwa ein Objekt mehrere Titel enthält, werden auch mehrere Feldwerte erzeugt und einzeln indiziert.

Ein Sonderfall stellt die Quelle objectCategory dar. Sie muss verwendet werden, wenn nach den Kategorien einer Klassifikation gesucht werden soll. In diesem Fall gibt das xpath-Attribut an, welches Element in den Objektmetadaten den Link auf die Klassifikationskategorien enthält. Das value-Attribut gibt an, ob die ID oder die Labels der Klassifikationskategorie indiziert werden sollen. Beispiel:

]]>

Felder mit der Quellangabe searcherHitMetadata werden nicht aus den gespeicherten Daten gebildet, sondern erst bei Zusammenstellen der Trefferliste der Suche von der Suchimplementierung dynamisch ergänzt. Dieser Feldtyp ist für technische Metadaten eines Treffers (score, rank etc.) gedacht. Damit dieses Feld z.B. auch sortierbar ist, muss es in der Datei searchfields.xml definiert sein.

Suchfelder, nach denen man die Trefferliste der Suche sortieren können möchte, müssen explizit über das Attribut sortable='true' gekennzeichnet werden.

Manche Suchfelder sollen bzw. können nur für bestimmte Objekttypen oder Dateitypen gebildet werden. Über das Attribut objects kann definiert werden, dass ein Suchfeld nur für bestimmte Typen von Metadatenobjekten oder für bestimmte Typen von Dateien (z.B nur denen, für die ein Volltextfilter vorliegt) gebildet werden. Beispiel:

]]>

Jedem Suchfeld ist ein definierter Datentyp zugeordnet. Der Datentyp bestimmt die möglichen Operatoren für Suchanfragen und legt implizit fest, wie Inhalte dieses Typs behandelt werden (Normalisierung von Umlauten, Stammwortbildung statt exakter Suche etc.). Für jeden Datentyp gibt es eine festgelegte Menge vordefinierter Standard-Operatoren, die jede Searcher-Implementierung unterstützen muss. Darüber hinaus kann eine Implementierung aber auch eigene Datentypen und eigene Operatoren mit erweiterten Suchmöglichkeiten definieren.

Die Definition der Standard-Datentypen und Operatoren erfolgt in der Datei mycore/config/fieldtypes.xml. Das XML Schema dieser Datei befindet sich in mycore/schema/fieldtypes.xsd. Hier ein Auszug als Beispiel:

... ]]>

In zukünftigen Versionen von MyCoRe wird diese Datei auch proprietäre Datentypen (etwa GIS-Koordinaten) und Operatoren (z.B. proximity-Suche in Lucene) definieren und diese als nur durch bestimmte Implementierungen unterstützte Operatoren kennzeichnen. Diese Funktionalität ist derzeit noch nicht implementiert.

Bei der Konfiguration der Suchfelder ist insbesondere auf die richtige Wahl der Textdatentypen zu achten. Es wird zwischen drei verschiedenen Datentypen für Textfelder unterschieden: identifier, name und text. Die folgenden Standard-Datentypen sind derzeit implementiert:

Es ist Aufgabe der Suchimplementierung, diese Datentypen auf möglichst geeignete Suchstrukturen (Lucene-/SQL-Typen etc) abzubilden und die Standard-Operatoren in der späteren Suche umzusetzen. Zu beachten ist, dass für Datums-, Zeit- und Boolean-Werte das Format für die Indizierung (wie werden die Felder zur Indizierung übergeben) und die spätere Suche (wie wird ein Wert in einer Query formatiert) exakt festgelegt ist (siehe Formate in obiger Tabelle).

Eine Suchanfrage kann als XML-Dokument oder als Textausdruck formuliert werden. Für Programmierer besteht weiterhin die Möglichkeit, eine Suche als zusammengesetztes Java-Objekt zu formulieren.

Eine einfache Suchbedingung enthält das zu durchsuchende Feld, einen Suchoperator und den Vergleichswert, z.B. Suche nach dem Wort „Optik“ im Titel:

MCRFieldDef titleField = MCRFieldDef.getDef("title"); new MCRQueryCondition( titleField, "contains", "Optik" ); ]]>

Die Klassen MCRQueryParser und MCRQueryCondition implementieren die Java-Darstellung einer Query bzw. den Parser, um aus der String- oder XML-Darstellung die Java-Darstellung zu gewinnen und zwischen den Darstellungen zu wechseln.

Einfache Suchbedingungen können über and/or/not-Ausdrücke miteinander verknüpft und so zu komplexeren Suchanfragen zusammengesetzt werden:

]]>

Solche komplexen Suchbedingungen können über die Klassen MCRAndCondition, MCROrCondition und MCRNotCondition aus dem Paket org.mycore.parsers.bool auch als Java-Objekte gebildet werden.

Suchanfragen werden vor der Ausführung normalisiert. Insbesondere werden Datumsangaben in Suchausdrücken vom eingegebenen Format z.B. 22.04.1971 automatisch in das ISO8601-Format transformiert also 1971-04-22.

Suchbedingungen, die den Operator contains verwenden, werden automatisch in einzelne contains/like/phrase/not-Bedingungen zerlegt. Beispiel:

In der Konsequenz bedeutet das, dass man bei der Textsuche in aller Regel den Operator contains verwenden kann. Die Umwandlung in eine like- und/oder contains- und/oder phrase-Suche erfolgt automatisch.

• Worte beginnend mit einem Minuszeichen werden zu einer not-Bedingung.
• Worte, die * oder ? enthalten, werden zu einer like-Bedingung.
• Wortgruppen in einfachen Anführungszeichen werden zu einer phrase-Bedingung.

Eine Suchbedingung kann auch gleichzeitig für mehrere Suchfelder definiert werden. Dazu werden die einzelnen Feldnamen durch Kommata getrennt. Beispiel:

Diese Funktionalität kann z.B. verwendet werden, um in einer Suchmaske über nur ein Eingabefeld parallel in mehreren Suchfeldern suchen zu können.

Das Servlet MCRSearchServlet führt Suchanfragen aus und stellt die resultierenden Trefferlisten dar. Die Suchanfrage wird auf verschiedene Weisen akzeptiert:

• Suche in einem vordefinierten Feld:
  In diesem Fall wird nur ein Parameter übergeben, z.B. search=Optik.
  Es wird in einem vordefiniertem Feld mit vordefiniertem Operator gesucht, entsprechend der Konfiguration in mycore.properties:
  MCR.SearchServlet.DefaultSearchField=allMeta
MCR.SearchServlet.DefaultSearchOperator=contains
  Ein Aufruf mit search=Optik sucht dann nach allMeta contains Optik.
• Suche mit komplexem Suchausdruck:
  Die Suchanfrage wird dabei im Parameter query übergeben, z.B.
  query=title contains Optik
• Suche über Namens- und Operator-Parametern:
  Es können mehrere Parameter übergeben werden, deren Namen den definierten Suchfeldern entsprechen müssen. Die einzelnen Bedingungen werden mit UND verknüpft. Beispiel:
  title=Optik&author=Kupferschmidt
  entspricht einer Suche nach
  (title contains Optik) and (author contains Kupferschmidt).
  Wenn, wie im obigen Beispiel, kein Suchoperator angegeben ist, wird der in MCR.SearchServlet.DefaultSearchOperator definierte Wert verwendet. Alternativ kann auch ein Operator angegeben werden:
  title=Opti*&title.operator=like
  entspricht einer Suche nach
  title like Opti*
  Wenn mehrere Werte für ein Suchfeld angegeben werden, werden diese mit dem Operator or verknüpft:
  title=Optik&title=Magnetismus
  entspricht einer Suche nach
  (title contains Optik) or (title contains Magnetismus)

Mit den drei zuvor beschriebenen Methoden kann jede Suche als statischer Link in einer Webseite eingebunden werden. Als weitere HTTP-Request-Parameter können die Anzahl Treffer pro Seite (numPerPage) und die maximale Anzahl auszugebender Treffer (maxResults) angegeben werden. Beispiel:

/servlets/MCRSearchServlet?title=Optik&maxResults=100&numPerPage=5

Die Sortierung der Trefferliste kann über einen weiteren Parameter festgelegt werden, durch Anhängen des Suffixes .sortField an den Feldnamen, mit den möglichen Werten ascending und descending:

/servlets/MCRSearchServlet?title=Optik&...&created.sortField=descending

Wenn Sie nach mehr als einem Kriterium sortieren möchten, können Sie die sortField Parameter im Suffix nummerieren, um die Sortierreihenfolge zu bestimmen, z. B.

/servlets/MCRSearchServlet?title=Optik&...&created.sortField.1=descending&author.sortField.2=ascending

• Suchanfrage als XML-Dokument:
  Hier ist dem MCRSearchServlet ein MyCoRe Editor-Formular vorgeschaltet, das eine Suchmaske darstellt. Nach Abschicken der Suchmaskeneingaben durch den Benutzer generiert das Editor Framework daraus ein XML-Dokument, das die Suchanfrage enthält. Die Syntax dieses XML-Dokumentes entspricht der im vorangehenden Kapitel beschriebenen Syntax für Suchanfragen. Das Wurzelelement query enthält drei Attribute:

  mask

  Dateiname der Suchmaske

  maxResults

  maximale Trefferzahl

  numPerPage

  Anzahl Treffer pro Seite

  Das Element conditions enthält die eigentliche Suchbedingung, entweder formuliert als Menge von verschachtelten XML-Elementen (format=xml) oder als textueller Suchausdruck (format=text). Beispiel:

]]>

Der Query Service ist logisch von der Speicherung der Inhalte unabhängig, so dass Persistenz- und Suchimplementierungen sehr flexibel kombinierbar und austauschbar sind. Dies bedeutet jedoch nicht, dass eine bestimmte Implementierung nicht dennoch beide Dienste gemeinsam realisieren kann. In einer reinen Open Source Umgebung kann z.B. zur Speicherung von Metadaten und Dateien ein lokales Dateisystem dienen, zur Suche in Metadaten und Dateien kann Lucene verwendet werden.

Jedem Index (Menge von Suchfeldern) ist ein Searcher zugeordnet, der diese Felder durchsuchbar macht. Es gibt nun drei Fälle, auf welche Weise diese Felder für eine spezielle Implementierung des Searchers durchsuchbar werden:

• Es ist keine separate Indizierung notwendig, weil schon durch die Art und Weise der Speicherung der Daten automatisch eine Durchsuchbarkeit gegeben ist (Ausnahmefall), oder:
• Wenn sich ein MCRObject (Metadaten eines Dokumentes) oder MCRFile (Datei mit Volltext) ändert, wird bei diesem Ereignis über einen speziellen EventHandler, dem Indexer, die Feldwerte aus den Daten extrahiert und in einer eigenen Struktur zwecks Durchsuchbarkeit abgelegt. In der Implementierung gibt es dann zwei Varianten:
  • Der Indexer tut dies selbst, indem er die entsprechenden Event-Methoden überschreibt (Ausnahmefall), oder:
  • Der Indexer wird als Unterklasse von MCRSearcher implementiert und überschreibt die Methoden addToIndex und removeFromIndex (Regelfall). Alle Feldwerte werden dann automatisch durch die Hilfsklasse MCRData2Fields anhand der Konfiguration aus den Daten gebildet.

Aufgabe eines Indexers ist es also, Inhalte auf Suchfelder abzubilden und diese in geeigneten Strukturen in einer Datenbank oder einer Suchmaschine durchsuchbar zu machen. Im Regelfall ist daher nach der Speicherung der Inhalte eine Abbildung von Suchfeldinhalten auf geeignete Backend-Strukturen (SQL-Tabellen, Lucene Index etc). erforderlich. Die Trennung von Such- und Persistenzdiensten und der Aufruf der Indexer erfolgt über den MyCoRe-EventManager. Bei create/update/delete Operationen auf MCRObject (Metadaten) und MCRFile (Dateien) Objekte wird über den Event Manager ein Ereignis ausgelöst, das ein oder mehrere konfigurierte Indexer aufruft. Der Indexer ist dafür verantwortlich, auf die für ihn relevanten Änderungen an Inhalten zu reagieren und ggf. seine Suchfeldeinträge zu aktualisieren.

Jeder Searcher muss als Unterklasse der abstrakten Klasse MCRSearcher implementiert werden. MCRSearcher implementiert bereits das MCREventHandler Interface. Es sind daher drei Fälle realisierbar:

• Searcher ohne Indexer: Es ist nichts weiter zu tun
• Searcher mit Indexer, wobei die Indizierung mit eigenen Mitteln erfolgt:
  Die MCRSearcher-Unterklasse überschreibt dann die MCREventHandlerBase Methoden
• Searcher mit Indexer, wobei die Feldwerte automatisch gebildet werden sollen: Die MCRSearcher-Unterklasse überschreibt die Methoden addToIndex() und removeFromIndex().

Eine Searcher-Implementierung mit Indexer (die also Event Handler ist) kann z.B. wie folgt in den Event-Mechanismus eingebunden werden:

Nun werden bei create/update/>delete Ereignissen auf Metadaten bzw. Dateien die EventHandler-Methoden der implementierenden Klassen aufgerufen. Der typische Ablauf sieht dann in der Implementierung wie in Abbildung 2.1 dargestellt aus.

Abbildung 2.1: Typischer Event-Ablauf bei der Suche

In diesem Abschnitt geht es um die Rückgabe von Suchergebnissen über interne Referenzen. Damit ist gemeint, dass in einem Datensatz vom Typ B ein Verweis in Form des Datentyps MCRMetaLinkID auf den Datensatz vom Typ A vorhanden ist. Wird nun im Datensatz B z.B. über eine Klassifikation gesucht, so sollen in der Trefferliste die ID's des referenzierten Datensätze vom Typ A erscheinen.

Um dies zu realisieren, muss die Klasse org.mycore.services.fieldquery.MCRSearcher in den Source-Zweig der betreffenden Applikation kopiert werden. Dort sind die Methoden handleObjectCreated und handleObjectUpdated wie folgend umzugestalten.

Die Klasse MCRDataExtractorJPEG ist in der Lage, EXIF- und IPTC-Metadaten aus JPEG-Dateien zu extrahieren. Abhängig von der Eingabedatei sehen diese Daten z. B. wie folgt aus:

Um die Daten auch durchsuchbar zu machen, muss die searchfields.xml um entsprechende Felddefinitionen erweitert werden, z. B.

Die Klasse MCRDataExtractorMP3 extrahiert ID3v1, ID3v1.1, Lyrics3v1, Lyrics3v2, ID3v2.2, ID3v2.3 und ID3v2.4 Metadaten aus MP3-Dateien. Abhängig von der Eingabedatei sehen diese Daten z.B. wie folgt aus:

Um die Daten auch durchsuchbar zu machen, muss die searchfields.xml um entsprechende Felddefinitionen erweitert werden, z. B.

Die Klasse MCRDataExtractorPDF extrahiert Seitenzahl, Autor, Titel etc. und das Inhaltsverzeichnis aus PDF-Dokumenten. Abhängig von der Eingabedatei sehen diese Daten z.B. wie folgt aus:

Neben der Indizierung der Metadaten zur Suche wird auch über einen entsprechenden Event-Handler (MCRLinkTableEventHandler) dafür gesorgt, dass Verweise zwischen den einzelnen Metadaten-Objekten gesondert in einer Datenbanktabelle gespeichert werden. Über entsprechende Zugriffe sind so Abfragen von Referenzen und Zählungen möglich. Die Definition des Tabellennamens erfolgt in der Konfigurationsdatei mycore.private.properties

MCR.Persistence.LinkTable.Store.Table=MCRLINKHREF

Die Tabelle enthält die Spalten MCRFROM, MCRTO, MCRTYPE, MCRATTR.

• MCRFROM enthält die Quelladresse (Source) des Link (i.d.R. eine MCRObjectID).
• MCRTO enthält die Zieladresse (Target/Destination) des Link. Dies kann u. a. eine MCRObjectID sein. Links auf Kategorien von Klassifikationen werden in der Form {classid}##{categid} abgespeichert.
• MCRTYPE enthält den Typ des Links. Derzeit sind folgende Typen vorgesehen:
  • parent – Link zu einem Elternobjekt
  • child – Link zu einem Kindobjekt
  • derivate – Link zu einem Derivate
  • classid – Link zu einer Kategorie einer Klassifikation
  • reference – Link zu einem anderen Metadaten-Objekt
• MCRATTR – derzeit nicht belegt

Der Zugriff auf die Link-Tabellen mittels API erfolgt über die Klasse org.mycore.datamodel.metadata.MCRLinkTableManager. Diese organisiert auch den Zugiff auf die Persistenz-Schicht durch Nutzung eines Interface.

Abbildung 2.2: Klassendiagramm für die Link Tables

Für den Zugriff via Web stellt das System ein Servlet bereit. Dieses liefert als Rückgabewert ein mcr.results-XML-Objekt. Abhängig von der Angabe der Parameter from oder to enthält das Ergebnis die ID's der Ziel- oder Quellobjekte. Wird der Parameter type weggelassen, so ist 'reference' der Standardwert.

http://myhost/servlets/MCRLinkServlet?XSL.Style=xml&from=DocPortal_Document_00000001&type=derivate

Alternativ kann der Zugriff über den WebService erfolgen. Dies geschieht entweder über den URIResolver (Siehe Beschreibung des URIResolvers in diesem Handbuch) oder direkt als URL. Die WebService URL lautet dazu beispielsweise:

http://localhost:8481/services/MCRWebService?method=MCRDoRetrieveLinks&to=TestPapyri_schrift_00000001

Das Benutzermanagement ist die Komponente von MyCoRe, in der die Verwaltung derjenigen Personen geregelt wird, welche mit dem System umgehen (zum Beispiel als Autoren Dokumente einstellen). Zu dieser Verwaltung gehört auch die Organisation von Benutzern in Gruppen. Eine weitere Aufgabe dieser Komponente ist das Ermöglichen einer An- und Abmeldeprozedur.

Ein UseCase-Diagramm (siehe Abbildung 2.3) zeigt eine Reihe typischer Geschäftsprozesse des Systems (ohne dabei den Anspruch zu haben, alle Akteure zu benennen oder alle Assoziationen der Akteure mit den Geschäftsprozessen zu definieren).

Offensichtlich dürfen nicht alle Akteure des Systems über die Berechtigungen verfügen, alle Geschäftsprozesse durchführen zu können. Daher musste ein System von Permissions und Regeln implementiert werden: BenutzerInnen haben Privilegien (z.B. die Berechtigung, neue BenutzerInnen zu erstellen). Die Vergabe der Permissions wird durch die Mitgliedschaft der BenutzerInnen in Gruppen geregelt. Darüber hinaus muss das System definierten Regel gehorchen. So genügt z.B. die Permission 'add user to group' allein nicht, um genau das Hinzufügen eines Benutzers zu einer Gruppe definieren zu können. Die Regel ist in diesem Fall, jeder Benutzer mit dieser Permission kann die Zugehörigkeit nur zu Gruppen vergeben, in denen er oder sie selbst Mitglied ist. Auf diese Weise wird verhindert, dass sich ein Benutzer oder eine Benutzerin selbst höhere Privilegien zuweisen kann. Die Privilegien und Regeln der MyCoRe-Benutzerverwaltung werden weiter unten ausgeführt.

Abbildung 2.3: Geschäftsprozesse der Benutzerverwaltung in MyCoRe

Die Attribute von Benutzern/innen des Systems können in drei Bereiche klassifiziert werden, Account-Informationen wie ID, Passwort, Beschreibung usw., Address-Informationen wie Name, Anrede, Fakultätszugehörigkeit usw. sowie Informationen über die Mitgliedschaft in Gruppen. Die aktuell implementierten Benutzerattribute kann man an folgender beispielhafter XML-Darstellung erkennen:
[ToDo]: to be continued ...

Das ACL-System ist nur lose an das Datenmodell von MyCoRe gekoppelt und so sind ACL-Regeln nicht zwangsweise an MCRObjectIDs gebunden, sondern nehmen als ID jeden String entgegen. Diese Flexibilität kann man sich zu Nutze machen, wenn es um die Überprüfung der Zugriffsrechte geht. Bei MyCoRe gibt es drei vordefinierte Methoden, die über Properties ausgewählt werden.

Methode 1: ObjectID

Diese Methode ist der Standardfall von DocPortal. Zu jeder ObjectID wird die ACL-Regel mit gleicher ID genommen. Existiert diese nicht, wird der Zugriff verweigert. Die Pflege der ACL-Regeln, z.B. die Integration von Standardregeln, übernimmt das SimpleWorkFlow-Modul, das im User Guide beschrieben wird. Dabei wird jedem neu angelegten Objekt eine objektspezifische Regel angehängt. Beim Einstellen in den MyCoRe-Server, entfernt ein Eventhandler die dort vorhandene Regeldefinition und legt eine entsprechende Regel für das Dokument an. Methode 1 ähnelt in diesem Zusammenhang der Unix-Rechteverwaltung und dem dort benutzten Befehl umask. Änderungen an den Standardregeln gelten für neu eingestellte Objekte. Folgende Properties sind für Methode 1:

Methode 2: Objekt-Typ

Diese Methode arbeitet wie Methode 1, nutzt jedoch einen anderen Eventhandler, der nicht für jedes Objekt eine Regel anlegt, sondern diese ignoriert. Das bedeutet, dass man für einzelne Objekte explizit eine Regel anlegen muss oder es tritt beim Überprüfen die erweiterte Behandlung in Kraft. Diese sieht ein Zurückfallen auf die Regel des Objekttyps vor und notfalls die Anwendung einer Standardregel. Die Regel für einen Objekttyp lässt sich über die Kommandozeile anlegen.

Heißt der Objekttyp document, so lautet die ID für das ACL-System default_document. Die Standardregel, die notfalls nach der Objekttyp-Regel überprüft wird, lautet default. Beispiele für die oben genannten Regeldateien (grant-*.xml), finden sich in DocPortal unter config/acl. Methode 2 reduziert gegenüber Methode 1 den Verwaltungsaufwand, sowohl auf Administratorseite als auch auf Datenbankseite, wegen der reduzierten Zahl an Regelzuweisungen. So treten Änderungen an den Standardregeln sofort für alle entsprechenden Objekte in Kraft.

Folgende Properties sind für die Methode 2:

Methode 3: Vererbung von Regeln

Diese Methode arbeitet wie Methode 1, nutzt jedoch wieder den Eventhandler von Methode 2. Entsprechend müssen Regeln für MCRObjectIDs selbst angelegt und gepflegt werden. Sollte für eine MCRObjectID keine ACL-Regel hinterlegt sein, so wird Methode 3 rekursiv mit der MCRObjectID des Vaterobjekts angewandt, bis zu einer MCRObjectID eine ACL-Regel existiert. Sollte es keine ACL-Regel geben, wird der Zugriff verweigert. Methode 3 ähnelt also dem Vererbungsmodell von MyCoRe. Folgende Properties sind für die Methode 3:

MyCoRe in der Version 1.2 bietet 2 Möglichkeiten, die Stores für die organisatorischen Daten einzubinden.

Zum einen wird über das Package org.mycore.backend.sql ein direkter Zugriff auf relationale Datenbanken via JDBC realisiert. Der Vorteil davon sind optimale Zugriffszeiten. Nachteilig kann sich auswirken, dass nur einige der am Markt verfügbaren Datenbanken integriert und getestet wurden. Es kann also bei Verwendung anderer Datenbanken ggf. zu Problemen kommen (besonders beim automatischen Anlegen der Tabellen).

Der zweite Weg ist die Nutzung der Hibernate-Integration. Hier übernimmt das freie Paket „Hibernate“ die Anpassung an die jeweils darunter liegende Datenbank. Es wird also der gesamte Zugriff über ein fest definiertes API geregelt. Der Nachteil ist ein leichter Performance-Verlust, da alle Daten durch das API verwaltet werden. Die Klassen zur Arbeit mit Hibernate stehen in org.mycore.backend.hibernate.

Welche der beiden Zugriffsarten nun in Ihrem konkreten Projekt genommen wird hängt von den ganz spezifischen Eigenschaften der Anwendung und deren Umgebung sowie den personellen Ressourcen ab. Das MyCoRe-System wurde mit beiden Varianten getestet.

Das MyCoRe-Paket bietet eine simple Standard-Lösung für die Suche in kleinen Beispielanwendungen, ohne dass zusätzliche externe Produkte verwendet werden müssen. Die XML-Daten werden im JDOM-Tree zum Startzeitpunkt der Applikation direkt aus der XML-SQL-Tabelle gelesen, teilweise hinsichtlich der Umlaute normalisiert und im weiteren Verlauf der Anwendung im Hauptspeicher verwaltet. Create, Update, Delete auf die XML-SQL-Tabellen wird direkt mit dem im Speicher befindlichen Datenbaum synchronisiert.

Die XPath-Suchanfrage wird in ein XSL-Stylesheet umgewandelt, welches gegen die XML-Daten im Hauptspeicher läuft. Als Ergebnis wird die Liste der Treffer-IDs zurückgegeben. Für die Datumssuche wurde eine zusätzliche XSL-Funktion implementiert. Suchdaten im Operator contains werden hinsichtlich der Umlaute normalisiert (z.B. contains("Eindrücke") → contains("eindruecke")).

Tabelle 2.2: Felder mit Umlautnormalisierung im Search-Store

Dieser Abschnitt beschäftigt sich mit der Struktur des Commandline-Tools und dessen Erweiterung mit eigenen Kommandos. Dem Leser sei vorab empfohlen, den entsprechenden Abschnitt im MyCoRe-UserGuide durchzuarbeiten.

Abbildung 2.4: Zusammenhang der Java-Klassen

Das Commandline-Tool ist die Schnittstelle für eine interaktive Arbeit mit dem MyCoRe-System auf Kommandozeilen-Basis. Sie können dieses System ebenfalls dazu verwenden, mittels Skript-Jobs ganze Arbeitsabläufe zu automatisieren. Dies ist besonders bei der Massendatenverarbeitung sehr hilfreich. In DocPortal werden Ihnen schon in den Verzeichnissen unixtools bzw. dostools eine ganze Reihe von hilfreichen Skripts für Unix bzw. MS Windows mitgegeben.

All diese Skripte basieren auf dem Shell-Skript bin/mycore.sh bzw. bin/mycore.cmd, welches im Initialisierungsprozess der Anwendung via ant mit gebaut wird (ant create.unixtools bzw. ant create.dostools). Sollten Sie zu einem späteren Zeitpunkt eventuell einmal *.jar-Dateien in den lib-Verzeichnissen ausgetauscht haben oder sonstige Änderungen hinsichtlich des Java-CLASSPATH durchgeführt haben, so führen Sie für ein Rebuild des MyCoRe-Kommandos ein ant scripts durch.

Die Abbildung 2.4 soll einen Überblick über die Zusammenhänge der einzelnen Java-Klassen im Zusammenhang mit der nutzerseitigen Erweiterung des Commandline-Tools geben.

Es ist relativ einfach, weitere Kommandos hinzuzufügen. In DocPortal sind bereits alle nötigen Muster vorhanden.

1. Im Verzeichnis ~/docportal/sources/org/mycore/frontend/cli finden Sie eine Java-Klasse MCRMyCommand.java. Diese ist ein Muster, kopieren Sie sie in eine Java-Klasse z.B. MCRTestCommand.java. Die Klasse kann im Package org.mycore.frontend.cli liegen, sie können Sie aber auch in den Bereich tun, zu dem es logisch gehört.
2. Ersetzen Sie alle MCRMyCommand-String durch MCRTestCommand.
3. Im Konstruktor werden nun alle neuen Kommandos definiert. Hierzu werden der ArrayList command jeweils zwei weitere Zeilen hinzugefügt. Die erste enthält den Text-String für das Kommando. Stellen, wo Parameter eingefügt werden sollen, sind mit {...} zu markieren, wobei ... eine fortlaufende Nummer beginnend mit 0 ist (siehe Beispielcode). In der zweiten Zeile ist nun der Methodenaufruf anzugeben. Für jeden Parameter ist das Schlüsselwort String anzugeben.
4. Nun muss das eigentliche Kommando als Methode dieser Kommando-Klasse implementiert werden. Orientieren Sie sich dabei am mitgelieferten Beispiel. (Die Methode convertData sollten Sie in Ihrer Klasse löschen. Ebenso die Definition in der commands-ArrayList.)
5. Compilieren Sie nun die neue Klasse mit cd ~/docportal; ant jar
6. Als letztes müssen Sie die Klasse in das System einbinden. Die mit dem MyCoRe-Kern mitgelieferten Kommandos sind bis auf die Basis-Kommandos über die Property-Variable MCR.internal_command_classes in ~/docportal/mycore.properties dem System bekannt gemacht. Für externe Kommandos steht hierfür in der Konfigurationsdatei mycore.properties.application die Variable MCR.external_command_classes zur Verfügung. Hier können Sie eine mit Komma getrennte Liste Ihrer eigenen Kommando-Java-Klassen angeben.
7. Wenn Sie nun mycore.sh bzw. mycore.cmd starten und DEBUG für den Logger eingeschaltet haben, so sehen Sie Ihre neu integrierten Kommandos.

Als übergeordnetes Servlet mit einigen grundlegenden Funktionalitäten dient die Klasse MCRServlet. Die Hauptaufgabe von MCRServlet ist dabei die Herstellung der Verbindung zur Sessionverwaltung (siehe Abschnitt Die Session-Verwaltung). Das Zusammenspiel der relevanten Klassen ist im Klassendiagramm (Abbildung 2.5) verdeutlicht.

Abbildung 2.5: Klassendiagramm Common Servlets

Wie an anderen Stellen im MyCoRe-System auch, kann auf Konfigurationsparameter wie zum Beispiel den Einstellungen für das Logging über das statische Attribut MCRConfiguration zugegriffen werden.

MCRServlet selbst ist direkt von HttpServlet abgeleitet. Sollen andere Servlets im MyCoRe-Softwaresystem die von MCRServlet angebotenen Funktionen automatisch nutzen, so müssen sie von MCRServlet abgeleitet werden. Im Klassendiagramm ist das durch die stellvertretende Klasse MCRAnyOtherServlet angedeutet. Es wird empfohlen, dass die abgeleiteten Servlets die Methoden doGet() und doPost() nicht überschreiben, denn dadurch werden bei einem eingehenden Request auf jeden Fall die Methoden von MCRServlet ausgeführt.

Der Programmablauf innerhalb von MCRServlet ist im folgenden Sequenzdiagramm (siehe Abbildung 2.6) dargestellt. Bei einem eingehenden Request (doGet() oder doPost()) wird zunächst an MVRServlet.doGetPost() delegiert. (Bei dieser Delegation wird ein Parameter mitgeführt, über den feststellbar ist, ob es sich um einen GET- oder POST-Request gehandelt hat.)

Abbildung 2.6: Sequenzdiagramm Common Servlets

Falls nicht schon aus vorhergehenden Anfragen an das MCRServlet bekannt, werden in doGetPost() die Base-URL und die Servlet-URL des Systems bestimmt. Dabei besteht die Servlet-URL aus der Base-URL und dem angehängten String 'servlets/'. Darauf folgend wird die für diese Session zugehörige Instanz von MCRSession bestimmt. Das Verfahren dazu ist im Ablaufdiagramm (Abbildung 2.7) dargestellt.

Die Session kann bereits durch vorhergehende Anfragen existieren. Falls dies der Fall ist, kann das zugehörige Session-Objekt entweder über eine im HttpServletRequest mitgeführte SessionID identifiziert oder direkt der HttpSession entnommen werden. Existiert noch keine Session, so wird ein neues Session-Objekt über den Aufruf von MCRSessionMgr.getCurrentSession() erzeugt. Nachfolgend wird das Session-Objekt an den aktuellen Thread gebunden und zusätzlich in der HttpSession abgelegt.

Im Sequenzdiagramm gehen wir davon aus, dass die Sitzung neu ist und deswegen ein Session-Objekt über MCRSessionMgr.getCurrentSession() erzeugt werden muss. Schließlich wird eine Instanz von MCRServletJob erzeugt. Diese Klasse ist nichts weiter als ein Container für die aktuellen HttpServletRequest und HttpServletResponse Objekte und hat keine weitere Funktionalität (siehe Klassendiagramm, Abbildung 2.5). (Das Speichern des Session-Objekts in der HttpSession ist notwendig, weil in einer typischen Servlet-Engine mit Thread-Pool Umgebung nicht davon ausgegangen werden darf, dass bei aufeinander folgenden Anfragen aus demselben Kontext auch derselbe Thread zugewiesen wird.)

Abbildung 2.7: Ablaufdiagramm für MCRServlet.doGetPost()

An dieser Stelle wird der Programmfluss an das abgeleitete Servlet (in diesem Beispiel MCRAnyOtherServlet) delegiert. Dazu muss das Servlet eine Methode mit der Signatur

public void doGetPost(MCRServletJob job) {}

implementieren. Wie das Sequenzdiagramm beispielhaft zeigt, kann MCRAnyOtherServlet danach gegebenenfalls auf das Session-Objekt und damit auf die Kontextinformationen zugreifen. Der Aufruf an den SessionManager dazu wäre:

MCRSession mcrSession=MCRSessionMgr.getCurrentSession();

Es sei bemerkt, dass dies nicht notwendigerweise genau so durchgeführt werden muss, da wegen der geschilderten Probleme mit threadlocal Variablen in Servlet-Umgebungen das Session-Objekt auch in der HttpSession abgelegt sein muss, könnte man die Kontextinformationen auch aus der übergebenen Instanz von MCRServletJob gewinnen.

Das LoginServlet, implementiert durch die Klasse MCRLoginServlet, dient zum Anmelden von Benutzern und Benutzerinnen über ein Web-Formular. Die Funktionsweise ist wie folgt: Wie in Abschnitt 3.7.2 empfohlen, überschreibt MCRLoginServlet nicht die von MCRServlet geerbten Standard-Methoden doGet() und doPost(). Meldet sich ein Benutzer oder eine Benutzerin über das MCRLoginServlet an, so wird daher zunächst die Funktionalität von MCRServlet ausgenutzt und die in Abschnitt 3.7.2 beschriebene Verbindung zur Sessionverwaltung herstellt. Wie dort ebenfalls beschrieben, wird der Programmfluss an das Login-Servlet über die Methode MCRLoginServlet.doGetPost() delegiert. Der Ablauf in doGetPost() wird im Diagramm auf Abbildung 2.8 dargestellt und ist selbsterklärend.

Abbildung 2.8: Ablaufdiagramm für MCRServlet.doGetPost()

Der resultierende XML Output-Stream muss vom zugehörigen Stylesheet verarbeitet werden und hat die in Abbildung 2.9 gezeigte Syntax.

Abbildung 2.9: XML Output des LoginServlets

Bei einer missglückten Anmeldung wird der Grund dafür in Form eines Attributes gespeichert. Das Stylesheet kann dann die entsprechende Meldung ausgeben. Die Gast-User-ID und das Gast-Passwort werden aus einer Konfigurationsdatei gelesen. Die URL schließlich wird dem Http-Request entnommen und sollte dort von der aufrufenden Seite bzw. vom aufrufenden Servlet gesetzt sein. Ist sie nicht gesetzt, so wird die Base-URL des MyCoRe-Systems verwendet.

Das Zip-Servlet, implementiert durch die Klasse MCRZipServlet, dient dem Ausliefern der Derivate und der Objektmetadaten als gepackte Zip-Datei. Aus der Konfigurationsdatei mycore.properties.zipper holt sich das Servlet über die Variable MCR.zip.metadata.transformer den Namen des Stylesheets, welches die Metadatentransformation in das gewünschte Auslieferungsformat vornimmt. In DocPortal verwenden wir hierfür Qualified Dublin Core.

Aufrufmöglichkeiten des Servlets:

MCRID ist die ID eines Objekts vom Typ <mycoreobject> oder <mycorederivate>. Im Fall von <mycoreobject> werden die Dateien aller dem Objekt zugeordneten Derivate und ein XML-File mit den Metadaten des Objekts zusammengepackt. Im Fall von <mycorederivate> werden alle Dateien des angegebenen Derivates zusammengepackt. Die Option MCRID/foldername ist nur zulässig, wenn MCRID ein Objekt vom Typ <mycorederivate> bezeichnet. Dann wird nur der mit foldername angegebene Ordner des betreffenden Derivats gezippt.

Wer geschützte Inhalte anbietet, sollte das Zip-Servlet erst dann in seine Anwendung integrieren, wenn die Zugriffskontrolle in MyCoRe gewährleistet werden kann. Dies ist momentan (04.2005) noch nicht der Fall, das Zip-Servlet lässt sich mit jeder MCRID aufrufen.

Die Klasse org.mycore.common.xml.MCRURIResolver implementiert einen Resolver, mit dem an verschiedenen Stellen im MyCoRe-System XML-Daten über URI's gelesen werden können. Der Resolver wird zur Zeit an folgenden Stellen eingesetzt:

• Bei der Verarbeitung von Stylesheets im LayoutServlet, wenn XML-Daten über die XSL-Funktion document() in ein Stylesheet nachgeladen werden oder wenn ein untergeordnetes Stylesheet mittels xsl:include nachgeladen wird.
• Beim Import von Editor-Definitionsteilen mittels des include-Elementes des Editor-Frameworks.

Der Resolver unterstützt die folgenden Schemata bzw. Protokolle:

file://[Pfad]

liest eine statische XML-Datei vom Dateisystem des Servers

Beispiel:

webapp:[Pfad]

liest eine statische XML-Datei vom Dateisystem der Web-Applikation. Im Gegensatz zur file()-Methode kann der Pfad der zu lesenden Datei relativ zum Wurzelverzeichnis der Web-Applikation angegeben werden. Der Zugriff erfolgt direkt, d.h. ohne HTTP Request oder Anwendung eines Stylesheets.

Beispiel:
webapp:config/labels.xml

http://[URL]
https://[URL]

liest eine XML-Datei von einem lokalen oder entfernten Webserver

request:[Path]

liest eine XML-Datei durch einen HTTP Request an ein Servlet oder Stylesheet innerhalb der aktuellen MyCoRe-Anwendung. Im Gegensatz zur http/https Methode ist der Pfad relativ zur Basis-URL der Web-Applikation anzugeben, die MCRSessionID wird automatisch als HTTP GET Parameter ergänzt.

Beispiel:
request:servlets/MCRLinkServlet?
XSL.Style=xml&form=&to=DocPortal_document_00000001&type=derivate

resource:[Path]

liest eine XML-Datei aus dem CLASSPATH der Web-Applikation, d.h. die Datei wird zunächst im Verzeichnis WEB-INF/classes/ und als nächstes in einer der jar-Dateien im Verzeichnis WEB-INF/lib/ der Web-Applikation gesucht. Diese Methode bietet sich an, um statische XML-Dateien zu lesen, die in einer jar-Datei abgelegt sind.

Beispiel:
resource:ContentStoreSelectionRules.xml

session:[Key]

liest ein XML-Element, das als JDOM-Element in der aktuellen MCRSession abgelegt ist. Mittels der put() Methode der Klasse MCRSession kann analog zu einer Java-Hashtable unter einem Schlüssel ein Objekt abgelegt werden. Ein Servlet kann so z.B. ein JDOM-Element in der MCRSession ablegen, den Schlüssel einem Stylesheet über einen XSL-Parameter mitteilen. Der MyCoRe Editor kann dieses JDOM-Element dann mittels der get() Methode aus der Session lesen.

Beispiel:
session:mylist
liest das JDOM XML-Element, das als Ergebnis von
MCRSessionMgr.getCurrentSession().get("mylist");
zurückgegeben wird.

mcrobject:[MCRObjectID]

liest die XML-Darstellung der Metadaten eines MCRObject aus.

Beispiel:
mcrobject:DocPortal_document_07910401

classification:[Classification Query]

gibt eine Klassifikation in unterschiedlichen Formaten aus, wobei „Classification Query“ folgendes Format hat:

{editor['['formatAlias']']|metadata}:{Levels}[:noEmptyLeaves]:{parents|children}:{ClassID}[:CategID]

Die einzelnen Parameter sind durch Doppelpunkte getrennt.

1. Rückgabetyp ist wahlweise im MyCoRe metadata Format oder für eine Editor-Selectbox (editor). Letztere kann für den Label-Text noch unterschiedliche Formatanweisungen enthalten, die mit formatAlias referenziert werden.
   Das Property MCR.UriResolver.classification.format.{formatAlias} enthält dann die Formatieranweisung. Diese besteht aus beliebigem Text kombiniert mit Platzhaltern:
   1. {id} steht für die Kategorie-ID,
   2. {count} steht für die Zahl der zugeordneten MyCoRe-Objekte,
   3. {text} steht für das Attribut text im label-Tag der Klassifikationsdefinition,
   4. {description} steht für das Attribut description im label-Tag der Klassifikationsdefinition.
2. Levels gibt an, wieviel Hierarchiestufen dargestellt werden. Bei Angabe der CategID ist dies die Anzahl der Kindkaterogiehierarchiestufen. Ist Levels „-1“ angegeben, so bedeutet dies „komplette Hierarchie“.
3. noEmptyLeaves ist ein optionaler Parameter. Wenn angegeben, werden leere Kategorien ohne Objekte nicht mit ausgegeben. Diese Funktion ist nur für den Rückgabetyp editor, d.h. sinnvollerweise in Suchmasken, implementiert.
4. parents oder children gibt an, ob bei Angabe einer CategID zusätzlich alle übergeordneten Kategorien mit zurückgegeben werden (parents) oder ob nur die Kinder der Kategorie berücksichtigt werden sollen. Bei Angabe eines positiven Levels und „parents“ werden sowohl die Eltern ausgegeben, wie auch {Levels} Hierarchieebenen der Kinder.
5. ClassID ist die Klassifikations-ID
6. CategID ist Kategorie-ID

Beispiele:

• classification:editor:-1:children:DocPortal_class_00000001
• classification:editor[CountDocument]:2:noEmptyLeaves:children:DocPortal_class_00000002
• classification:metadata:0:parents:DocPortal_class_00000001:Unis.Jena

mcrws:[WebService Request]

fordert über einen WebService-Request XML-Darstellungen entfernter Hosts der Metadaten eines MCRObject, der einer Klassifikation oder eines Links. Für den WebService request sind folgende Formen derzeit möglich:

operation=MCRDoRetrieveObject&ID={MCRObjectID}&host={hostAlias}

operation=MCRDoRetrieveClassification&level={level}&type={type} &classid={classid}&categid={categid}&format={format}&host={hostAlias}

operation=MCRDoRetrieveLinks&from=[{MCRObjectID}]&to=[{MCRObjectID}] &type=[{type}]&host={hostAlias}

Die Werte from und to sind alternativ zu belegen, je nach dem, ob nach der Quelle oder dem Ziel eines Links gefragt wird. (Siehe auch Kapitel zur Link Table)

Beispiel:
mcrws:operation=MCRDoRetrieveObject&ID=DocPortal_document_07910401&host=remote

mcrws:MCRDoRetrieveClassification&level=0&type=parents&classid= DocPortal_class_00000001&categid=Unis.Jena&format=metadata&host=remote

mcrws:MCRDoRetrieveLinks&from=&to=DocPortal_document_00000001& type=derivate&host=remote

access:[ Access Value ]

liest die XML-Darstellung der ACL-Metadaten aus.

action=[all|{permision}&object={MCRObjectID}

Beispiel:
access:action=all&object=DocPortal_document_07910401
access:action=writedb&object=DocPortal_document_07910401

query:[ Query Value ]

startet eine Query und liefert eine Liste der Treffer als mcr:results XML-Darstellung aus.

term={search_term}&sortby={sort_term}&order={order_term}

Beispiel:
query:term=objectType=document&sortby=title

Sie können mit diesem Resolver z.B. aus einem XSL Stylesheet heraus eine Suche in MyCoRe anstoßen und die Suchergebnisse (Element mcr:results) in eine Variable ablegen:

<xsl:variable name="hits"
 xmlns:encoder="xalan://java.net.URLEncoder"
 select="document(concat('query:term=',encoder:encode(
  'objectType = fodokperson')))/mcr:results" />

Die Verwendung von java.net.URLEncoder ist notwendig, damit Leerzeichen, Sonderzeichen etc. in der eigentliche Query codiert werden. Die einzelnen Suchtreffer werden als mcr:hit Elemente geliefert, die im wesentlichen nur die IDs der gefundenen Objekte enthalten. Über diese IDs und z.B. das URIResolver Schema „mcrobject:ID“ können Sie dann die Metadaten der gefundenen Objekte weiterverarbeiten. So geben Sie z.B. eine gefundene ID aus:

<xsl:value-of select="$hits/mcr:hit/@id" />

ifs:[ Derivate ID ]

startet den Abruf eines Derivate-Contents.

{MCRDerivateID}?host={hostAlias}

Beispiel:
ifs:DocPortal_derivate_00000001?host=remote

notnull:[uri]

stellt sicher, dass es bei Aufruf der genannten URI keine NullPointerException gibt. Sollte es bei Verarbeitung der anhängenden URI eine Exception geben, wird diese geloggt. Im Falle einer Exception oder wenn die URI den Wert NULL zurückgibt, liefert dieser Resolver stattdessen eine leere XML-Datei. Dies ist z.B. hilfreich, um in XSL Stylesheets URIs zu verwenden, aber gegen Fehler abzusichern.

Beispiel:notnull:mcrobject:DocPortal_document_07910401

Bei der Verarbeitung von include-Anweisungen in Editor-Definitionen dürfen die folgenden URI-Schemata verwendet werden:

classification file http https request resource session webapp mcrobject notnull

Beim Aufruf der XSL-Funktion document() innerhalb eines Stylesheets können die folgenden URI-Schemata verwendet werden:

classification file http https resource session query webapp mcrobject query access mcrws notnull

xslStyle:[stylesheet]:[URI-Resolver]

wendet das Stylesheet [stylesheet] auf die XML-Datei des URI-Resolvers [URI-Resolver] an und gibt das Ergebnis als XML zurück. Das Stylesheet befindet sich im Classpath der Anwendung. Die Extension .xsl entfällt im Parameter [stylesheet].

Beispiel:
xslStyle:hosts:resource:hosts.xml

Liest zunächst die Datei hosts.xml aus dem Classpath und wendet darauf das Stylesheet hosts.xsl aus dem Classpath an.

Unter Umständen kann es nötig sein den URIResolver für eigene Anwendungen zu erweitern. Dabei ist es nicht möglich vorhandene URI-Schemas zu überschreiben, jedoch neue den bereits vorhandenen hinzuzufügen. Für jedes Schema z.B. file gibt es einen Resolver, der entsprechende URIs auflösen kann. Dieser Resolver muss die Schnittstelle MCRURIResolver.MCRResolver im Paket org.mycore.common.xml implementieren. Für die Zuweisung eines Schemas zur MCRResolver-Implementierung ist der MCRResolverProvider verantwortlich, der diese Schnittstelle aus MCRURIResolver implementiert. Letzterer stellt eine Abbildung von Schema-Strings zu MCRResolver-Instanzen zur Verfügung. Der MCRResolverProvider kann also beliebig viele MCRResolver zu den bereits in MyCoRe integrierten hinzufügen. Eingebunden wird ein zusätzlicher MCRResolverProvider mittels folgendem Property:

MCR.UriResolver.externalResolver.class = <voller Klassenname>

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

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

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

Die folgende Abbildung zeigt die Architektur des MyCoRe Editor Frameworks:

[ToDo]: Bild folgt

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

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

Abbildung 2.10: Einbindung des Editors in eine Webseite

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

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

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

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

Die Grundstruktur

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

Abbildung 2.11: Rahmen der Formular-Definition

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

Abbildung 2.12: Definition eines einfachen Formulares

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

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

Abbildung 2.14: Auslagern von Definitionen aus dem Root-Panel

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

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

Abbildung 2.15: Auslagern von Definitionen aus dem Editor-Formular

Abbildung 2.16: Die imports-Formular-Definition

Abbildung zwischen Eingabefeldern und XML-Strukturen

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

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

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

Abbildung 2.18: Integration von einfachen XML-Tags

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

Abbildung 2.19: Integration von mehrfachen XML-Tags

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

Integration und Aufruf des Editor Framework

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

Abbildung 2.20: Einbindung des Editors in eine Webseite

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

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

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

Abbildung 2.21: Codesequenz zum Aufruf des Editor Framework

Über XSL-Parameter kann beim Aufruf des Editors gesteuert werden, ob bzw. aus welcher Quelle die zu bearbeitenden XML-Daten gelesen werden. Die zu bearbeitenden XML-Daten werden von einer URL gelesen. Falls die URL mit http:// oder https:// beginnt, wird sie als absolute URL direkt verwendet, andernfalls wird die URL als relativ zur WebApplicationBaseURL (context root), dem Startpunkt der WebApplication,interpretiert. Es gibt die folgenden vier Optionen:

1. XSL.editor.source.new=true
   Es wird das Formular mit leeren Datenfeldern gestartet.
2. Statische URL eines XML-Dokumentes (z.B. eines Metadaten-Templates), die in der Editor-Definition als Top-Level-Element angegeben ist (d.h. auf gleicher Ebene wie die target-Deklaration), z.B.
   <source url="templates/document.xml" />
3. URL, die durch ein Servlet oder Stylesheet zur Laufzeit gebildet wird, und die beim Aufruf des Editors über einen XSL Parameter übergeben wird:
   XSL.editor.source.url=templates/document.xml
4. URL, die aus einer Kombination einer statischen URL und eines ID-Tokens gebildet wird, das beim Aufruf des Editors über einen XSL Parameter übergeben wird. Im folgenden Beispiel wird zur Laufzeit das Token XXX durch den Parameterwert 4711 ersetzt:
   XSL.editor.source.id=4711
<source url="servlets/SomeServlet?id=XXX" token="XXX" />

XSL.editor.cancel.url/XSL.editor.cancel.id
Diese Parameter werden im Abschnitt zur Verwendung eines Cancel-Buttons (Abbrechen-Knopf) erläutert, sie steuern die URL, zu der bei Klick auf einen „Abbrechen“ Button zurückgekehrt wird.

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

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

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

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

  Abbildung 2.22: Rahmen der Formular-Definition

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

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

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

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

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

Aufbau einer Zelle

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

Abbildung 2.25: Syntax des cell-Elements

Texteingabefelder

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

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

Abbildung 2.26: Syntax von textfield und textarea

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

Abbildung 2.27: AutoFill-Werte in textfield und textarea

Passwort-Eingabefelder

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

Abbildung 2.28: Syntax des password-Elements

Einfache Checkboxen

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

Abbildung 2.29: Syntax für Checkboxen

Auswahllisten

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

Abbildung 2.30: Syntax einer Auswahlliste

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

Abbildung 2.31: Beispiel für Mehrfachauswahl

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

Radio-Buttons und Checkbox-Listen

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

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

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

Beschriftungen

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

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

Abbildung 2.33: Syntax eines Textfeldes

Internationalisierung

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

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

Abbildung 2.34: Beschriftung mit I18N

Abstandshalter

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

Abbildung 2.35: Syntax eines Abstandhalters

Externes Popup-Fenster

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

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

Im Einzelnen sind die Tags wie folgend definiert:

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

Abbildung 2.36: Syntax eines Popup-Fensters

Buttons

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

Abbildung 2.37: Syntax eines einfachen Buttons

SubmitButton

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

Abbildung 2.38: Syntax des Submit-Buttons

CancelButton

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

Abbildung 2.39: Syntax des Cancel-Buttons

Die Ziel-URL des Buttons kann auf drei verschiedene Weisen gebildet werden. Falls die URL mit „http://“ oder „https://“ beginnt, wird sie als absolute URL direkt verwendet, andernfalls wird die URL als relativ zur WebApplicationBaseURL (context root), dem Startpunkt der WebApplication, interpretiert.

Statische URL, die in der Editor-Definition als Top-Level-Element angegeben ist (d.h. auf gleicher Ebene wie die target-Deklaration), z.B.
<cancel url="pages/goodbye.html" />

1. URL, die durch ein Servlet oder Stylesheet zur Laufzeit gebildet wird, und die beim Aufruf des Editors über einen XSL-Parameter übergeben wird:
   XSL.editor.cancel.url=pages/goodbye.html
2. URL, die aus einer Kombination einer statischen URL und eines ID=Tokens gebildet wird, das beim Aufruf des Editors über einen XSL Parameter übergeben wird. Im folgenden Beispiel wird zur Laufzeit das Token XXX durch den Parameterwert 4711 ersetzt:
   XSL.editor.cancel.id=4711
<cancel url="servlets/SomeServlet?id=XXX" token="XXX" />

Ausgabe von Werten aus dem Quelldokument

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

Beispiel:

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

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

Wiederholbare Elemente mit Repeatern erstellen

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

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

Abbildung 2.40: Beispiel Repeator

Der Framework-interne FileUpload

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

Abbildung 2.41: Syntax des FileUpload

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

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

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

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

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

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

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

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

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

Integration externer Datenquellen

Das Editor-Framework gestattet die Einbindung externer Datenquellen in das Formular. Dies ermöglicht eine flexible Gestaltung von Eingabewerten zur Laufzeit. Dabei werden Teile der Formulardefinition „on the fly“ erzeugt und im Moment der Darstellung erst integriert.

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

Abbildung 2.43: Include Servlet-Request

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

Abbildung 2.44: Java-Code

Einführung

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

Abbildung 2.45: Einfaches Beispiel für Eingabevalidierung

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

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

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

Abbildung 2.46: Fehlgeschlagene Eingabevalidierung

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

Abbildung 2.47: Beispiel für eine Reihenfolge von Regeln

Oder

Abbildung 2.48: Beispiel für Regeln in einer condition

Validierungsregeln für einzelne Felder

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

Validierungsregeln für Feldkombinationen

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

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

Abbildung 2.49: Codebeispiel

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

field1="validFrom"

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

field2="validTo" >

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

operator="<="

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

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

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

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

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

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

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

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

Validierung ganzer Panels oder XML-Bereiche

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

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

"de"> Eingabefehler! ... ruft dann zur Validierung in der Klasse foo.bar.Validator die folgende Methode auf: public static boolean validateInput( Element input ) ]]>