Ich habe mir in letzter Zeit viel Gedanken über die verfügbaren Optionen zum Bau von Websites gemacht. Es gibt

• Content-Management-Systeme: Typo3, Joomla, SixCMS, Coremedia, ...
• Content-Management-Frameworks: Drupal, Django Project, …
• Model-View-Controller-Frameworks: CakePHP, Symfony, Zend Framework, RoR, …
• andere Frameworks: Pear, Zope, ...
• Ad-Hoc-Programmierung; PHP, JSP, ASP, ...

Natürlich sind nicht alle Websites gleich und daher können die meisten dieser Systeme und Ansätze unter einem vorgegeben Satz von Anforderungen ihre jeweilige Stärke besonders gut oder besonders schlecht ausspielen. Wenn ich mich aber auf PHP-basierende Systeme beschränke – nicht weil PHP so toll ist, sondern wegen meiner Sozialisierung und wegen “Sachzwängen”, so sind die naheliegenden Kandidaten in vielen Web-Projekten Drupal und eines der MVC-Frameworks.

Das Zend-Framework hatte sich ziemlich schnell wegen unerklärebarer Überkomplexität und fehlender Modell-Ebene disqualifiziert. Nach drei kleineren Web-Projekten in den letzten Wochen mit CakePHP und Drupal schlägt das Zünglein an der Waage immer öfter Richtung Drupal aus, und zwar aus folgenden Gründen:

• Jedes Web-Projekt braucht ein paar content-lastige Seiten für Impressum, Handbücher, Marketing-Blurb usw., sprich, es braucht immer irgend eine Form von CMS, die man bei blossen MVC-Frameworks dazu erfinden muss.
• Web-Projekte brauchen Menschen, die sich darum kümmern: Administratoren, Redakteure, Partner-Sites, also eine Rechteverwaltung. In CakePHP zumindest ist diese recht zäh zu integrieren und hat dann immer noch keine Verwaltungsoberfläche. Ein weiterer Punkt für Drupal.
• Datenbank-Abstraktionsschicht, Formulare, Caching, Listen. Jedes auch nur sanft anspruchsvolle Projekt hat ein paar eigene Datenstrukturen, Registrier- und Pflegeformulare, Anforderungen an Skalierung, mehrseitige Content-Listen usw. Zumindest beim direkten Vergleich zwischen Drupal und CakePHP merkt man einfach, dass Drupal in der Version 6 in fast allen diesen Punkten um Lichtjahre ausgereifter und leichter zu bedienen ist als die in CakePHP anstehende Version 1.2.
• Schema und Schema-Migration. Automatische Introspektion ist prima für einfache Fälle. In komplexeren Fällenaber muß man entweder ständig mit neuen Relations-Konzepten im MVC-Framework kämpfen oder man benutzt tatsächlich SQL-Statements, von denen man direkt beim Hinsehen versteht, was sie machen. Und warum gibt es in CakePHP keine einfach funktionierenden Mechanismus für Schema-Updates?
• Trennung von Routing, Modell, Anwendungslogik und Präsentation. Klassisch eine augenscheinliche Stärke der MVC-Frameworks, scheint mir subjektiv Drupals Menü/Modul/Theme-System viel besser geeignet, funktionale Einheiten beieinander zu halten und nicht in einem Wald von Verzeichnissen zu verteilen. Es ist einfach nicht richtig, für eine Funktionseinheit ‘‘Feed-Manager’‘ jeweils eine einzelne Datei in einem models, einem controler und mehreren views-Verzeichnissen zu verteilen, anstatt sie wie in Drupal in einem einzigen Modul-Verzeichnis zu sammeln.
• Javascript: Es gibt immer noch Systeme (CakePHP, Symfony), die auf Prototype setzen. Drupal hat jQuery eingebaut – himmlisch!
• Vision: Für mich ist klar: Die nächste Revolution im Web ist Cloud Computing. Drupal hat zwar noch keine fertige Lösung, aber die Richtung ist erkannt.

OK, mit Symfony habe ich keine wirkliche praktische Erfahrung. Dem Buch nach ist es etwas komplexer als CakePHP, vielleicht auch mächtiger. Den Versionsnummern nach ist es aber wohl noch einige Zyklen zurück. Es bleibt dabei: Ich liebe Drupal, und wenn auch nur wegen api.drupal.org, den Code-Standards und seinen coolen Entwicklern.