Inhaltsverzeichnis
Einführung
Das Apache XML Projekt
Das Apache Cocoon Projekt
Ein bewährtes Konzept
Architektur
Verwendete Techniken
XML
XSLT
XSL:FO
XSP - eXtensible Server Pages
XSP - eXtensible Server Pages
Wichtige XSP Tags
Kombination XML & XSP
Das Cocoon Servlet
Warum Java?
Das Cache System
Abschließende Informationen
Stärken und Schwächen
Cocoon vs. JSP & ASP
Cocoon vs. PHP
Leitfaden zum Einsatz
Cocoon 2
Literaturverzeichnis
Einführung
Das Apache XML Projekt
Das XML Projekt der Apache Software Foundation verfolgt drei Ziele:
I. Das Projekt soll eine Austauschplattform für alle Arbeiten innerhalb der Foundation sein, die mit XML zu tun haben.
II. Das Projekt soll ein Feed Back aus Sicht der Implementierenden an standardisierende Organisationen wie z.B. dem W3C liefern.
III. Das Projekt soll hochwertige XML Lösungen erstellen, die kommerziellen Produkten in nichts nachstehen.
Das Apache XML Projekt selber besteht aus derzeit 6 Unterprojekten, nämlich
1. dem XML Parser Xerces-J,
2. dem XSLT Stylesheet Processor Xalan,
3. dem XSL Formatter FOP,
4. dem JavaScript/XML Projekt Xang,
5. dem Simple Object Access Protocol SOAP und schließlich
6. Cocoon.
Das Apache Cocoon Projekt
Das Apache Cocoon Projekt kann wie folgt definiert werden:
,,Cocoon ist ein Publishing Framework Servlet, dass mittels seines modularen Reaktorkonzepts ein XML-Quelldokument je nach anfragendem Client in ein beliebiges Zielformat transformiert."
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Cocoon als Publishing Framework Servlet
Abbildung 1 zeigt das Publishing Framework - also einen Publizierungs-Rahmen - den Cocoon zur Verfügung stellt. Die Aufgabe eines solchen Publishing Frameworks ist erst einmal die Kostenreduzierung. Kosten die beispielsweise bei der Veränderung des Layouts eines Internetservices entstehen. Des weiteren soll ein Publishing Framework leicht zu erweitern sein (daher Framework) und den Verwalter von Informationen bei der Veröffentlichung unterstützen.
Die Funktionsweise des Cocoon Servlets kann auch in Abbildung 1 erkannt werden. Ein Mozilla kompatibler Browser stellt über das Internet ein Anfrage an Cocoon für ein XML Dokument auf dem Server. Cocoon erkennt den Browsertyp (anhand des übermittelten user-agent Strings) und weiß, dass dieser Browser HTML bzw. XHTML als Datenformat erwartet. Das Cocoon Servlet - für das in diesem Kontext die Betrachtungsweise als Blackbox ausreicht - nimmt sich daraufhin das verlangte XML Dokument und transformiert dies mit XSL Stylesheets in XHTML.
Diese Funktionalität kann allerdings nur erreicht werden, wenn ein neuer Weg zur Erstellung und Veröffentlichung von Informationen genutzt wird. Bisher (Abbildung 2) waren bei ,,traditionellen" HTML Dokumenten die Schichten Inhalt, Layout und Programmierlogik fest miteinander verschmolzen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: "Traditionelle" HTML Dokumente
Das heißt, dass im besten Fall ein Layouter ein HTML Template, also eine Vorlage erstellt hat, in die er beispielsweise eine Menüstruktur und Grafiken eingesetzt hat. Danach hat ein Programmierer noch ein paar Javascript Funktionen eingefügt und schließlich setzt ein Redakteur den eigentlichen (Text-) Inhalt in das Dokument ein. Das Management (Projektmanagement oder auch Unternehmensführung) kann letztendlich nur eine Datei betrachten und diese beurteilen.
Cocoon geht einen anderen Weg zur Veröffentlichung der Informationen (Abbildung 3). Die drei Schichten Inhalt, Layout und Programmierlogik werden strikt voneinander getrennt und in verschiedenen Dateien bearbeitet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Trennung der drei Schichten mit Cocoon
Bei diesem Ansatz ist also ein Layouter für ein Stylesheet zuständig, ein Programmierer für dynamischen Inhalt in einer eXtensible Server Page (XSP) und ein Redakteur für den Inhalt einer XML Datei. Im Management kommt es ebenfalls zu einer Dreiteilung: Jedes der Teams Inhalt, Layout und Logik hat nun einen gezielten Ansprechpartner im Management.
Die Vorteile liegen hierbei auf der Hand: sowohl Stylesheets als auch Programmierlogik können einfach und effektiv weiterverwendet werden. Der Overhead für das Management wird verringert und die Time-To-Market des Internetservices wird sehr kurz gehalten - und das ist im besonders schnelllebigen Internetmarkt von unschätzbarem Wert, damit das Unternehmen agieren kann und nicht reagieren muss.
Und wenn es doch mal reagieren muss, dann kann es wenigstens schnell reagieren.
Ein bewährtes Konzept
Die Idee der Trennung der drei Schichten Inhalt, Layout und Logik, wie sie Cocoon verfolgt, ist nicht neu - allerdings bewährt. Redaktionssysteme von Tageszeitungen nutzen ein ähnliches Konzept wie Cocoon.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Funktionsweise des ProMan Redaktionssystems
Abbildung 4 zeigt die Funktionsweise eines solchen Redaktionssystems. Das Softwareprodukt ProMan trennt die Bereiche Layout (blau) in Form von Blattplanung bzw. Teilseitenmontage von dem Bereich Inhalt (grün), in dem die Zeitungsartikel von den Redakteuren erstellt werden.
Die Blackbox ,,ProMan" setzt wie Cocoon diese einzelnen Schichten zusammen.
Architektur
Verwendete Techniken
Im folgenden werden die Techniken, die Cocoon nutzt, kurz erklärt.
XML
Eine Syntax für hierarchische Dokumente und zum Strukturieren von Informationen bzw. Dokumenten (im Gegensatz zu HTML, welches für die Präsentation von Informationen konzipiert wurde).
XSLT
Eine Sprache - also eine XML Document Type Definition (DTD) - zum transformieren von XML in ein beliebiges Zielformat.
XSL:FO
XSL:Formating Objects ist ebenfalls eine Sprache, um 2D Layout von Text zu beschreiben. Dabei ist es egal, ob es sich um Printmedien wie z.B. einen Drucker oder Digitalmedien wie PDF's handelt.
XSP - eXtensible Server Pages
XSP ist eine DTD zur Trennung von Inhalt & Logik und hat somit eine ähnliche Aufgabe wie XSL, dass zur Trennung von Inhalt & Layout verwendet wird.Eine XSP Seite ist kompilierter Code und somit entsteht bei der Anfrage eines Clients kein zusätzlicher Aufwand in Form von parsen oder interpretieren.
XSP - eXtensible Server Pages
Eine XSP Seite ist ein XML Dokument mit dynamischem Inhalt. Diese Dynamik wird durch Direktiven erzielt, die in Tags gesetzt werden. Direktiven, also Anweisungen, werden entweder aus vor- oder aus anwenderdefinierten Bibliotheken entnommen.
Wichtige XSP Tags
· <xsp:page>
Das Root Element jeder XSP Seite. Hier wird die verwendete Programmiersprache angegeben, wobei der Standard ,,Java" ist. Dies ist momentan auch die einzige Programmiersprache die in XSP Seiten verwendet werden kann. Für die Zukunft ist allerdings geplant, alle Sprache anzubieten, die auch die Java Virtual Machine unterstützt.Zusätzlich wird im Root Element der eindeutige Namespace definiert und Tag Bibliotheken bzw. Java Pakete importiert.
<xsp:page
language="java"
xmlns="http://www.apache.org/1999/XSP/Core/"
>
· <xsp:logic>
In diesen Bereich wird die eigentliche Programmierlogik der XSP Seite eingefügt. Dieser Inhalt wird später in ausführbaren Code verwandelt.
<xsp:logic>
String formatDate(Date d, String muster) {
return (new SimpleDateFormat(muster)).format(d);
}
</xsp:logic>
In diesem Beispiel wird eine Funktion formatDate definiert, die als Parameter ein Datumsobjekt d und einen String muster erwartet und dann mittels der java.text Funktion SimpleDateFormat das aktuelle Datum nach dem gewünschten Muster transformiert.An dieser Stelle können beliebige Java Konstrukte eingesetzt werden, so sind hier u.A. natürlich auch SQL-Abfragen möglich.
· <xsp:expr>
Mit xsp:expr(ession) werden Ausdrücke in den XML Baum eingesetzt und schließlich in Text umgesetzt. Als Beispiel dient hier eben besprochene Funktion formatDate.
Aktuelle Zeit und Datum:
<xsp:expr>
formatDate(new Date(), "HH:mm dd.MM.yyyy")
</xsp:expr>
Die Funktion formatDate liefert einen String der Form 11:00 01.12.2000 zurück und dieser String wird ein neues Blatt im XML Baum.
Kombination XML & XSP
Es gibt zwei Möglichkeiten, XSP Seiten zu erstellen. Die erste ist, den XSP Code in ein normales XML Dokument einzufügen (in Abbildung 5 das index.xml Dokument).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: XML Seite ist XSP Seite
Diese index.xml beinhaltet nun zwei Processing Instructions (pi): Instruktion Nr.1 ist die geforderte Verarbeitung als XSP Seite (,,XSP" Kasten). Der von der XSP Seite gelieferte Output soll dann - gefordert durch die 2. Instruktion - von einem Stylesheet bearbeitet werden, nämlich von index.html.xsl. Das Resultat ist dann ein Dokument index.html, welches an den Client geschickt wird.
Dem aufmerksamen Leser fällt auf, dass in dieser Verarbeitungskette nicht die Vorteile genutzt werden, die XSP mit sich bringt: es wird nicht der Inhalt von der Programmierlogik getrennt. Beides ist in dem index.xml Dokument hinterlegt.
Um sinnvoll mit XSP zu arbeiten, sollte man die zweite Möglichkeit der Implementierung nutzen. Bei dem Ansatz, der in Abbildung 6 zu erkennen ist, wird der Inhalt strikt von Logik und Layout getrennt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: XSP Seite wird aus XML Seite erstellt
In der index.xml ist nun neben dem (redaktionellen) Inhalt nur noch eine pi vorhanden, nämlich die Instruktion, dieses XML Dokument mit einem XSL Stylesheet zu bearbeiten. In diesem Stylesheet - hier xspIncluded.xsp.xsl - ist nur XSP Code vorhanden, der in den Dokumentenkopf von index.xml (bzw. dessen DOM's) eingesetzt wird. Des weiteren hat dieses Stylesheet zwei pi's: die erste pi zur Erstellung einer XSP Seite und die zweite pi zum Anwenden eines zweiten XSL Stylesheets.
Die Kombination aus index.xml und xspIncluded.xsp.xsl ergibt also eine XSP Seite, die wie ein XML Dokument behandelt wird und auf welches dann ein zweites Stylesheet - index.html.xsl - angewendet wird, um den Output als XHTML zu formatieren.
In dieser Verarbeitungskette kann XSP seine Stärke demonstrieren, nämlich die Trennung von Inhalt und Logik.
Das Cocoon Servlet
Cocoon ist ein Servlet aus mehreren Komponenten, bzw. ,,Unter-Servlets". Diese Architektur wird von den Autoren als Reactor Pattern, einem Reaktor Konzept betitelt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: Architektur des Cocoon Servlets
Das Framework, dass Cocoon zur Verfügung stellt, wird in Abbildung 7 beschrieben. Alle orange/gelben Bereiche sind eben dieses Framework und die Blackboxen sind Komponenten, die in Cocoon standardmäßig implementiert sind und vom Anwender mit minimalem Aufwand durch eigene Komponenten ersetzt werden können.
Um die Architektur besser zu verstehen, wird nun der Weg eines Dokumentes (oder besser: dessen DOM Abbild) durch das Cocoon Servlet von der Anfrage bis zur Antwort an den Client im Detail beschrieben.
1. Request
Die Anfrage des Clients nach einem bestimmten XML Dokument auf dem Server beinhaltet wichtige Informationen für die Processing Engine. Neben der URL ist natürlich auch die Art des Clients (anhand des user-agent Strings) wichtig für spätere Verarbeitungsschritte.
2. Producer
Der Producer ist verantwortlich für die Übergabe von strukturierten Informationen in Form eines DOM's an den Reaktorkern. Hinter dem Producer versteckt sich also in den meisten Fällen nichts weiteres als ein XML Parser.
3. Reaktorkern
Der Reaktorkern (,,U" um Processor) selber macht nichts weiteres als zu determinieren, welcher...
4. Processor
mit dem Dokument arbeiten soll (eine XSL Transformation, eine XSP Seite etc.). Der Processor erweitert dadurch das DOM. Danach verlässt das DOM auch schon den Reaktorkern und befindet sich beim...
5. Formatter
Bei diesem Schritt in der Verarbeitungskette wird das DOM als Stream für den Client vorbereitet.
6. Reply
Hierhinter verbirgt sich ein fertig formatiertes Dokument inklusive aller nötigen Angaben wie MIME-Type, Länge etc., dass dann an den Client geschickt wird.
Tritt nun allerdings der Fall ein, dass ein Dokument entweder weitere Processing Instructions hat (etwa um erst den Dokumentkopf und dann denn Dokumentenfuß mit XSLT zu formatieren) oder dass es sich um eine XSP Seite handelt, dann wird der Schritt 6 (Reply) erst einmal übergangen und Schritt 7 (Loader) wird aktuell.
7. Loader
In beiden eben genannten Fällen tritt der Loader in Kraft. Dieser lädt Dokumente mit zusätzlichen Processing Instructions, übergibt diese wieder an den Producer und das DOM kann bei einem weiteren Durchlauf durch Cocoon erneut transformiert werden.
Handelt es sich um eine XSP Seite, so werden diese vom Loader kompiliert und in Producer verwandelt. Die XSP Seite steht nun also in der Architektur von Cocoon auf gleicher Ebene wie ein XML Parser, und übergibt genauso wie ein Parser strukturierte Informationen an den Reaktorkern.
Warum Java?
Nach diesem Einblick in die Architektur des Cocoon Servlets stellt sich die Frage, warum sich der Hauptautor Stefano Mazzocchi für Java als Programmiersprache entschieden hat.
Wichtig war für ihn der Portabilitätsaspekt, den Java mit sich bringt und die mächtigen objektorientierten Eigenschaften dieser Sprache. Sicherlich spielte auch der Fakt, dass alle Tools die Cocoon nutzt, ebenfalls in Java geschrieben sind (z.B. der XML Parser Xerces-J).
Neben der Frage ,,Warum Java" soll auch geklärt werden, warum Cocoon als ein Servlet und nicht beispielsweise einfach als mod_cocoon für den Apache httpd direkt vorliegt.
Auch hier war natürlich die Portabilität von Servlets wichtig. Cocoon läuft derzeit (Dezember 2000) auf ca. 60 verschiedenen Umgebungen aus Betriebssystem, Webserver und Servletengine und natürlich ist ein Servlet die naheliegende Lösung, wenn Java als Programmiersprache verwendet wird.
Das Cache System
Wie man sich leicht vorstellen kann, ist der Weg des DOM's durch das Servlet (siehe ,,Das Cocoon Servlet: Abbildung 7") resourcenintensiv und daher wird ein effektiver Cache benötigt.
Wenn ein Request von einem Client Cocoon erreicht, wird geprüft, ob der Output des verlangten XML Dokumentes im Cache liegt. Ist dies der Fall, und die Quelldateien (XML Dokumente, XSL Stylesheets) sind unverändert, so wird die gecachte Datei an den Client geschickt.
Wurde allerdings an einer Quelldatei ein Änderung vorgenommen, wird weiter vorgegangen, als wenn der Output nicht im Cache liegen würde, d.h.: das XML Dokument wird normal verarbeitet, dann an den Client geschickt und schließlich wird es im Cache gespeichert.
Abschließende Informationen
Stärken und Schwächen
Bei den Stärken ist sicherlich die volle Unterstützung von XML und Java als erstes zu nennen. XML und Java werden in Zukunft (nach Meinung des Autors dieses Dokumentes) sicherlich ein zweites Gleis neben HTML im Webserverbereich darstellen.
Auch sollte hier die flexible Architektur von Cocoon genannt werden, die durch ihre Modularität und natürlich auch durch das von der Apache Software Foundation verfolgte Open Source Konzept leicht an eigene Bedürfnisse anzupassen ist.
Wenn man über Schwächen von Cocoon spricht, dann ist dort ein eben besprochener Vorteil auch zugleich ein Nachteil. Denn ein Open Source Produkt hat keine Garantien gegenüber dem Anwender. Das Open Source allerdings keine Gefahr für den professionellen Nutzer sein muß, hat die Foundation u.A. mit dem Apache Webserver gezeigt.
Auch XML ist ein Nachteil, denn es ist in diesem Umfeld eine neue Syntax und es müssen erst einmal vernünftige Tools geschrieben werden, mit denen XML Dokumente erstellt und bearbeitet werden können.
Der wohl größte Nachteil von Cocoon wird die Verwendung von XSL sein. XSL - eine sehr komplexe Sprache die schwer zu verstehen ist. Gerade da XSL von Layoutern genutzt werden soll, wird die Masse der zeitgenössischen ,,Photoshop & Frontpage - Screen Designern" hoffnungslos mit XSL überfordert sein. Denn diese bringen nicht die nötige (Programmier-) Erfahrung mit, die man für das erfolgreiche Verwenden von XSL benötigt.
Cocoon vs. JSP & ASP
Vergleicht man Cocoon mit dynamischen Server Technologien wie Java oder Active Server Pages, die sich am Markt etabliert haben, so fällt auf, dass Cocoon die einzige Software ist, die eine Trennung von Inhalt und Logik vollziehen kann. Dazu soll nur kurz die JSP Funktion out.println() genannt werden, die die einzige Möglichkeit zur Ausgabe von Text darstellt. Mit anderen Worten: sowohl bei JSP als auch bei ASP sind Verarbeitungsketten wie bei Cocoon nicht möglich.
Im Hinblick auf die Architektur kann gesagt werden, dass die von Cocoon durch das modulare Reaktorkonzept flexibler ist, als die von JSP / ASP.
Und soll bei JSP oder ASP mit XML Dokumenten gearbeitet werden, so muss der XML Parser explizit aufgerufen werden.
Cocoon vs. PHP
Eine in diversen Newsgroups und Foren geführte Diskussion um die Vor- und Nachteile von Cocoon und PHP ist ungefähr genauso sinnvoll wie ein Vergleich von C mit Windows: nämlich absolut überflüssig. Denn: PHP ist eine Sprache mit der Daten veröffentlicht werden und Cocoon ist ein Framework, dass einen dabei unterstützt.
Nun könnte man aber die Frage stellen, warum eigentlich Cocoon entwickelt wird. PHP kann auch die Schichten Inhalt, Layout und Logik trennen; hat es doch ein Template-System in den Standard-Bibliotheken, ist objektorientiert etc. Dies ist natürlich auch mit PHP möglich, allerdings existiert eine Software, die eine analoge Funktionsweise wie Cocoon bietet, nicht. Möchte man also Cocoon mit PHP realisieren, so muss man sich an den 200.000 Zeilen Source Code orientieren, die Cocoon mittlerweile bietet.
Leitfaden zum Einsatz
Haben die Stärken von Cocoon überzeugt, muss man sich bewusst sein, dass ein XML / Cocoon Webserver sehr aufwendig in der Erstellung ist.
Beginnt man etwa ein neues Projekt, müssen XSL-fähige Layouter zur Verfügung stehen. Und das dies durchaus zu einem Problem werden kann, wurde in ,,Stärken und Schwächen" beschrieben.
Soll ein bestehendes Projekt in XML / Cocoon realisiert werden, kommt noch dazu, dass der Wandel (das Zerpflücken) von HTML in XML / XSL ebenfalls nicht einfach ist.
Doch für welchen Service Provider im Internet ist es eigentlich sinnvoll, Cocoon zu verwenden? Abbildung 8 soll diesen Entscheidungsprozeß erleichtern:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Wann ist die Verwendung von Cocoon sinnvoll?
Auf der X-Achse ist der Informationsgehalt, also der Umfang der Informationen die der Service für die Clients zur Verfügung stellt, abgetragen. Die Y-Achse beschreibt die Vielfalt der Clients, die auf diese Informationen zugreifen. Im Koordinatenursprung ist die Vielfalt sehr groß - es nutzen also alle erdenklichen Browser Typen von IE über Netscape über WAP (...) bis zu Lynx den Service.
In dem Diagramm wird der Einsatz von Cocoon als sinnvoll beschrieben, wenn die Clients recht unterschiedlich in ihren Darstellungsmöglichkeiten sind (also nicht nur Netscape, Internet Explorer und Opera) und gleichzeitig der Informationsgehalt des Services gehobenen Maßes ist.
Generell kann also gesagt werden, dass je mehr Informationen ein Service bietet und je unterschiedlicher die Clients sind, die darauf zugreifen, desto vorteilhafter ist der Einsatz von Cocoon als Webserver.
Dieser Sachverhalt soll nun an drei Beispielen erklärt werden:
1. Peters Aquarium im Internet
Peter hat seine fünf Zierfische fotografiert und diese mit zugehörigen Namen im Internet verfügbar gemacht.Der Informationsgehalt ist in diesem Fall extrem gering und es ist zu bezweifeln, dass jemals eine Person diese Informationen über ein WAP Handy abrufen wird; die Client -Vielfalt ist also dementsprechend gering ist.
2. FH Wedel
Mit Sicherheit ist die Menge der Informationen, die auf den FH Seiten abrufbar sind, eine Rechtfertigung für den Einsatz von Cocoon. Allerdings ist die Client -Vielfalt doch stark beschränkt, nämlich auf einen großen Anteil von Netscape, ein wenig IE und ganz wenig Lynx. Der Einsatz von Cocoon ist somit optional, und nicht empfehlend.
3. Newsbroker
Ganz heiße Anwärter für den Einsatz von Cocoon sind natürlich News Anbieter wie z.B. www.n24.de und www.ntv.de. Die Menge der angebotenen Informationen ist sehr groß und es greifen die unterschiedlichsten Clients auf die Seiten zu.
Cocoon 2
Cocoon 2 wird gegenüber der aktuellen Version 1.8.1 einige Vorteile haben, die aus der Entfernung von ,,Kinderkrankheiten" resultieren. Diese ,,Kinderkrankheiten" wurden dadurch begünstigt, dass Cocoon sehr viel schneller zu sehr viel mehr gewachsen ist, als es eigentlich vom Autor geplant war.
Deswegen schlichen sich einige Fehler und Restriktionen ein, die nun beim großen Versionssprung von 1.x zu 2.0 eliminiert werden sollen.
Die verbesserte Struktur wird sich im Detail durch weniger Speicherverbrauch, einer erhöhten Geschwindigkeit sowie einer erhöhten Modularität auszeichnen.
Literaturverzeichnis
Apache Software Foundation http://www.apache.org/ Informationen über den Aufbau der Foundation
Apache XML Project http://xml.apache.org/ Das XML Projekt von Apache
Apache Cocoon Project http://xml.apache.org/cocoon/ Informationen über Cocoon: Techniken, Architektur
Java Apache Project http://java.apache.org/faq/fom-serve/cache/236.html Kurzzusammenfassung von Cocoon und dessen Techniken
PHPBuilder.com http://www.phpbuilder.com/columns/bealers20000616.php3?page=2 PHP mit Cocoon verwenden
Häufig gestellte Fragen
Was ist das Apache XML Projekt?
Das XML Projekt der Apache Software Foundation verfolgt drei Ziele: Eine Austauschplattform für alle Arbeiten innerhalb der Foundation sein, die mit XML zu tun haben; Feedback aus Sicht der Implementierenden an standardisierende Organisationen liefern; und hochwertige XML Lösungen erstellen.
Welche Unterprojekte gehören zum Apache XML Projekt?
Das Apache XML Projekt besteht aus Xerces-J (XML Parser), Xalan (XSLT Stylesheet Processor), FOP (XSL Formatter), Xang (JavaScript/XML Projekt), SOAP (Simple Object Access Protocol) und Cocoon.
Was ist Apache Cocoon?
Cocoon ist ein Publishing Framework Servlet, dass mittels seines modularen Reaktorkonzepts ein XML-Quelldokument je nach anfragendem Client in ein beliebiges Zielformat transformiert.
Was ist der Zweck eines Publishing Frameworks wie Cocoon?
Ein Publishing Framework soll die Kosten reduzieren, die beispielsweise bei der Veränderung des Layouts eines Internetservices entstehen, leicht zu erweitern sein und den Verwalter von Informationen bei der Veröffentlichung unterstützen.
Wie trennt Cocoon Inhalt, Layout und Programmierlogik?
Cocoon trennt die drei Schichten Inhalt, Layout und Programmierlogik strikt voneinander und bearbeitet sie in verschiedenen Dateien (XML für Inhalt, Stylesheets für Layout, XSP für Programmierlogik).
Welche Vorteile bietet die Trennung von Inhalt, Layout und Programmierlogik?
Die Trennung ermöglicht die einfache und effektive Wiederverwendung von Stylesheets und Programmierlogik, verringert den Overhead für das Management und verkürzt die Time-To-Market des Internetservices.
Welche Techniken verwendet Cocoon?
Cocoon verwendet XML, XSLT, XSL:FO und XSP (eXtensible Server Pages).
Was ist XML?
XML ist eine Syntax für hierarchische Dokumente und zum Strukturieren von Informationen.
Was ist XSLT?
XSLT ist eine Sprache zum Transformieren von XML in ein beliebiges Zielformat.
Was ist XSL:FO?
XSL:FO (XSL:Formating Objects) ist eine Sprache, um 2D Layout von Text zu beschreiben, sowohl für Printmedien als auch für Digitalmedien.
Was ist XSP?
XSP (eXtensible Server Pages) ist eine DTD zur Trennung von Inhalt & Logik. Eine XSP Seite ist kompilierter Code.
Was sind wichtige XSP Tags?
Wichtige XSP Tags sind <xsp:page>, <xsp:logic> und <xsp:expr>.
Wie kombiniert man XML und XSP in Cocoon?
Es gibt zwei Möglichkeiten: Entweder den XSP Code in ein normales XML Dokument einfügen oder den Inhalt strikt von Logik und Layout trennen, wobei das XML Dokument nur noch den Inhalt enthält und das XSL Stylesheet den XSP Code.
Wie ist das Cocoon Servlet aufgebaut?
Cocoon ist ein Servlet aus mehreren Komponenten, bzw. ,,Unter-Servlets", die als Reactor Pattern bezeichnet werden. Dazu gehören Request, Producer, Reaktorkern, Processor, Formatter, Reply und Loader.
Warum wurde Java als Programmiersprache für Cocoon gewählt?
Java wurde aufgrund seiner Portabilität, mächtigen objektorientierten Eigenschaften und der Tatsache, dass alle Tools, die Cocoon nutzt, ebenfalls in Java geschrieben sind (z.B. der XML Parser Xerces-J), gewählt.
Wie funktioniert das Cache System in Cocoon?
Wenn ein Request von einem Client Cocoon erreicht, wird geprüft, ob der Output des verlangten XML Dokumentes im Cache liegt. Ist dies der Fall, und die Quelldateien sind unverändert, so wird die gecachte Datei an den Client geschickt.
Was sind die Stärken von Cocoon?
Die Stärken von Cocoon sind die volle Unterstützung von XML und Java, die flexible Architektur und die Modularität.
Was sind die Schwächen von Cocoon?
Die Schwächen von Cocoon sind das Fehlen von Garantien (als Open Source Produkt), die Komplexität von XML und die Verwendung von XSL, die für manche Layouter schwer zu erlernen ist.
Wie unterscheidet sich Cocoon von JSP und ASP?
Cocoon ist die einzige Software, die eine Trennung von Inhalt und Logik vollziehen kann. Die Architektur von Cocoon ist flexibler als die von JSP / ASP.
Wie unterscheidet sich Cocoon von PHP?
PHP ist eine Sprache mit der Daten veröffentlicht werden und Cocoon ist ein Framework, dass einen dabei unterstützt.
Wann ist der Einsatz von Cocoon sinnvoll?
Der Einsatz von Cocoon ist sinnvoll, wenn die Clients recht unterschiedlich in ihren Darstellungsmöglichkeiten sind und gleichzeitig der Informationsgehalt des Services gehobenen Maßes ist.
Was sind die Vorteile von Cocoon 2 gegenüber Cocoon 1.x?
Cocoon 2 wird weniger Speicher verbrauchen, schneller sein und eine erhöhte Modularität aufweisen.
- Quote paper
- Anonym (Author), 2000, Das Apache Cocoon Projekt, Munich, GRIN Verlag, https://www.grin.com/document/98941
