© kallejipp, photocase.com

Viele Wege führen ans Ziel, das gilt auch für die Wahl von Software für die Website. Wer aber zuerst ankommt und unterwegs Angenehmes erlebt, ist klar im Vorteil. Der Versuch einer Podest-Zuweisung.

Durchs Ziel haben sie es alle geschafft: Sowohl mit Contao und Magnolia CMS als auch mit Rails und Django haben die beauftragten Experten eine funktionierende Veranstaltungsübersicht produziert. Der Unterschied besteht darin, mit welchen Mitteln und mit welchem Aufwand sie es getan haben.

Stilfrage

Differenzen zeigen sich aber auch im Arbeitsstil: Dass beispielsweise hinter Magnolia CMS das Räderwerk eines Unternehmens arbeitet, zeigte sich rasch. Die Firma beauftragte einen In-House-Entwickler, der innerhalb von zwei Wochen eine ansprechende Lösung produzierte und an die Redaktion schickte. Daneben war er der einzige, der neben dem Code auch noch mehrere Seiten Dokumentation einreichte, zudem eine vorbereitete Tomcat-Instanz zum Ausprobieren.

Der Ruby-on-Rails-Mann installierte seine Anwendung dafür flugs öffentlich auf der Plattform Heroku, publizierte den Code auf Github und unterzog ihn den ständigen Tests des freien Continuous-Integration-Tools Travis.

Möchte man den Absolventen eine Rangfolge zuweisen, bietet es sich an, erreichte Features abzuhaken. Magnolia CMS hat die Daten erfolgreich importiert, verwendet einen Cache und bietet dem Anwender ein hübsches Kalender-Widget. Dazu kommt jedoch noch ein besonderes Feature: Sobald die Daten im Java Content Repository gespeichert sind, lassen sie sich über die Redaktionsoberfläche auch bearbeiten, sperren oder freigeben. Diesen im Testfeld einmaligen Zusatznutzen honoriert die Redaktion symbolisch mit dem ersten Platz.

Das einzige, was man Magnolia ankreiden könnte, ist die etwas wortreiche Syntax der Programmiersprache Java. Da fassen sich die beiden Kandidaten Rails mit Ruby und Django mit Python merklich kürzer. Sie haben überhaupt einiges gemeinsam, denn sie folgen beide der Architektur Model-View-Controller (MVC) und verwenden einen Object-Relational-Mapper (ORM), der die Brücke zwischen SQL-Datenbank und objektorientierter Programmierung schlägt.

Ruby kommt mit weniger Bearbeitung von Konfigurationsdateien aus, da es stärker nach dem Motto “Convention over Configuration” ausgerichtet ist. Wenn ohnehin schon alle Komponenten vorgeschriebene Namen oder zumindest Namensmuster haben, bleibt nicht mehr viel zu konfigurieren. Doch nicht allein deshalb hat Ruby on Rails die Nase ein wenig vor Django. Der Rails-Entwickler hat in einem beherzten Coup gewagt, ganze Komponenten auszutauschen: Das Ruby-Framework dient ihm nur zum Umsetzen eines Datenservers, die Ansicht übernimmt Angular.js in Javascript. Dazu verwendet er noch ein Template-System seiner Wahl, verwaltet die Javascript-Bibliotheken mit dem Paketmanager Bower – und liefert die Tests für seine Anwendung gleich mit. Eine beeindruckende Demonstration von Flexibilität und Erweiterbarkeit. Das hätte fast für den ersten Platz gereicht, auf jeden Fall aber für die Nummer zwei.

Schnell, aber zu Fuß

Beim PHP-basierten Contao brauchte der Entwickler zwar nur einen einzigen Tag für seine Lösung, aber es waren insgesamt elf Dateien für die Umsetzung erforderlich, nur bei einzelnen könnte ein mitgelieferte Generator helfen. Das abgedruckte Listing zeigt, dass er auch Selbstverständliches wie den Speicherort der CSS-Stylesheets im Code angeben musste. Klug ist dagegen die Idee, den Eventkalender als Erweiterung zu implementieren – dafür umso enttäuschender, dass es keinen Installationsmechanismus für das fertige Modul gibt.

Wer schließlich das so genannte Template für Contao betrachtet, vermisst schmerzlich die Trennung von Präsentation und Logik: Hier mischt sich eine HTML-Tabelle mit waschechtem PHP-Code. Und schließlich folgt noch ein regelrechtes K.-o.-Kriterium: Das Fehlen aktueller, brauchbarer Dokumentation.