Identifizierung und Rekonstruktion eines allgemeinen Schemas für Web-Content-Management-Systeme

Die Variable name muss dabei den Klassennamen des hinzuzufügenden Parameters enthalten, die Variable value eine Referenz auf die Instanz des entsprechenden Parameterobjekts. Bei der Publizierung werden dann zunächst die Beschreibungen zur Einbettung der Programmlogik (Logicsheets) angewendet, das heißt die entsprechenden XSLTransformationen werden vorgenommen. Sofern Logik eingebettet wurde, wird das resultierende XML-Dokument mit Programmlogik (jetzt als XSP-Dokument zu bezeichnen) dann in der Datei „PubMan.xsp“ auf dem Datenträger gespeichert, ansonsten in der Datei „PubMan.xml“. Die Dateiendung weist COCOON an, entweder eine Übersetzung des eingebetteten Java-Quelltext vorzunehmen („.xsp“) oder das Dokument als pure XML-Daten normal weiterzuverarbeiten („.xml“). Anschließend werden die Darstellungsbeschreibungen (Stylesheets) auf den Datenträger geschrieben, so dass sie von COCOON verwendet werden können. Da in der aktuellen Version von COCOON 2 der Arbeitsablauf in der Konfigurationsdatei „sitemap.xmap“ definiert werden muss, also nicht dynamisch zur Laufzeit festgelegt werden kann, wurde eine Prozesskette von neun Transformationen festgelegt (Abbildung 38). [...]

Zur Publizierung von Web-Content mit eingebetteter serverseitiger Programmlogik ist ein Seitenprozessor notwendig, der den Quelltext übersetzt oder interpretiert, ausführt und das Ergebnis der Ausführung wieder in den Publizierungsprozess einbindet. Es existieren zahlreiche Ansätze, die solche Prozessoren verwenden (z.B. PHP, ASP, JSP, XSP, u. a.). Für eine Abbildung der konsequenten Trennung von Struktur, Inhalt, Darstellung und Programmlogik ist das Konzept der eXtensible Server Pages (XSP) aufgrund der XMLkonformen Strukturierungskonstrukte besonders gut geeignet. XSP ist zum Zeitpunkt der Entstehung dieses Textes nur in den beiden Open Source-Projekten AxKit und COCOON der Apache Software Foundation ([AXML02]) verfügbar. Da die Beispielimplementierung in Java erfolgen soll, wurde COCOON als zu verwendetes System gewählt (AxKit basiert auf Perl). COCOON wird von den Entwicklern als XML-Publishing-Framework bezeichnet. Oberflächlich betrachtet stellt es eine Möglichkeit zur Publizierung von XML-Dokumenten als Webseiten durch Transformation mit XSLT dar, wobei eingebetteter Java-Quelltext übersetzt, ausgeführt und das Ergebnis in das XML-Dokument wieder eingebunden wird. Obwohl COCOON wesentlich leistungsfähiger ist, als dieser kurzen Charakterisierung zu entnehmen ist, soll an dieser Stelle nicht näher darauf eingegangen werden1. Die genannte Funktionalität reicht aus, um den Einsatzzweck in dieser Arbeit zu erfüllen. COCOON wird dabei ausschließlich für die Abschlusstransformation des strukturierten Inhalts und der Beschreibungen für die Darstellung und die Einbettung der Programmlogik in das gewünschte Ausgabeformat eingesetzt, implementiert also die in Abschnitt 4.2 vorgestellte Schnittstellendefinition für die Publizierungskomponente. Da COCOON in erster Linie eine Servlet-basierte Web-Applikation entsprechend dem Jakarta Tomcat-Standard ist und somit einerseits diverse Konfigurationsdateien benötigt, andererseits aber zur Laufzeit auch noch eigene spezifische Verzeichnisstrukturen anlegt, ist es nicht möglich, es in einer Komponente ohne Nebenwirkungen vollständig zu kapseln. Deshalb ist die hier verwendete Implementierung der Schnittstellendefinition für die Publizierungskomponente als Adapter für COCOON zur Anbindung an das WCMS zu sehen. COCOON benötigt als Servlet einige Parameter zur korrekten Funktionsweise. Es handelt sich dabei um die Objektinstanzen des Servlet-Kontext (ServletContext), der Abfrage (HttpServletRequest) und der Antwort (HttpServletResponse). Da die Schnittstellenmethode publish der Publizierungskomponente keine spezifischen Parameter enthalten kann, wurde eine zusätzlich Methode zur Definition zusätzlicher Parameter definiert: [...]

In Abschnitt 2 wurden die wichtigsten Anforderungen an ein Web-ContentManagementsystem erörtert. Neben der Wahl des Datenhaltungssystems und dem AssetManagement stand dabei die Trennung von Struktur, Inhalt, Darstellung und Programmlogik im Vordergrund. Abschnitt 3 griff diese Schwerpunktthemen erneut auf und vermittelte wichtige Konzepte für eine technische Umsetzung. Insbesondere wurde ein Datenschema vorgestellt, welches als verallgemeinerte und umfassende Basisdatenstruktur für WebContent-Managementsysteme gelten soll. Abschnitt 4 ergänzte die vorhergehenden Überlegungen durch zwei Modelle für Application Programming Interfaces (APIs), welche den administrativen und den lesenden Zugriff in möglichst effizienter Weise ermöglichen sollen. Um diesen Ergebnissen noch mehr Substanz zu verleihen, soll in diesem Abschnitt ein einfaches Beispiel für den Einsatz der Technologien gezeigt werden. Anhand einer einfachen Webseite, welche über den Dateneditor aus Abschnitt 4.1.3 basierend auf dem Administrations-API in die Datenbank bzw. das Datenschema aus Abschnitt 3 eingefügt wurde, soll die Funktionalität des Publizierungs-API demonstriert werden. Aus Gründen des Aufwands wurde keine Webseite bzw. –anwendung aus der „realen Welt“ nachgebildet. Die verwendete Beispielseite erfüllt die Anforderungen aber genauso gut. [...]