Cocoon-Anwendung zusammenbauen, wie man möchte.

Java Magazin: Nachdem es um Cocoon 2 still geworden war, hat das Team begonnen, Cocoon 3 zu entwickeln. Was sind die großen Vorteile von Cocoon 3 gegenüber seinem Vorgänger?

Simone Tripodi: Cocoon 3 wurde von Grund auf neu geschrieben und ist gut durchdacht, während Cocoon 2 „bottom-up“ entwickelt wurde. Reinhard Pötz und Steven Dolg, die Erfinder von Cocoon 3, haben festgestellt, dass die Modularisierung in vorhergehenden Releases nicht so gut war, wie wir erwartet hatten. Neue Komponenten zu integrieren bedeutete demnach eine Menge Arbeit. Daher begannen sie mit einer Pipeline-basierten Architektur, die es nicht nur möglich machte, neue Features von Cocoon selbst schnell einzufügen, sondern es auch den Benutzern erlaubte, eigene Anwendungen mit direkten Zugriff auf diese Pipelines zu erstellen. Das bedeutet, dass die User, die Interesse an den Vorteilen von Cocoon haben, nicht länger gezwungen werden Cocoon-Container zu verwenden. Sie können ihre „Cocoon-powered“ Anwendung einfach so zusammenbauen, wie sie es möchten.

Java Magazin: Heutzutage gibt es eine Menge großartiger Frameworks – man denke an Apache Wicket oder Apache Tapestry. Wird dadurch Cocoon nicht irgendwie obsolet?

Simone Tripodi: Ich würde eher sagen, die Frameworks haben verschiedene Ziele. Cocoon orientiert sich mehr an Datenmanipulation und dem Erstellen von Web Content. Wicket undTapestry dagegen stellen eher das Modell einer Webanwendung bereit. Aus diesem Grund arbeitet das Cocoon-Team daran, solche Frameworks zu integrieren. Es gibt sogar eine Wicket-Anbindung! Wir versuchen das Rad nicht neu zu erfinden und sehen einfach nach, welches Framework etwas macht, das Cocoon nicht macht. Und dann versuchen wir, dieses Framework zu integrieren. Auf diese Weise können die Benutzer das Beste aus beiden Welten bekommen, ohne dass man darunter leiden müsste, wenn einem Framework mal etwas fehlt. Ein Beispiel: Bekanntermaßen hat Francesco Chicchiriccó (Anm. JM: PMC im Cocoon-Projekt) ein System für seine italienischen Kunden entworfen, das für das Frontend Apache Wicket und im Backend eben Cocoon verwendet.

Java Magazin: Was sind die nächsten Schritte für Cocoon 3?

Simone Tripodi: Wir sind gerade dabei aus der Alphaphase herauszukommen. Bedauerlicherweise bräuchten wir mehr Zeit, denn leider ist niemand von uns ein Vollzeit-Cocoon-Entwickler. Was soll’s, besser spät als nie! Leute benutzen die Cocoon-3-APIs trotz ihres Alphastatus‘. Sie wissen was das bedeutet: Die API-Signatur ist nicht stabil und kann sich verändern, oder die Software kann einfach unerwartete Fehler produzieren.

Java Magazin: Wenn du in die Zukunft sehen könntest, was erwartet Cocoon 3? Wird es jemals so populär werden wie Cocoon 2?

Simone Tripodi: Ich denke, dass die Popularität von Cocoon 2 in den W3C-Technologien begründet lag: XML, XSchema und XSLT waren zu der Zeit relativ neu und aufregend. Heute haben viele Leute diese Welt verlassen, um die neuen und aufstrebenden Formate JSON oder YAML zu verwenden – und das Internet ist voll von Software, die mit diesen Inhalte umgehen kann Deswegen wird Cocoon 3 vermutlich nicht so populär, wie Cocoon 2. Trotzdem ist es immer noch ein großartiges Werkzeug, um mit den nicht ganz so modernen, aber dafür stabilen und weit verbreiteten Formaten zu arbeiten.

Java Magazin: Vielen Dank für dieses Gespräch!

Simone Tripodi ist seit 2009 Teil des Cocoon-3-Projekts und wurde Chair des PMC-Komitees. Im C3-Projekt verbesserte er die XSchema/XSLT/XInclude-Unterstützung von C3-Pipeline-Komponenten und erarbeitete die Unterstützung von Artefakten/Modulen, wie Apache FOP, CyberNeko HTML und anderen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.