Komponenten

Allgemeines

Die Komponente Session Listing ist relativ klein und einfach. Sie stellt lediglich die Möglichkeit bereit, in der interaktiven Sitzung angezeigt zu bekommen, welche Sitzungen für die MyCoRe-Anwendung aktiv sind. Die Anfrage an das Servlet liefert eine XML-Datei zurück, welche über das mitgelieferte Stylesheet angezeigt wird. Ggf. kann dieses Stylesheet durch eine eigene Variante überschrieben werden.

Installation

Der MyCoRe-Kern enthält schon alle Dateien für die Integration der Komponente. Sie muss lediglich noch aufgerufen werden, z. B. in der navigation.xml mit href="/servlets/MCRSessionListingServlet".

Allgemeines

Abbildung 3.1: Grundübersicht des SimpleWorkflow

Für die Erstellung einfacher Anwendungen, welche nur einen relativ primitiven Arbeitsablauf bedingen, war es notwendig ein Werkzeug zur Gestaltung dieser Abläufe anzubieten. So entstand die Idee des SimpleWorkflow. Eigentlich handelt es sich dabei gar nicht um einen Workflow, sondern eher um eine Menge von kleinen Werkzeugen, die über HTTP-Requests zu einem interaktiven Arbeitsablauf zusammengefügt werden können. Der Begriff Workflow soll dabei die Bearbeitungsebene zwischen dem ersten Erstellen eines Objektes, seiner Bearbeitung und der Ablage im Server sowie die dabei vor sich gehenden Arbeitsschritte beschreiben. Physisch handelt es sich um ein Verzeichnis workflow, unter welchem für jeden Objekttyp Unterverzeichnisse angelegt sind, in welchen die Daten zwischengespeichert werden. Konsultieren Sie zum besseren Verständnis auch die Beschreibung im MyCoRe-User Guide.

Der SimpleWorkflow besteht im wesentlichen aus einer Sammlung von Servlets, die über HTTP-Requests angesprochen, verschiedene Bearbeitungsprozesse initiieren. Dabei wird gleichzeitig eine Berechtigungsprüfung für den Zugriff auf einzelne Aktionen durchgeführt. Für das Neuanlegen von Objekten ist die Permission 'create-'ObjectTyp bzw. für mandantenfähige Systeme 'create-'ObjectBase erforderlich. Ist das Objekt schon vorhanden, so entscheiden die ACL's des jeweiligen Objektes selbst über die Möglichkeit der Bearbeitung.

Tabelle 3.1: Permissionliste für den SimpleWorkflow

Bestandteile und Funktionen

Der SimpleWorkflow besteht aus einer Reihe von Servlets. Die folgende Tabelle listet die Servlets auf.

Tabelle 3.2: Übersicht der SimpleWorkflow-Servlets

Die folgende Abbildung soll noch einmal die Beziehungen der einzelnen Teile verdeutlichen. Hier gibt es zwei Komplexe. Der erste arbeitet mit dem Plattenzwischenspeicher und stellt einen simplen Workbasket dar. In diesen Korb können Objekte neu eingestellt, bearbeitet, ergänzt, geprüft oder wieder gelöscht werden. Ist dieser Arbeitsschritt fertig, so kann das Objekt in den Server hoch geladen werden. Hier gibt es wieder die Möglichkeit, so der Nutzer die Berechtigung dazu hat, Objekte zu bearbeiten, zu verändern oder zu löschen. Diese Schritte arbeiten direkt gegen den Server. Ausgangspunkt aller Aktivitäten ist dabei das MCRStartEditorServlet. Hier wird beim Aufruf eine Aktion mitgegeben, welche den weiteren Ablauf bestimmt. Entweder werden jetzt die ToDo's direkt ausgeführt (Löschen) oder es wird z.B. eine Web-Seite mit einer Editor-Maske aufgerufen. Diese wiederum beinhaltet im <target>-Tag das zu nutzende Verarbeitungs-Servlet, welches dann je nach Aufgabe wieder zu einer Web-Seite oder der Workflow-Ansicht verzweigt. Um weitere Aktionen in eigene Anwendungen zu integrieren, muss nur eine Servlet erstellt werden, welches eine Ableitung vom MCRStartEditorServlet ist und die neuen Aktionen implementiert. Mit MyCoRe 2.0 besteht die Möglichkeit, statt der Angabe des Types nun den Base-Bestandteil der MCRObjectID, also projectid_type anzugeben. Damit können Permissions für gleiche Datenmodelltypen bei unterschiedlicher Projekt-ID einzeln abgesichert werden.

Abbildung 3.2: Ablaufschema im SimpleWorkflow

Installation

In DocPortal sind die Funktionen bereits standardmäßig integriert. Bei der Verwendung in anderen Applikationen sind die nacholgenden Schritte auszuführen:

1. die folgende Zeile ist in das XSL-Stylesheet zu kopieren, welches die Auswertung Ihrer XML-Webseiten realisiert (z.B. MyCoReWebPage.xsl).
   <xsl:include href="workflow.xsl" />
2. Weiterhin finden Sie im Kern unter components/swf/xsl das Stylesheet mycoreobject-to-workflow.xsl. Dieses ist eine Transformationsvorlage für die Transformation von den XML-Objekt-Metadaten in eine SimpleWorkflow-interne XML Struktur. Für jeden Ihrer Metadaten-Typen muss eine solche Konverter-Datei mit Namen mycoreobject-<type>-to-workflow.xsl in Ihrer Anwendung vorhanden sein.
3. Als letztes muss der Workflow in eine XML-Webseite integriert und diese entsprechend über Menüpunkte aufgerufen werden. Aufgerufen wird ein Workbasket mit der eingebetteten Zeile
   <workflow base="MCRObjectID.Base" step="editor" /> oder
   <workflow type="MCRObjectID.Type" step="editor" />

Die Integration des SimpleWorkflow in die Präsentationsseiten erfolgt unter Einbeziehung der bereitgestellten Icons und eines dahinter liegenden Links. Dieses kann an beliebiger Stelle in der Präsentation platziert werden. Da die einzelnen Aktionsaufrufe sich in ihren Parametern doch erheblich unterscheiden sollten bei Bedarf die relevanten die entsprechenden Aufrufe im DocPortal-Beispiel zu Rate gezogen werden.

 
    <a href="{$ServletsBaseURL}MCRStartEditorServlet{$HttpSession}?
       tf_mcrid={$mcrid}&amp;       - MCRObjectID
       se_mcrid={$mcrid}&amp;       - MCRObjectID
       re_mcrid={$mcrid}&amp;       - Return MCRObjectID, nur für Derivate-ToDo, optional
       type={$type}&amp;            - MCRObjectID Typ, alte Variante, ggf. optional
       project={$project}&amp;      - MCRObjectID Base, neu, überschreibt type
       step=commit&amp;             - Arbeitsschritt
       todo=seditobj&amp;           - ToDo
       layout={$layout}"            - optional
    >
    <img
       src="{$WebApplicationBaseURL}images/static/workflow_objedit.gif" 
       title="{$OMD.EditorEdit}"/>
    </a>
    
    

Die Einbindung in den Editor erfolgt mit den folgenden Zeilen.

 
    <target type="servlet" name="MCRCheckNewDataServlet" method="post" format="xml" />
    oder
    <target type="servlet" name="MCRCheckEditDataServlet" method="post" format="xml" />
    oder
    <target type="servlet" name="MCRCheckCommitDataServlet" method="post" format="xml" />
    
    

Konfiguration

Die Konfiguration des SimpleWorkflow beschränkt sich auf einige wenige Dinge. Für MyCoRe 2.0 kann alternativ entweder auf den MCRObjectID.Type (alt) oder MCRObjectID.Base (neu) referenziert werden. Für jede Installation können einige Werte different sein, so dass es sich empfiehlt, diese in der mycore.private.properties abzulegen. Ein großer Teil der vom MCRStartEditorServlet veranlassten Aktionen ist so implementiert, dass Sie auf Wunsch eine E-Mail an eine oder mehrere E-Mail-Adressen schicken können. Wenn Sie für den Konfigurationswert, welcher durch das Paar [MCRObjectID.Base|MCRObjectID.Type].[todo] beschrieben wird, nichts angeben, so wird die E-Mail unterdrückt. Alle Angaben in diesem Konfigurationsabschnitt sind selbsterklärend. Anzugeben sind:

• allgemeine Angaben zur Mailverteilung
• die Verzeichnisnamen des Plattenspeichers,
• die Mail-Verteilung

 
    ##################################################################
    #  SimpleWorkflow                                                #
    ##################################################################
        
    # Generic mail configuration for MCRMailer
    # The server for outgoing mails
    MCR.Mail.Server=mail.mycore.de
    # The mail protocol
    MCR.Mail.Protocol=smtp
    # The debug option
    MCR.Mail.Debug=false
    # Encoding for the mail
    MCR.Mail.Encoding=UTF-8
    # Number of send tries to send the mail : 0 – off or n tries
    MCR.Mail.NumTries=1
    # Editor Mail adresses for Messages add1@serv1,add2,@serv2,...
    MCR.Mail.Address=mycore@mail.mycore.de

    # Editor path for directories
    MCR.SWF.Directory.base=%MCR.basedir%/data/workflow
    MCR.SWF.Directory.[MCRObjectID.Base|MCRObjectID.Type]=%MCR.basedir%
        /data/workflow/[MCRObjectID.Base|MCRObjectID.Type]
    ...

    # Editor flags for base/type and todo
    MCR.SWF.Mail.[MCRObjectID.Base|MCRObjectID.Type].
        [todo]=%MCR.Mail.Address%
    ...

    
    

Ergänzung eigener ToDo's

Das MCRStartEditorServlet gestattet eine Erweiterung mit eigenen Funktionen durch einfache Vererbung. Erstellen Sie eine Klasse MCRStartEditorServletMyToDo als Ableitung des MCRStartEditorServlet. Hierin können Sie nun Methoden definieren, welche als ToDo direkt aufgerufen werden können. Entsprechend der Konfiguration können dann auch Mails versendet werden.

 
package org.mycore.frontend.servlets;

import java.io.IOException;

/**
 * The class extends the MCRStartEditorServlet with a new method
 * 
 * @author Jens Kupferschmidt
 */
public class MCRStartEditorServletMyToDo extends MCRStartEditorServlet {

    private static final long serialVersionUID = 1L;

    /**
     * A new method. The access right is writedb.
     * 
     * @param job
     *            the MCRServletJob instance
     * @param cd
     *            the common data part
     */
    public void mytodo(MCRServletJob job, CommonData cd) throws IOException {
        // access right
        if (!MCRAccessManager.checkPermission(cd.mysemcrid, "writedb")) {
            job.getResponse().sendRedirect(job.getResponse().encodeRedirectURL(getBaseURL() + usererrorpage));
            return;
        }
        
        /** ToDo code */
        
        // back to the metadata view
        StringBuffer sb = new StringBuffer();
        sb.append(getBaseURL()).append("receive/").append(cd.mysemcrid);
        job.getResponse().sendRedirect(job.getResponse().encodeRedirectURL(sb.toString()));
    }

}
    
    

Ergänzung eigener Datenmodell-Datentypen

Werden dem bereits vorhandenen allgemeinen Datenmodell neue bzw. ergänzende Typen hinzugefügt, so muss die Prüfung und Vervollständigung des Output Validators für den Editor erweitert werden. Dazu muss in der Klasse MCREditorOutValidator eine Methode für die Klasse eingefügt werden. Die Klasse prüft den Output des Editor Framework und ergänzt fehlende Namespaces (z. B. für xml:lang).

 
    /**
     * @param datasubtag
     */
    boolean checkMCRMetaXYZ(Element datasubtag) {
        return checkMetaObject...(datasubtag, MCRMetaXYZ.class);
    }
    
    

Allgemeines

Für das Webservice-Module wird das Axis-Framework verwendet (http://ws.apache.org/axis/). Über den Webservice können MyCoRe-Objekte geholt und Queries in der neuen Abfragesprache ausgeführt werden. In dem Modul ist auch ein Beispiel eines Clients enthalten, der den installierten Webservice von MyCoRe nutzt.

Installation des WebServices

Hierzu müssen in der mycore.private.properties die Properties für den Axis-Administrator gesetzt werden:

MCR.ws_admin =Kennung des Axis-Administrators

MCR.ws_adminpasswd =und zugehöriges Passwort

Von ant webapps werden Kennung und Passwort in die Datei webapps/WEB-INF/users.lst eingetragen. MyCoRe-Anwendung (z. B. DocPortal) wird wie gewohnt gestartet und durch Eingabe der Url

http://localhost:8080/servlets/AxisServlet

wird geprüft, ob Axis richtig konfiguriert ist. Danach wird das Deployment des Webservice mit ant webservice.deploy durchgeführt.

  
    <target name="webservice.deploy" depends="mvn-init" description="Call the deploy target for the WebServices">
      <modulePreHook target="webservice.deploy"/>
      <mcr:integrate target="webservice.deploy" classpathref="build.classpath"/>
      <moduleHook target="webservice.deploy"/>
    </target>
    

Ein erneuter Aufruf des AxisServlets zeigt den MyCoRe-Webservice mit dem Namen MCRWebService und den Methoden MCRDoRetrieveObject und MCRDoQuery an. Ein Klick auf die WSDL (Web Service Description Language) von MCRWebService zeigt die Parameter und Datentypen der Rückgabewerte an.

Mit ant webservice.undeploy wird das Undeployment des Webservice MCRWebService durchgeführt.

  
    <target name="webservice.undeploy" depends="mvn-init" description="Call the undeploy target for the WebServices">
      <modulePreHook target="webservice.undeploy"/>
      <mcr:integrate target="webservice.undeploy" classpathref="build.classpath"/>
      <moduleHook target="webservice.undeploy"/>
    </target>
    

Nutzung des WebServices

Folgende WebServices sin in MyCoRe implementiert:

  
    http://localhost:8080/services/MCRWebService?
      method=MCRDoRetrieveObject&id=<mcrid>
    

Der Service liefer ein MyCoRe-Object mit der mcrid zurück.

  
    http://localhost:8080/services/MCRWebService?
      method=MCRDoQueryRequest&id=<query>
    

Der Service liefert für die query eine Trefferliste von MyCoRe-ObjectIDs zurück.

  
    http://localhost:8080/services/MCRWebService?
      method=MCRDoRetrieveClassificationRequest
      &level=<level>&type=<type>&classID=<classID>&catID=<catID>&format=<format>
    

Der Service liefert für die eine Klassifikation oder Teile davon zurück. Dabei ist level die Tiefe der gewünschten Kategorie, type die Auswahl für 'chlidren' oder 'parents', classID die ID der Klassifikation, catID die gewünschte Kategorie und format das Ausgabeformat der Form editor['['formatAlias']']|metadata

  
    http://localhost:8080/services/MCRWebService?
      method=MCRDoRetrieveLinksRequest&from=<fromid>&type=<type>]
    http://localhost:8080/services/MCRWebService?
      method=MCRDoRetrieveLinksRequest&to=<toid>&type=<type>
    

Der Service liefert für die Link-Abfrage eine Trefferliste von MyCoRe-ObjectIDs zurück. Dabei bezeichnet fromid eine MyCoRe-ID eines MyCoRo-Objektes, von der ein Link ausgeht und toid eine MyCoRe-ID eines MyCoRo-Objektes, zu der ein Link verweist. Als type sind die Angaben 'reference', 'child', 'parent' und 'derivate' möglich.

Sollten Sie beim Deploy/Undeploy die Meldung „Exception in axis-admin“ oder „axis-admin failed with {http://xml.apache.org/axis/}HTTP (401)Unauthorized“ erhalten, setzen Sie wie am Anfang dieses Abschnittes beschrieben, Kennung und Passwort des Axis-Administrators. Nach einem erneuten ant webapps führen Sie ant webservice.deploy aus. Die Konfigurationsdatei für Axis ist docportal/config/server-config.wsdd.

Client für den Webservice erzeugen

Mit 'ant client.cmd' wird ein Webservice-Client erstellt, der den Webservice MCRWebService nutzt. Hierzu werden WSDL-Informationen vom Server geholt und mittels Axis die Stubs generiert und im Verzeichnis module-webservices/build/src gespeichert. Anschließend werden alle Daten kompiliert und module-webservices/build/bin/wsclient.cmd (Windows) gebaut.

[ToDo]: sh für Linux bauen]

Allgemeines

MyCoRe bietet einen Bildbetrachter, „Image-Viewer“ genannt, für das komfortable Betrachten von Bilddaten an. Dieser eignet sich sehr gut für Bildarchive oder jegliche Content-Repositories in denen Bilddaten verwaltet und angezeigt werden müssen. Der Bildbetrachter basiert (wie MyCoRe) auf Java und XML/XSL. Die Benutzerschnittstelle ist mit Javascript unter Verwendung der Frameworks PanoJS und jQuery realisiert.

Komponente IView2 – API zur Bildbearbeitung

Die IView2-Komponente befindet sich im MyCoRe-Kern und bietet eine API um Bilddaten in MyCoRe abzuspeichern, performant zu laden und gegebenenfalls zu verändern (Skalierung).

Bilder speichern

Für jedes (unterstützte) Bildformat wird beim Einstellen der Datei in MyCoRe ein asynchroner Kachelvorgang gestartet. Dabei wird das Bild in Kacheln à 256x256 Pixel zerlegt und so lange herunterskaliert und erneut gekachelt, bis das Thumbnail (x<=256 und y<=256) erstellt ist. Alle so entstanden Kacheln und Auflösungen werden für die spätere Verwendung gespeichert. Durch diese redundante Speicherung der Bilddaten verdreifacht sich schlimmsten Falls (wenn original JPEG ist) die Datenmenge. Bei unkomprimierten TIFF-Bildern liegt der Overhead bei ca. 10-15 Prozent.

Bilder ausgeben

Bilder können über den Image-Viewer angezeigt werden oder in festen Auflösungsstufen ausgegeben werden. Beim Image-Viewer wird entsprechend der Ausgabegröße wird entschieden, welche Kacheln für die Darstellung verwendet werden.

Schnittstellen

Hier nun eine Übersicht der Möglichkeiten die verschiedenen Kacheln/Darstellungen in die eigene Anwendung einzubinden. Der jeweilige Pfad muss dann im Zuge der Anwendungsentwicklung im gewünschten Stylesheet an der richtigen Stelle platziert werden.

Thumbnails (immer PNG 256x256 mit transparenten Rahmen):

/servlets/MCRThumbnailServlet/{derivateID}/{pfadZumBild}

Thumbnails original (immer JPEG und mit Kantenlänge <=256):

/servlets/MCRTileServlet/{derivateID}/{pfadZumBild}/0/0/0.jpg

Zusammengefügte Bilder in verschieden Auflösungen (immer JPEG):

/servlets/MCRTileCombineServlet/{Auflösung}/{derivateID}/{pfadZumBild}

Auflösung:

• "MIN" - 256 < Kantenlänge <=512
• "MID" - 512 < Kantenlänge <= 1024
• "MAX" - 1024 < Kantenlänge <= 2048

pfadZumBild: relativer Pfad innerhalb des Derivats inklusive der original Endung (z.B.: .tiff)

Einbinden des Bildbetrachters mittels XSLT (kompatibel mit IView1):

    	<xsl:call-template name="derivateView">
          <xsl:with-param name="derivateID" select="{derivateID}" />
        </xsl:call-template>

IView2-Metadaten eines Bildes:

/servlets/MCRTileServlet/{derivateID}/{pfadZumBild}/imageinfo.xml

ergibt:

    	<imageinfo  derivate="{derivateID}"path="/{pfadZumBild}"tiles="{AnzahlAllerKacheln}"
               width="{BreiteInPixeln}"height="{HöheInPixel}"zoomLevel="{maximalerZoomlevel}"//>

Allgemein

Die Firma Zoomify Inc. bietet einen Web-basierten Bildbetrachter an, der auf der Grundlage von gekachelten Bilder basiert und diese "on-demand" nachlädt. Innerhalb des Bildausschnitt kann stufenlos gezoomt werden.

Grundlagen

Um ein Bild über den Zoomify-Viewer anzeigen zu können, muss dieses zunächst aufbereitet werden. In Windows existiert dafür ein Midlet, in Linux kann ein Phyton-Skript genutzt werden. Bei der Datenaufbereitung werden Ausschnittbilder in verschiedenen Auflösungen erzeugt und in Ordnern abgelegt. Für das Zoomify-Servlet in MyCoRe kann der so entstandene Datenbestand in Zip-Archive verpackt werden (jedoch ohne Archiv-Kompression!). Somit wird das Handling extrem vereinfacht. Die Zip-Dateien werden dann als Derivat hochgeladen.

Bilder anzeigen

Für die Bildanzeige wird das Zoomify-Express-Plugin erwartet. Über das MCRStartZoomifyServlet wird die Anzeige der Bilder gesteuert. Zur Zeit findet sich eine adäquate Navigation wie beim IView zur Bildsteuerung im Servlet-Menü. Die Bilder werden über das MCRZipFileNodeServlet automatisch an das Plugin übergeben. Die Anzeigereihenfolge wird über die Mets/Mods-Datei definiert und ist zwingend erforderlich (siehe dazu den Abschnitt über das Mets/Mods-Modul).

Konfiguration

In der mycore.properties-Datei kann über die folgende Variable der Titel des Bildes in Abhängigkeit des zugrunde gelegten Objektes angezeigt werden:

MCR.Component.Zoomify.[type].identifier=[field of datamodel]

Hierbei steht [type] für den Objekttyp und [field of datamodel] für ein verknüpftes Feld aus dem Datenmodell.

Allgemein

Das Mets-Format ist ein Austauschformat in XML für mediale Inhalte. Besonders für die Darstellung von Bildern im DFG-Viewer wird das Format benötigt. Daneben nutzt der Zoomify-Bildbetrachter das Format als Reihenfolgenvorgabe bei Bilderserien.

Mets-Dateien erzeugen

Die Mets-Datei kann vom Derivat-Menü aus erzeugt werden und lässt sich via Java-Applet konfigurieren.

Konfiguration

Die Komponente kann über folgende Properties konfiguriert werden:

CommandLine-Befehle

Allgemeines

Dieses Modul ergänzt die Anwendung um die Funktionalität einer Runtime-Anwenderinformation. Als berechtigter Nutzer oder Administrator können Sie Nachrichten online generieren und versenden.

Konfiguration

In der konkreten Anwendung muss im Verzeichnis modules ein Unterverzeichnis module-broadcasting angelegt werden. Hier muss sich eine build.xml-Datei mit folgenden Targets befinden:

• create.default-rules – Es werden die erforderlichen Rechteeinträge erzeugt.
• webapps – Der Modul wird in die Web-Applikation integriert.

Die Nutzung des Modules in mehreren Anwendungen macht weiterhin die Existenz eines config-Verzeichnisses erforderlich. Darin sind die Dateien grant-broadcastinggroup.xml und mcr-module-broadcasting.xml abzulegen. Die Datei grant-broadcastinggroup.xml beschreibt die Gruppen und Nutzer, welche Nachrichten an die Anwendung versenden dürfen. Im Beispiel sind das alle Mitglieder der Gruppe admingroup.

 
    <?xml version="1.0" encoding="utf-8"?>
    <!-- this rule allways returns true -->
    <condition format="xml"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    
       xsi:noNamespaceSchemaLocation="MCRCondition.xsd">
       <boolean operator="or">
         <condition value="admingroup" operator="=" field="group" />
       </boolean>
    </condition>
    
    

Mit den folgenden MyCoRe-Kommandos werden die Rechte für die Nutzung des Modules eingetragen. Bei Nutzung des ANT-Tagets create.default-rules erfolgt dies automatisch.

    mcrcmd> update permission manage for id module-broadcasting with rulefile grant-broadcastinggroup.xml
    
    mcrcmd> update permission read for id webpage:/servlets/MCRBroadcastingServlet?mode=getReceiverList with rulefile grant-broadcastinggroup.xml
      
    

Die Grundkonfiguration zum Versenden der Nachrichten ist in der Datei mcr-module-broadcasting.xml gespeichert. Sie stellt eine Voreinstellung dar, welche zum Ausführungszeitpunkt interaktiv verändert werden kann.

 
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <mcr-module-broadcasting>
       <!-- on | off -->
       <!-- on = client will autmatically listen for new messages by AJAX -->
       <!-- off client won't listen for new messages -->
       <power>on</power>
   
       <!-- Seconds, in which intervall the client will ask for new messages -->
       <refreshRate>60</refreshRate>
    
       <!-- true | false -->
       <!-- true = User will get the same message again, if a new session is opened, even though the user already received 
            the message. This should be used, if a user login will be used by more than one person -->
       <!-- false = Each user will get a message only on times, indepently on the session. -->
       <sessionSensitive>false</sessionSensitive>
    
       <message.header>Sehr geehrte Mitarbeiter</message.header>
       <message.tail>Ihr Administrator</message.tail>
       <!-- <group/> &| <user> -->
    
       <!-- allowGuestGroup ("true|false")  if set to true all "gast" users are listen on the channel, if "false" only 
            user != "gast" are listen -->
       <receivers allowGuestGroup="false"/>
    
       <!-- <from> & <to> (ISO 8601) are NOT supported yet, -> use @send -->
       <!-- @send = ever | never --><!-- ever = send continuasly -->
       <!-- never = do NOT send -->
       <onAirTime send="ever">
          <from>2006-10-20T10:17:42.920Z</from>
          <to>2006-10-20T10:17:42.920Z</to>
       </onAirTime>
    
    </mcr-module-broadcasting>
    
    

Einbinden in die Anwendung

Der Aufruf des Broadcasting-Modules sollte aus der Navigation der Anwendung heraus erfolgen. Hierfür ist in der navigation.xml folgender Eintrag zu tätigen.

 
    <item 
       href="/servlets/MCRBroadcastingServlet?mode=getReceiverList"
       type="extern"
       target="_self"
       style="normal"
       replaceMenu="false"
       constrainPopUp="false">
         <label xml:lang="de">Nachrichten</label>
         <label xml:lang="en">Broadcasting</label>
    </item>
    
    

Der Include der benötigten XSLT-Stylesheets erfolgt in der Datei generatePage.xsl.

<xsl:include href="mcr-module-broadcasting.xsl" />

Als letztes ist dafür zu sorgen, dass der Listener in alle Webseiten im HEAD-Bereich eingetragen wird. Dazu ist das head-HTML-Tag um diese Zeile zu ergänzen.

<xsl:call-template name="module-broadcasting.getHeader"/>

Informationen zu Benutzung des Modules finden Sie im MyCoRe User Guide.

Allgemein

Das Paket org.mycore.frontend.basket implementiert eine Korbfunktion für MyCoRe Anwendungen. Ein Korb sammelt Verweise auf Objekte, z. B. Dokumente in einem Dokumentenserver oder Bilder, die zu einem Album zusammengefasst werden sollen. Das Paket enthält Klassen für den API-Zugriff auf die Korbfunktionen und ein Servlet, das die Weboberfläche implementiert.

Ein Eintrag im Korb besteht aus einer eindeutigen ID und einer URI. Die ID repräsentiert ein Objekt, das im Korb enthalten sein soll, z. B. die MCRObjectID. Die URI gibt eine Quelle für XML-Daten an, die das Objekt beschreiben. Ein XSL-Stylesheet kann diese URI auflösen, um die im Korb enthaltenen Objekte in der Weboberfläche darzustellen.

MCRBasketEntry entry = new MCRBasketEntry( "DocPortal_document_00774301", "mcrobject:DocPortal_document_00774301" );

Ein Korb wird zunächst in nicht persistenter Form in der Session des Benutzers im Speicher gehalten. Innerhalb einer Anwendung und einer Session könnte es verschiedene Körbe geben, die über ein Typattribut unterschieden werden können, z. B. einen Korb zu Sammeln von Dokumenten, einen anderen Korb für Verweise auf Bilddateien.

Beispiel (API):

       MCRBasketEntry entry = new MCRBasketEntry( "DocPortal_document_00774301", "mcrobject:DocPortal_document_00774301" );
       MCRBasket basket = MCRBasketManager.getOrCreateBasketInSession( "objects" );
       basket.add( entry );
     

Die Klasse Basket implementiert die Schnittstellen List<MCRBasketEntry> und Set<MCRBasketEntry>.
Das MCRBasketServlet implementiert die Weboberfläche der Korbfunktion.
Beispiel (Servlet):

• den Inhalt des Korbs "objects" anzeigen

  BasketServlet?type=objects&action=show

• einen Eintrag dem Korb hinzufügen

  BasketServlet?type=objects&action=add&id=DocPortal_document_00774301&uri=mcrobject:DocPortal_document_00774301

• den Korb leeren

  BasketServlet?type=objects&action=clear

Die HTML-Ausgabe von BasketServlet wird durch das XSL Stylesheet basket-{TYP}.xsl generiert, im obigen Beispiel also basket-objects.xsl.

Reihenfolge der Einträge

Einträge im Korb werden in einer definierten Reihenfolge abgelegt, zunächst in der Reihenfolge des Einfügens in den Korb. Die Position der Einträge ist veränderbar, Einträge können auf und ab geschoben werden:

       basket.up( entry );
       basket.down( entry );
       basket.move( entry, 3 ); // move entry 3 positions down
      

bzw.

        BasketServlet?type=objects&action=up&id=DocPortal_document_00774301
        BasketServlet?type=objects&action=down&id=DocPortal_document_00774301
      

Ein Objekt kann nur einmal in einem Korb vorhanden sein (Set-Eigenschaft). Zum Vergleich von Einträgen wird die ID des Eintrages verwendet.

Entfernen von Objekten

       basket.remove( entry );
       basket.removeEntry( "DocPortal_document_00774301" );
       basket.remove( basket.get( "DocPortal_document_00774301" ) );
     

bzw.

BasketServlet?type=objects&action=remove&id=DocPortal_document_00774301

Kommentare

Einträge im Korb können kommentiert werden.

       entry.setComment( "Kommentar" );
       String comment = entry.getComment();
     

bzw.

BasketServlet?type=objects&action=comment&id=DocPortal_document_0077430

Der obige Aufruf erwartet als weitere Requestparameter die Ausgabe eines Editor-Formulars. In diesem Formular wird der Kommentar bearbeitet. DocPortal enthält hierfür kein Beispiel. Das Formular basket-edit.xml aus miless kann hier als Vorlage dienen.

Körbe speichern und laden

Ein Korb wird zunächst in nicht persistenter Form in der Session der Webanwendung gehalten und dort bearbeitet. Eine Anwendung kann Funktionen zur Speicherung eines Korbes bereitstellen. Beispielsweise könnten in einer Bilddatenbank einzelne Bildobjekte im Korb gesammelt werden und diese Kollektion dann als Album mit weiteren Metadaten persistent gespeichert werden. Die Kollektion kann hierbei beliebige Metadaten enthalten und durch einen MyCoRe Objekttyp implementiert werden. Die Inhalte des Korbs selbst, d.h. die enthaltenen Verweise auf Objekte, werden als XML in einer Derivat-Datei gespeichert.

Korb speichern

       MCRObjectID ownerID = MCRObjectID.getInstance( "ImagePortal_basket_01234567" );
       MCRBasketPersistence.createDerivateWithBasket(basket, ownerID);
     

bzw.

BasketServlet?type=objects&action=create&ownerID=ImagePortal_basket_01234567

erzeugt ein neues Derivat für das Metadaten-Objekt ImagePortal_basket_01234567, legt darin eine Datei basket.xml an und speichert die Verweise des Korbs "objects" darin.

Das Metadaten-Objekt, das die Inhalte des Korbs persistent aufnimmt, kann zuvor auf beliebige andere Weise erstellt werden, etwa über ein Formular, das wie bei jedem MyCoRe Objekt Metadaten zur Beschreibung der Kollektion aufnimmt. Ein Korb merkt sich, in welchem Derivat er gespeichert wurde:

String derivateID = basket.getDerivateID();

Korb erneut speichern

Ein Korb wird in der Session über das BasketServlet oder über die API bearbeitet. Nach Veränderung kann er erneut persistent gespeichert werden:

MCRBasketPersistence.updateBasket(basket);

bzw.

BasketServlet?type=objects&action=update

Korb laden

Ein Korb kann aus der gespeicherten Form zur Anzeige und Bearbeitung in die Session geladen werden:

       MCRBasket basket = MCRBasketPersistence.retrieveBasket(derivateID);
       MCRBasketManager.setBasketInSession(basket);
     

bzw.

BasketServlet?action=retrieve&derivateID=ImagePortal_derivate_12345678

Aufgelöstes XML oder beliebige weitere Metadaten im Korb

In der Regel wird ein Korb nur Referenzen auf andere Objekte enthalten. Für einige Anwendungsfälle kann es jedoch nützlich sein, direkt das aufgelöste XML der Objekt-Metadaten statt nur die URI-Referenz darauf im Korb zu halten. In miless können so beispielsweise Publikationen in einem Korb gesammelt werden, und deren Metadaten direkt im Korb für alle Einträge auf einmal geändert werden. Erst beim Speichern des Korbes werden diese Änderungen dann von miless persistent gemacht.

Um die URI-Referenz für neue Einträge direkt aufzulösen und das XML der enthaltenen Objekte im Korb abzulegen, sind folgende Aufrufe zu nutzen:

       MCRBasketEntry entry = new MCRBasketEntry( "DocPortal_document_00774301", "mcrobject:DocPortal_document_00774301" );
       entry.resolveContent();
       basket.add(entry);
       Element resolvedXML = entry.getContent();
     

bzw.

BasketServlet?type=objects&action=add&id=DocPortal_document_00774301&uri=mcrobject:DocPortal_document_00774301&resolve=true

Es liegt in der Verantwortung der Anwendung, diese Variante zu unterstützen.

XML-Darstellung

Die Klassen MCRBasketXMLBuilder und MCRBasketXMLExporter transformieren ein Korbobjekt und seine Einträge von/nach XML. Bei der Generierung einer XML-Darstellung der Korbinhalte kann gewählt werden, ob die XML-Metadaten der Objekte selbst auch enthalten sein sollen:

       boolean includeBasketEntryContent = false;
       Document xml = new MCRBasketXMLBuilder( includeBasketEntryContent ).buildXML(basket);
     

bzw.

MCRBasket basket = new MCRBasketXMLParser().parse( xml );

Wird der Inhalt eines Korbes in einer Derivat-Datei persistent gespeichert, werden stets nur die enthaltenen Referenzen, nicht aber das aufgelöste XML der Objekt-Metadaten gespeichert.
Beispiel:

 
       <basket type="objects" id="ImagePortal_derivate_12345678">
         <entry id="DocPortal_document_00774301" uri="mcrobject:DocPortal_document_00774301">
           <!-- Hier evtl. weitere aufgelöste XML-Metadaten des Objektes -->
           <comment>Kommentar</comment>
         </entry>
       </basket>