grefe´s webnotes

Skip to: [content] [navigation]

Cocoon-Servlet:

Ein Mann, der recht zu wirken denkt, muß auf das beste Werkzeug halten. (Goethe)

Diese Seite dient noch als Ideensammlung und es bedarf noch einiger Wochen bis zur "Fertigstellung"

Wozu?

Bei der Entwicklung einer Website ergeben sich häufig die gleichen Probleme. Ein starres Layout läßt sich nur mit einem großen Aufwand ändern. Und die Pflege des Inhalts ist nicht weniger aufwändig. Ursächlich ist meist eine "unsaubere" Trennung von Kompetenzen und Aufgaben. Selbst JSP ermöglicht/erfordert eine Einbettung von Logik im Layout.
Durch den Gebrauch von XML/XSLT ermöglicht Cocoon eine strikte Trennung von Logik, Inhalt und Layout. Das Webpublishing Framework Cocoon basiert auf verschiedenen Komponenten, die den Aufbau einer Website im "Lego"-Stil ermöglicht. Offene Schnittstellen erlauben die Nutzung eigenentwickelter Komponenten. Häufig werden für den Eigengebrauch entwickelte Komponenten dem Cocoon-Projekt übergeben. Cocoon ist OpenSource und steht unter der Apache Software License. Ebenso wie der JSP-Referenz-Implementierung Tomcat ist es ein Jakarta Projekt. Aufgrund vorhandener Komponenten wird Cocoon gelegentlich als Content-Management-System oder Portal-Framework bezeichnet. Dazu ist die Funktionalität jedoch zu rudimentär, erlaubt auf der anderen Seite allerdings die flexible Entwicklung von multichannel Websites, daß heißt die Darstellung in verschiedenen Formaten (Crossbrowserfähig, HTLM, WAP,PDF,...) und Sprachen.

XML basiertes Publishing

Beim XML basierten Web-Publishing werden die Daten aus einem XML-Datenstrom erzeugt. Die Daten sind strukturiert (DTD, Schema) und werden mit XML Technologien ( XSL, XSLT, XPATH, XLink, SVG,...) für das jeweilige Ausgabemedium weiterverarbeitet. Der Inhalt ist somit von der eigentlichen Präsentation getrennt.
Soll die Aufbereitung via XSL im Browser geschehen, muss dieser XSL unterstützen. Zum anderen kann die Menge an übertragenen Informationen immense Ausmaße annehmen. Bei der serverseitigen Aufbereitung (Cocoon) wandelt dieser bereits die Daten für die verschiedenen Ausgabemedien (crossbrowserfähig,PDF,..) um und es werden nur die dargestellten Daten übertragen. An den Browser werden keine speziellen Anforderungen gestellt.

Komponenten

Unter Komponenten erwarten Sie vermutlich Komponenten wie Flow-, Authentication-, Portal- Komponenten. Einige von diesen werde ich später - nach Sitemap - auch kurz ansprechen. Sie sind aber eher Frameworks innerhalb des Cocoon Publishing Frameworks. Cocoon Komponenten sind viel elementarer und einzelne Bausteine innerhalb der "Pipeline", die durch die Sitemap definiert wird.

Sitemap

Die Sitemap ist die zentrale XML-Konfigurationsdatei und enthält "gebrauchsfertige" Komponenten, die aneinandergereiht eine Pipeline (~Job/Funktion) ergeben und die sukzessive abgearbeitet. wird. Wobei jede Pipeline genau einen Generator, optional einen oder mehrere Transformer und genau einen Serializer enthält. Der Generator erzeugt mit SAX den XML-Datenstrom, der Transformer (z.B. XSLT-Transformer) bereitet diesen auf und übergibt ihm dem Serializer, der ihn für das entsprechende Ausgabemedium anpasst.

<map:sitemap>
 <map:components>
   <map:generators/>
   <map:transformers/>
   <map:serializers/>
   <map:readers/>
   <map:selectors/>
   <map:matchers/>
   <map:actions/>
   <map:pipes/>
 </map:components>
 <map:pipelines>
   <map:pipeline/>
   <...>
   <map:pipeline/>
 </map:pipelines>
<map:sitmap>
Die einzelnen Komponenten werden im folgenden noch genauer erläutert. Für´s erste Verständnis mag diese Zeichnung hilfreich sein: Zeichnung :---)
             Generator          Transformer     Transformer     Transformer     Serializer
        FILE/HTTP/FTP           XSLT/SQL/LDAP  eigenprogrammiert Filter         HTML/WML/PDF/OFFICE
Oder - bis ich selbst kreativ tätig werde - zwei Zeichnungen aus der Cocoon Dokumentation:
Zu merken bleibt die Sitemap ist eine Sammlung von Pipelines/Funktionen!

Generators

Mit einem Generator beginnt eine Pipline und erzeugt aus einem XML-Datenstrom ein SAX-Event. Der Default-Generator ist der Filegenerator. Er liest XML-Daten aus einer Datei. Schwieriger läßt sich die Funktion des Directory-Generators herleiten. Es liest die XML-Struktur eines Verzeichnisinhalts. Aber es existieren auch noch viele andere wie den ServerPages-, JSP-, Request- und HTML-Generator. Die so entstandenen SAX-Event-Ströme werden auf einen Transformator gepiped.

Liste der Generatoren:
Directory Generator
File Generator (The default generator)
HTML Generator (optional: HTML block)
Image Directory Generator
JSP Generator (optional: JSP block)
LinkStatus Generator
MP3 Directory Generator (no documentation exists)
Notifying Generator
Php Generator (optional: PHP block)
Profile Generator (optional: Profiler block)
Request Generator
Script Generator (optional: BSF block)
Search Generator (optional: Lucene block)
Server Pages Generator
Status Generator
Stream Generator
Velocity Generator (optional: Velocity block)
Web Service Proxy Generator (optional: Proxy block)
XML:DB Collection Generator (optional: XMLDB block)
XML:DB Generator (optional: XMLDB block)
XPath Directory Generator

Transformers

Der Transformer ist eine optionale Komponente innerhalb einer Pipeline, die allerdings häufiger auftreten kann. Je nach Transformer werden die XML-Daten weiterverwandelt. Ein SQL-Transformer vermag weitere Daten aus einer SQL-Datenbank hinzuzufügen, der Default-Transformer XSLT ermöglicht Stylesheet Transformationen innerhalb einer Pipeline und der I18nTransformer dient der Internationalisierung um nur einige zu nennen. Das jeweilige "Ergebnis" wird dann an die nächste Komponente weitergereicht. Der letzte Transformer bereitet meistens mittels eines Stylesheets das Layout auf.

Liste der Transformer:
XSLT Transformer (The default transformer)
Fragment Extractor Transformer
I18n Transformer
Log Transformer
SQL Transformer
Filter Transformer
Read DOM Session Transformer
Write DOM Session Transformer
XInclude Transformer
CInclude Transformer
EncodeURL Transformer
SourceWriting Transformer
Augment Transformer
LDAP Transformer (optional)
Lexical Transformer (optional)
Parser Transformer (optional)
Pattern Transformer (optional)
Session Transformer (optional)

Serializers

Der Serializer übernimmt den Datenstrom vom letzten Transformer innerhalb der Pipeline und schließt die Umwandlung in das Ausgabeformat ab. Der Default-Serializer ist der HTLM-Serializer. Weitere wichtige sind der WML-, der XML- und der fo2pdf- Serializer.

Liste der Serializer:
HTML Serializer (The default serializer)
XHTML Serializer
XML Serializer
Text Serializer
HSSF (XLS) Serializer (optional)
PDF Serializer (optional)
PS Serializer (optional)
PCL Serializer (optional)
WAP/WML Serializer
SVG Serializer
SVG/XML Serializer
SVG/JPEG Serializer
SVG/PNG Serializer
SVG/TIFF Serializer
VRML Serializer
Link Serializer
Zip archive Serializer

Readers

Die Komponente Readers liest NICHT-XML Formate (Images, Filme etc.).

Liste der Reader:
AxisRPC Reader
Database Reader
Directory ZIP Archiver
Image Reader
JSP Reader
Resource Reader (default reader)

Selectors

Selektoren entsprechen in etwa den "if .. then ..else.. if" Ausdrücken in einer Programmiersprache. Und regeln den Aktionsfluß durch eine Pipeline. Der Browser-Selektor beispielsweise erkennt den benutzten Browser und kann so in ein passendes Stylesheet für den Transformator wählen. Natürlich gilt dies auch für WAP oder gar noch nicht entwickelte Endgeräte.

Liste der Selectoren:
BrowserSelector:vergleicht den "test"-Parameter mit dem HTTP User-Agent-Header und erkennt so den Browser am Request
Codeselector:vergleicht dem "test"-Parameter übergebenen Java-Code mit dem Environment
HostSelector:vergleicht den "test"-Parameter gegen Host-Request-Header
ParameterSelector:vergleicht den im "test"-Parameter spezifizierten String mit internen Cocoon Umgebungsparametern
HeaderSelector:wie Parameterselector, jedoch wird gegen den Request-Header abgeglichen
RequestSelector:wie Parameterselector, jedoch wird gegen den Request abgeglichen
SessionSelector:wie Parameterselector, jedoch wird gegen anwenderdefinierte Session Parametr abgeglichen

Matchers

Ein Matcher erkennt einen eingehenden Request und weist diesen der passenden Pipeline zu. Es gibt verschieden Arten von Matchern. Der gebräuchliste ist der Wildcard- Matcher.

Liste der Matcher:
WildCard URI matcher(The default matcher)
Regexp URI matcher
Request parameter matcher
Wildcard request parameter matcher
Wildcard session parameter matcher

Actions

Aktionen gewähren Zugriff auf Datenbanken oder prüfen die Existenz von Daten, validieren Forms oder werten einen Request aus (requestQuery ist beispielsweise der Fragestring in ?param1=test) und ermöglichen der Sitemap mit den erhaltenen Daten zu arbeiten.

Liste der Actions:
Database Actions
Sendmail Action
Session Action

"Komponenten" Frameworks

Liste der Frameworks:
Session Handlingverwaltet Sessions unter anderem durch Cookies ode URL Rewriting
Authentication Frameworkauthentifiziert Benutzer z.B. mithilfe von Datenbanken
Froms Handlingvalidiert benutzerdefinierte Regeln, Abhängikeiten
Portlet Specification JSR-168
Portal Framwork

Internas

XML

XSL

XSLT

SAX

DOM

JAVA (J2EE)

Avalon

Komponenten Framework

Excalibur

Logkit

Eigenbedarf

Privates Portal

Bildarchiv; Reisejournal, ...

EDI-Workbench

Benutzer-Management; Nachrichtenstatus; Jobstatus,...
kleinergrößernormal