XML Funktionalität

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:

    
    file:///usr/local/tomcat/conf/server.xml

    liest die Datei

    /usr/local/tomcat/conf/server.xml
    
    

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

language:[code]

kann verwendet werden, um zwischen verschiedenen Codes für die gleiche Sprache zu konvertieren. Das zurückgegebene XML enthält die ISO 639-1 und ISO 639-2 Sprachcodes für die angefragte Sprache.

Beispiel:
language:de

<language xmlCode="de" biblCode="ger" termCode="deu" />

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.

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 language

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 language

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>