OpenSAGA

Neben vielen punktuellen Erweiterungen und Verbesserungen in OpenSAGA 3.0 sind zwei grundsätzlich neue Bereiche hinzu gekommen. Bisher lag der Fokus von OpenSAGA hauptsächlich in der Umsetzung von Fachanwendungen mit Webtechnologien, besonders im Intranet-Bereich. Die zugrunde liegenden Technologien wurden im Bezug auf ihren Komfort und ihre möglichst inklusive Benutzerfreundlichkeit gewählt.

Zwar lässt sich auf diese Art und Weise grundsätzlich jede Anwendung abbilden, für bestimmte Anwendungsbereiche ist die Umsetzung aber gleichzeitig zu überdimensioniert und für speziellen Anforderungen doch nicht ausreichend. Dies betrifft im Grunde alle Anwendungsbereiche, bei denen der Anwendungscharakter weniger im Vordergrund steht sondern vielmehr die klassische informationelle Internet-Seite als Ganzes oder als Teil eines größeren Portal-Konzepts.

Hier greifen viele der klassischen Überlegungen zum Informations-Design im Internet. Inhalte sind strukturiert und korrelieren mit einer möglichst permanenten URL-Struktur. Es gibt zwar einen klassischen Einstiegspunkt — üblicherweise an der Wurzel-URL, aber auch tiefe Verlinkungen durch Partner, Suchmaschinen und/oder Dritte. URLs und Verlinkungen folgen der Informationsstruktur und nicht Anwendungsregeln.

Um diese Bereiche besser für OpenSAGA zu erschließen, haben wir in OpenSAGA 3.0 zwei neue Konzepte eingeführt.

Content-Mapping

Bisher ergaben sich die URLs einer OpenSAGA-Applikation aus Details der Implementation und Modell-Ids. Mit OpenSAGA 3.0 kann man in großen Teilen frei bestimmen, welche URLs in der Applikation verwendet werden. Hierzu wurde das Konzept der Content-Mappings eingeführt. Im portal.xml einer Extension kann ein <content-mapping-set /> angegeben werden, dass die Content-Mapping-Deklaration enthält.

<content-mapping-set>
    <content-mapping id="cms-test.cm_mapped" location="/mapped/" process-ref="cms-test.p_mapped"/>
</content-mapping-set>

Die Content-Mappings deklarieren für ein bestimmtes URL-Muster, welche Inhalte dort verfügbar sind, ob es Zusatzparameter oder Fachobjekt-Bezüge gibt. Für Prozesse können sowohl die Basis-URL des Prozesses während er läuft bestimmt werden, wie auch Startzustands-URLs. Für Prozesse kann dies erfolgen, muss aber nicht. Wenn kein Content-Mapping für einen Prozess oder einen Startzustand existiert, so wird ein Default verwendet.

Standalone-Views

Zusätzlich zu den Prozessen gibt es nun auch eigenständige Views. Standalone-Views sind den bisherigen OpenSAGA-Views sehr ähnlich, sie sind aber nicht nur ein Teil eines Prozesses und von dessen Logik gesteuert, sondern existieren für sich und werden mit Hilfe von Content-Mappings mit relativen URLs verbunden.

Im einfachsten Fall sieht eine Content-Mapping-Deklaration für einen Standalone-View dann so aus:

<content-mapping id="cms-test.cm_page" location="/page" view-ref="cms-test.sv_page"/>

Das location Attribut definiert die relative URL, das view-ref Attribut referenziert einen standalone view. Die Standalone-View-Modelle können jeweils als Datei unterhalb des Extension-Pfades “models/standalone-views” deklaratiert werden.

Die Content-Mapping-Deklarationen fungieren für Standalone-Views auch als Ziele für logische Links.

Vom Aufbau her sind Standalone-View-Modelle den traditionellen View-Modellen sehr ähnlich, sie haben lediglich ein anderes Wurzel-Element.

<standalone-view id="base.sv_test"
    title="Standalone Test View"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://www.opensaga.org/schema/model/standalone-view-3.0.xsd">    
    <part-set>
        <part id="base.sv_test.main_part">
            <content>
                <heading value="Hello from the View"/>
            </content>
        </part>
    </part-set>
</standalone-view>

Laufzeit-Pflege

Um von diesem generellen Strukturänderungen wirklich zu Content-Management-Funktionalität zu kommen, können bestimmte Teile des Modells nun auch zur Laufzeit per Adminstrations-Oberfläche, wie auch deklarativ oder programmatisch als Fachobjekte bearbeitet werden. Dazu gehören alle Content-Mapping-Definition, wie auch die Portal-Navigation. Präsentierte Inhalte können auch zur Laufzeit gepflegt werden.

Links:

• portal.xml einer Test-Extension als Beispiel
• Test-Extension im opensaga-core