Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Software & Infrastruktur

Open Source: Papaya CMS zielt in Version 5 auf große Webprojekte

Mit der neuen Version 5.0 wollen die Macher des Open-Source-CMS papaya vor allem größere Internetprojekte für sich gewinnen. Umfangreiche Caching-Funktionen und aktuelle Technologien sollen hier überzeugen. Durch den modularen Aufbau soll es bei alldem nicht nur ein Content Management System sein, sondern sich auch als Framework eignen.

Papaya wurde bis 2005 kommerziell vertrieben und ist seitdem unter der GNU General Public Licence (GPL) quelloffen. Die Firma hinter dem CMS verdient ihr Geld heute mit Support und Schulungen rund um das System.

Zu den grundsätzlichen Eckdaten: Papaya nutzt PHP ab Version 4.4 oder PHP 5 und benötigt als Datenbank MySQL ab Version 4.1, PostgreSQL ab Version 8.x oder SQLite. Als Templatesprache kommt XSLT 1.0 zum Einsatz.

Die Macher betonen in ihrer aktuellen Pressemitteilung zur neuen Version unter anderem die „leistungsstarken Caching-Technologien“ und die besondere Eignung für den professionellen Unternehmenseinsatz sowie für barrierefreie Internetangebote. Offene Standards wie XML-Speicherung, XSL-Templatesystem und umfassender UTF-8-Support werden ebenfalls hervorgehoben.

Neu in der Version 5.0 sind unter anderem Funktionen für den Einsatz in Multi-Site- oder Multi-Domain-Projekten, ein mehrstufiges Cachingsystem mit Support für memcached und xslcache sowie Support für Webserver- und Datenbankcluster. Zudem wurde das Backend neu gestaltet und das Handbuch umfasst nun 1.300 Seiten.

Schon jetzt kann papaya übrigens auf große Websites in seinen Referenzen verweisen. Dazu gehört beispielsweise die Multimedia-Plattform Hobnox.

Wer sich papaya ansehen möchte, findet auf der offiziellen Website einen entsprechenden Demozugang und hier die Downloads.

Bildnachweis für die Newsübersicht: love・janine. Lizenz: CC BY

Screenshots vom Backend

» alle Foto-Streams

Finde einen Job, den du liebst

4 Reaktionen
Jan
Jan

Der Unterschied ist mehr in der Anwendung (extern) als in der Klasse bemerkbar: Der Anwender aka Rolle Redakteur muss eine Ansicht (Modul, XML-Ausgabe, Controller) mit einer Ausgabe (XSL) verknüpfen.

Da es keine zusätzliche (und auch verkomplizierende) Methodik gibt, dynamisch ein Model in den Controller einzuhängen, können sowohl reine MVC als auch (MC)-V Ergebnisse entstehen. Wer faul ist, macht also alles im Controller (idR Box- und Seitenmodule). Das aus struktureller Sicht dies natürlich nicht optimal ist und eine Kapselung über eine Model/Daten-Basisklasse zu empfehlen ist, versteht sich alleine.

Nicht von der Hand zu weisen ist natürlich der vergleichsweise steile Lernkurve und die gleichzeitig überschaubare Community. Die ebenfalls neuen und jetzt verfügbaren Entwickler-Dokumentationen könnten da aber entgegenwirken.

Ein technischer Hinweis zu der Geschichte mit XML: Leider ist es aus technischer und performanter Sicht nicht leicht, einegeeignete Struktur VORZUgeben. Selbstverständlich empfehle ich auch für alle Ausgaben eine eigene Delegatorklasse zubauen, aber man wird nicht dazu gezwungen. Echte XML-Knoten-Objekte scheiden aus Gründen der Performanz aus, und die Alternative über (komplexe) Arrays (also Liste/Map) ist im Endeffekt nur sehr bedingt besser/übersichtlicher.

Antworten
Martin Brüggemann

Hi Massimiliano, danke für deinen Kommentar.

"...und die Basisklassen der jeweiligen Anwendungen stellen das Modell dar."

Ok. MVC meint für mich, dass es unter anderem ein Model gibt, dass sämtliche Zugriffe auf Objekte kapselt. D.h. ich darf zum Beispiel aus der View und insbesondere aus dem Controller nie direkt auf die Datenbank zugreifen, sondern muss immer mit dem Objekt über das Model arbeiten. Soweit ich das beurteilen kann, ist das bei Papaya alles ziemlich vermischt und SQL gibt es in den Controllern reichlich. Bei TYPO3 4.x ist das ähnlich. Deshalb wird mit FLOW3 und TYPO3 5.0 ja gerade alles neu gemacht. Ich denke z.B. an die Anforderung im Nachhinein die Save-Methode eines Objekt-Typs modifizieren zu wollen, dass beim Speichern auch noch ein Tweet rausgeschickt wird. Wie würde ich das bei Papaya möglichst einfach hinbekommen?

Die Sache mit dem XSLT als Template-Sprache ist zugegebenermaßen ziemlich abgefahren. Denke damit hat Papaya auf jeden Fall ein Alleinstellungsmerkmal und eignet sich optimal für HTML-fremde Ausgabeformate wie PDF oder XML-Backends für Flash-Oberflächen. Das rockt schon.

Für den Otto-Normal-Entwickler, dürfte das aber eine ziemlich hohe Einstiegshürde darstellen. Smarty oder eine andere Template-Sprache kann man sich schnell reinziehen, aber XSLT lernen schreckt viele erfahrungsgemäß ab.

Bei der XML-Ausgabe stört mich im Übrigen auch die Art, wie das XML erzeugt wird. Bei Papaya stehen die XML-Node-Elemente meist direkt im PHP-Quellcode - das hat sowas PHP-HTML-Vermischungs-mäßiges. Wenn man sowas heute neu schreiben müsste, würde man sämtliche XML-Ausgaben in Template-Objekte kapseln und am Ende z.B. über eine Render-Methode in XML ausgeben. Hält den Code schlank und ist flexibler.

Bitte nich falsch verstehen. Papaya ist meiner Meinung nach kein schlechtes CMS. Aber der Grund warum ich unbedingt darauf umsteigen sollte ist mir nicht klar. Evtl. weil es sich für einige Anforderungen durch fertige Module out-of-the-box eignet. Aber als "State-Of-The-Art-CMS-Framework" hat mich Papaya auf den ersten Blick (auch unter die Haube) nicht überzeugt. Sorry. Cooles Marketing. Mit hobnox auch eine super Referenz, aber an vielen Stellen das Rad unorthodox neu erfunden und auf lange Sicht wird die Community zu klein sein, um exponentiell abzustarten. Ist ein Bißchen ein Henne-Ei-Problem. Wenn das Produkt nicht auf den ersten Blick rockt, wächst auch die Community nicht so wie man sich das vorstellt und das Produkt wird nur unschlagbar gut, wenn sich möglichst viele Entwickler auf den ersten Blick dafür begeistern lassen...

Antworten
Massimiliano Siddi

Die Aussage, es gäbe kein MVC ist so eigentlich nicht korrekt. Die MVC-Architektur ist recht stringent aufgebaut: Seiten- bzw. Boxmodule sind die Controller, der XSLT-Ausgabefilter ist die View und die Basisklassen der jeweiligen Anwendungen stellen das Modell dar. Die eigentliche Stärke von papaya CMS besteht gerade in der Trennung von Content (Datenbank), Programmlogik, Templatelogik (XSLT) und Layout (CSS, Schmuckgrafiken), was in den Demo-Templates recht gut illustriert ist.

Außerdem ist es doch kein Nachteil, dass papaya CMS kein ORM benutzt. Der Einsatz einer ORM-Architektur ist ja nicht per se ein Qualitätssiegel. Aber gut, an dieser Stelle ist papaya CMS eben nicht Buzz-Word-kompatibel ;-)

Ja, es stimmt, der strukturelle Aufbau des papaya CMS ist nicht so einfach zu verstehen. Es handelt sich nun mal um ein recht komplexes System. Ich würde es aber nicht unbedingt als unübersichtlich bezeichnen - was jetzt auch daran liegt, dass ich den Quellcode selbst recht gut kenne, wie ich zugeben muss. Es ist auch wahr, dass die MediaDB nicht gerade ein Vorbild an objektorientiertem Design darstellt, aber die MediaDB stellt auch nicht gerade eine typische papaya-Klasse dar. Die Klasse befindet sich jedoch auch seit sehr langer Zeit im Einsatz - es handelt sich um ein sehr stabiles Stück Software.

Übrigens sind die Debug-Ausgaben der einzige Bereich im papaya CMS, in dem direkt HTML ausgegeben wird. Alle anderen Ausgaben erfolgen strikt in validem XML.

Antworten
Martin Brüggemann

Hab mir gerade mal den Quellcode angeschaut und mein erster, eigentlich positiver Eindruck (basierend auf einem Blick auf das Interface und die Produktbeschreibung) hat sich schnell wieder relativiert. Leider gibts weder MVC noch ORM und der strukturelle Aufbau des CMS erschließt sich mir auch nicht.

Dafür ist das Ding ganz schön unübersichtlich und es gibt PHP-Klassen, wie z.B. die papaya_mediadb.php, mit 5660 Zeilen prozeduralem PHP-Code, Dateien mit massig SQL und HTML-/XML-Tags im Quellcode und ich frage mich, ob der Produktflyer nicht deutlich mehr verspricht als da wirklich unter der Haube steckt...

Sicherlich nicht das Schlechteste Open-Source-CMS, aber aufgrund wahrscheinlich historisch bedingten, Oldschool-Aufbaus kann ich es leider auch nicht abfeiern.

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen