Nachdem ich wieder etwas tiefer in die Web-Entwicklung einsteigen möchte und größtmögliche Flexibilität, bei geringstem Aufwand erwarte (der Dollinger, die faule S..), habe ich mich mal wieder auf dem Markt umgesehen und nach meinen Ruby On Rails (RoR) Abstechern mich wieder auf PHP Lösungen konzentriert. Warum nich RoR? Naja, RoR ist recht nett und ich […]

Dieser Beitrag wurde 2007 veröffentlicht.
Seitdem hat sich viel getan und manche Informationen und Links sind vielleicht nicht mehr aktuell!

CakePHPNachdem ich wieder etwas tiefer in die Web-Entwicklung einsteigen möchte und größtmögliche Flexibilität, bei geringstem Aufwand erwarte (der Dollinger, die faule S..), habe ich mich mal wieder auf dem Markt umgesehen und nach meinen Ruby On Rails (RoR) Abstechern mich wieder auf PHP Lösungen konzentriert.

Warum nich RoR? Naja, RoR ist recht nett und ich habe mich auch etwas vom Hype tragen lassen, aber die Einstiegshürden bei der Installation von Rails und RoR auf dem vorhandenen, dedizierten Server sind recht hoch (in Deutschland gibt es noch kaum Webhoster, die RoR unterstützen), die Performance ist doch recht knapp (die RAM-Auslastung mit Apache und FastCGI ist ziemlich heftig) und dann kommt noch die umständliche Konfiguration mit YAML, Kommandozeile etc.. Hauptgrund war aber, dass ich jetzt nicht auch noch vertieft RUBY lernen wollte, wenn ich mit PHP doch schon lange recht komfortabel unterwegs bin.

Sicher Scaffolding, die Trennung von Datenmodell, Darstellung und Businesslogik nach dem MVC-Prinzip und diverse Helferlein sollten es schon ein, aber dazu ist RoR nicht mehr erforderlich. Ich wollte auch meine bisherigen (teils selbstentwickelten) Frameworks und Libraries ablösen, ohne jedoch ganz auf sie verzichten zu wollen. Eine weitere Voraussetzung war für mich die Unterstützung von PHP4 und PHP5, ein bisschen AJAX-Magie sowie die einfache Distribution vom Entwicklungsserver auf den Live-Server. Wenn das Framework dann auch nicht so akademisch und extrem abstrahiert daher kommt, wäre es ein Kandidat für mich. Außerdem möchte ich keine weitere Template-Engine, deren Syntax man erst wieder lernen muss (Smarty etc.) und ohnehin nur die Performance runterzieht – einfache PHP Syntax sollte genügen.

Ausgeschieden sind nach den obigen Vorbedingungen:

  • PRADO – Ich mag den lustigen Pilz, aber es ist nur für PHP5, verfolgt eher dieses Event-Driven Prinzip von ASP und ist – so denke ich zumindest – ein ziemlicher Overkill. Sicher ist PRADO eine nette Studie, die zeigt, was man mit PHP(5) so machen kann, aber schon etwas zu viel des Guten.
  • Mojavi – Hier hat zum Testzeitpunkt der Internetauftritt wg. Umbauarbeiten nicht funktioniert, daher keine Bewertung. Benötigt aber auch PHP5
  • PHPTrax -Der nicht nur namentlich extremste Ruby On Rails Ripoff – zu viel Kommandozeile und ich möchte nicht einfach einen 1:1 RoR-Klon
  • Symfony – Nur PHP5 – auch schon zu mächtig

Was blieb übrig?

CodeIgniter schien mir die ideale Lösung zu sein: Sehr leichtgewichtig, einfache Installation, wenig Konventionen und Abstraktion, guter Background (pMachine) etc.. Die Ernüchterung kam nach 2 Tagen des Probierens: Das Framework ist schon zu leichtgewichtig, will hei??en, es fehlt an Funktionsumfang. Der oft beredete Performancevorteil kommt einfach daher, dass wenig drin ist …
Eine File-Funktion, die einfach den aktuellen Pfad mit allen darin enthalten Dateien auslesen soll, macht dieses rekursiv durch alle darin enthaltenen Verzeichnisse, ohne dass man dieses einschränken könnte, oder ein multidimensionales Array erzeugt würde. Das M in MVC wird nahezu nicht beachtet, das meiste spielt sich im Controller ab. Aber auch die Formularerzeugung und vor allem die Validierung der gleichen ist ziemlich unbefriedigend umgesetzt. Es gibt zwar einige Libraries wie Forge oder Rapyd, aber die machen diesen grundlegenden Nachteil auch nicht wett. Active Record ist zwar ansatzweise vorhanden, aber weit hinter dem her, was man von Rapid Development und agilen Programmiertechniken erwartet und nicht zuletzt von RoR kennt.

Noch schlimmer ist es, dass man wohl einen Master-View (mit dem grundlegendem Layout) mit mehreren Formulare und jeweils eigenen Views (Wiederverwendbarkeit, Modularität) scheinbar nicht miteinander unter einem Hut bringt. Einige Anfragen im Forum lies hier nur noch mehr Fragen offen und die Dokumentation schweigt sich zum Thema gänzlich aus. Zwar gibt es das berühmte „Blog in 20 Minutes“ Tutorial, aber das behandelt nur rudimentärste Anwendungen.

Meine Testanwendung, eine Bildergalerie mit Upload, Verwaltung, Bildmanipulationen, Anmerkungen etc. brach ich entnervt ab.

Fazit: CodeIgniter kann mal interessant werden, es fehlt aber eindeutig an Funktionsumfang und es ist noch nicht erwachsen genug. Meiner Ansicht nach ist es vom Versionsstatus eher eine schwache 0.5 Version.

Seagull hat irgendwas. Mit den CMS, Navigations-, Usermanagement, Messaging-Komponenten usw. scheint es sehr attraktiv zu sein, mir fehlte allein die Zeit, mir es genauer anzusehen. Ich behalte es aber auf jeden Fall im Auge und werde es genauer testen.

CakePHP ist meine Wahl der Stunde. Schnelle Installation, durchgängiges Konzept, wenige aber sinnvolle Konventionen, sehr guter Funktionsumfang, sehr agile und freundliche Community, die „Bakery“ mit vielen guten Tutorials und Erweiterungen machen es greifbar und sympathisch. Mit dem Scaffolding und dem relationalen Mapping (belongsTo, hasMany, hasOne …) von Cake ist das Datenmodell schnell zusamen geschraubt und bestückt, und mit der „bake“ Funktion lassen sich gleich entsprechende Views, Controller usw. erstellen, die dann nach den eigenen Wünschen verfeinert werden können – hier ist dann auch gleich wieder der RoR Ansatz spürbar. Außerdem zerrt es nicht zu sehr an der Leistungsfähigkeit des Servers, da es nicht unnötig Overhead mit sich herumträgt.

Fazit: Wenn der Kuchen spricht, haben die Krümel Pause! CakePHP schmeckt einfach auf Anhieb und hat nicht zu viele Rosinen drin, denn die mag ich nicht 🙂

Seagull: FOLGT! Folgt nicht, Grund: Zu gro??er Overhead

Interessant auch dieser Beitrag:

http://blog.helmschrott.de/software/update-rubyonrails-mvc-und-so

2 Responses

  1. Simon

    Ich stand auch vor der Entscheidung, welches Framework ich verwende. Habe mich dann dazu entschlossen, ein eigenes zu entwickeln.

    Warum hast du denn Zend nicht getestet?

    Antworten

Und jetzt seid ihr dran! Schreibt doch einen Kommentar!

Mit gekennzeichnete Links sind Affiliate-Links zu Amazon