Kategorien
CodeIgniter
Manch einer mag denken „Noch ein weiteres PHP Framework“, aber CodeIgniter, kurz CI genannt, hat dann doch einige Alleinstellungsmerkmale.
Wenn du keine Frameworks magst, da du der Meinung bist, dass sie zu viel Performance benötigen, schwierig zu installieren sind, oder spezielle Anforderungen an das System stellen hast du CI noch nicht getestet.
Die einzige Systemvorraussetzung die CI hat, ist ein System mit einer PHP Version ab 4.3.2, wobei man jedoch auch auf Basis von PHP 5 entwickeln kann und dessen Vorteile genießen darf. CI selbst nutzt unter PHP 5 zum Beispiel die Möglichkeit seine Basis Klasse per self::$instance anzusprechen und bietet auch die Möglichkeit bei der Erstellung von Datenbankabfragen per active record die Methoden zu verketten (method chaining):
$this->db->select('title')->from('mytable')->where('id', $id);
Vorteile von CodeIgniter
- Unterstützung von PHP 4 – wenn man es benötigt – und Installation ohne Konsolenzugriff. Es werden auch keine externen Libraries oder PEAR benötigt.
- Sehr gute Performance im Vergleich zu anderen Framworks Test von avnetlabs (EN) pr0digy (EN)
- Geringer Ressourcenverbrauch, da Libraries erst geladen werden, wenn diese benötigt werden.
- CI zwingt einen keinen bestimmten Programmierstil auf – es wird jedoch klar ein MVC Ansatz angestrebt.
- Kein bestimmtes, oder wenn gewünscht auch gar kein, Template System.
- Unterstützung durch die Community Forum IRC codeigniter.ch User Guide
Allgemeines
CodeIgniter wird seit Februar 2006 von EllisLab Inc. entwickelt und ist im Rahmen einer an Apache/BSD angelehnten Lizenz nutzbar. License (EN)
EllisLab entwickelt dabei die Version 2.0 ihres kommerziell vertriebenen CMS ExpressionEngine auf Basis von CodeIgniter.
In CI Version 2, das sich aktuell in Entwicklung befindet, wird der PHP 4 Support deprecated sein.
Neue Funktionen werden nur mehr PHP 5 kompatibel entwickelt. Ab CI 2.1 soll PHP 4 nicht mehr unterstützt werden.
Wenn man auf der Suche nach einem freien CMS auf Basis von CI ist –
PyroCMS ist aktuell bereits als RC 1 Version 0.9.8 erhältlich.
Vergleich
| CodeIgniter | Zend Framework | CakePHP | |
|---|---|---|---|
| Installation | Ein einfaches entpacken der ZIP Datei reicht dazu vollkommen aus. Diese umfasst dabei auch nur etwa 2,2MB inklusive User Guide. |
Nach dem Entpacken muss man noch mittels dem command line Tool zf ein Projekt anlegen. Das Framework ist bereitsbeim Download sehr gewaltig und benötigt zwischen 5,7MB und 24MB. |
Die Installation gestaltet sich gleich einfach wie bei CI. Die Zip Datei umfasst dabei gerade einmal 1,3 MB, jedoch ohne Handbuch. |
| Dokumentation | Die Dokumentation bei CI ist ausführlich und sehr gut strukturiert. Antworten auf speziellere Fragen findet man dabei auch im Wiki. Teile wurden bereits auf Deutsch übersetzt. | Das Zend Framework hat eine sehr umfangreiche Dokumentation die zum Teil auch auf Deutsch erhältlich ist. Man sollte dabei aber schon wissen, wonach man sucht. Ansonsten hilft noch der „Quick Start Guide“. | Auch CakePHP hat eine umfangreiche Dokumentation. Jedoch ist sie nicht so schön strukturiert und beinhaltet auch nicht immer viel mehr als die API Dokumentation. Das Cookbook ist auch auf Deutsch erhältlich. |
| Konfiguration | Ein Verzeichnis beinhaltet mehrere Konfigurationsdateien auf PHP Basis. Weitere Dateien können sehr einfach angesprochen werden. | Das Zend Framework kennt nur eine einfache application.ini in der einige grundlegende Einstellungen abgelegt werden. Weitere Dateien können jedoch über die Zend_Config_* angesprochen werden. |
CakePHP nutzt eine Konfigurations-Klasse im Gegensatz zu den einfachen PHP Arrays von CI. |
| Anzeige | Codeigniter verwendet PHP Dateien zur Anzeige. Weiters bietet es einen Template Parser und auch die Einbindung von zum Beispiel Smarty ist problemlos möglich. | Zend verwendet auch einfaches PHP zur Anzeige, nutzt jedoch eine spezielle Layout Klasse (optional). Jedoch kann man auch z.B. Smarty als Template Engine integrieren. | CakePHP verwendet einen relativ fixen Layout Ansatz mit einigen Automatismen. Weiters nutzt es CakePHP Temples (.ctp). Die Verwendung von Smarty ist möglich, jedoch aufwendig und eher unüblich. |
| Datenbank | CI bietet standardmäßig eine Abstraktion für unterschiedliche RDBMS (MySQL, PostgreSQL, Mssql, SQLite, Oracle als auch ODBC) und eine Active Record Klasse. Wenn man statt CRUD lieber ORM nutzen möchte kann man dazu z.B. IgnitedRecord verwenden. Daraus ergibt sich eine hohe Flexibilität. |
Zend_Db unterstützt PDO für IBM DB2, MySQL, Mssql, Oracle, PostgreSQL und SQLite als auch Firebird und andere RDBMS ohne PDO Unterstützung. ORM wird z.B. über Table Data Gateways unterstützt. | CakePHP unterstützt IBM DB2, Firebird, Mssql, MySQL, Oracle, PostgreSQL, SQLite, Sybase als auch AdoDB und ODBC. CakePHP verwendet Associations (Beziehungen) zwischen Models (z.B. hasMany) um daraus Datenbank- abfragen zu erstellen. Um dies zu ermöglichen müssen jedoch einige Konventionen eingehalten werden. |
Wenn Ihr nun Lust auf CodeIgniter bekommen habt – Ein Artikel über das Entwickeln mit CI folgt in Kürze!
Ich freue mich schon auf Kommentare von Nutzern anderer Frameworks.
Ja, CI wollte ich mir immer nochmal genauer ansehen. Verdammt, ich finde für sowas keine Zeit… 😀
In der Vergleichstabelle ist die dritte Spalte falsch bezeichnet. Es handelt sich doch offensichtlich um CakePHP?
Kleiner Fehler:
Beim Vergleich hast du:
CodeIgniter Zend Framework CodeIgniter
Das 3. sollte wohl cakephp sein;)
Habe mir gerade dieses Wochenende ein paar Tuts zu CI angeschaut und bin recht angetan.
Ich denke ich werde auf das Framework „einsteigen“ und weg kommen von alles selber schreiben 😉
Verstehe ich das richtig, dass CI ein eigenes ORM bereitstellt?
Der Nachteil von CodeIgniter: Die längst überflüssige PHP4-Kompatibilität führt zu Konstruktionen wie $this->load->model(‚modelname‘) zum Instanzieren von Objekten. Das ist weder OO-technisch elegant noch wirklich praktisch zum Entwickeln: Die Code Completion funktioniert nicht mehr.
Ansonsten ist die Dokumentation wirklich exzellent.
(Um ersteres Problem zu beheben, wurde CodeIgniter vor einiger Zeit geforkt: Daraus ist Kohana entstanden, welches bis heute unter mangelhafter Dokumentation leidet…)
Wirklisch schicker einblick in CodeIgniter. Ich kanndeine begeisterung für CI verstehen. Ich habe vor kurzem ein Miniprojekt auf Basis von CI erstellt. Ich war wirklich Übberrascht wie schnell und einfach das geht.
Aber ich finde eine Objektivere schreibweisewürde deinem Eintrag besser stehen. Es liest sich größtenteilswie: CI ist tollund macht alles besser als du. Und das könnte leser abschrecken.
Trotzdem: CI doppelplusgut
@Christian: Active Records, aber kein ORM.
Mit Datamapper Overzealous gibt’s ein integrierbares Modul.
Ansonsten kannst du natürlich auch die standalone ORM-Systeme wie Doctrine oder Propel integrieren.
Ja, da ist beim umkopieren wohl etwas falsch gelaufen. Jetzt steht da auch CakePHP.
Zu Christians Frage. CI selbst bietet kein ORM, es gibt jedoch einige ORM Libraries für CI.
IgnitedRecord ist dabei wohl die bekannteste. Ich hatte aber selber noch nie die Möglichkeit ORM zu verwenden – Immer bestehende Datenstrukturen.
Aus den Artikel kann ich jetzt beim besten Willen kein Alleinstellungsmerkmal erkennen. Du hättest lieber „Anzeige“ drüber schreiben sollen …
Zwei kleine Korrekturen dann doch noch
@Vergleich:
Zeile Installation: Beim ZF muss kein Projekt mit dem CLI-Tool angelegt werden, für die meisten gilt solch ein Tool auch eher als Erleichterung. Was die Größe eines Framework mit dessen (Un)Fähigkeit zu tun hat, bleibt hier wohl dein Geheimnis, zumal bekanntlich 80% aller PHP-Dateien aus Kommentare und Docblocks besteht. Im 20MB-Paket ist zudem noch Dokumentation (etc) dabei.
Zeile Anzeige: Auch hier gilt, dass ‚Layout‘ überhaupt nicht verwendet werden muss.
@KingCrunch
Das mit Layout hab ich bei ZF eh auch angemerkt. „Jedoch kann man auch…“ – werde das noch etwas deutlicher machen.
Zur Größe. Nun ja, manch einen mag es interessieren, anderen ist es vollkommen egal. Hängt wohl immer davon ab, wie viele Projekte man verwaltet und ob man dabei z.B. eine vernünftige Internetverbindung hat. Und das dabei häufig Dokumentation dabei ist, ist auch klar und auch angemerkt.
Man kann ZF auch ohne die Shell konfigurieren. Dauert zwar etwas länger geht aber auch. Desweiteren muss man auch keine application.ini haben. Das kann man auch durch PHP lösen.
Das was mich davon abhält ein anderes Framework zu benutzten ist einfach die Community dahinter. So ist es bei Zend einfach sicher, dass es das Produkt auch noch in fünf Jahren geben wird, da Zend ja im direkten Kontakt zu PHP steht und auch die Engiene entwickelt hat.
Das sind für mich Gründe, CI oder auch Cake nicht zu nutzen.
Die Vorteile von CodeIgniter seh ich jetzt nicht so. Benchmarks kann man nicht trauen, PHP4 Support seh ich ganz klar als Nachteil und der Rest passt auch auf das ZF, wobei es da noch ein paar m,ehr Anlaufstellen gibt, wenn man die Community braucht zur Problemlösung 🙂
Ein Vorteil von CodeIngiter wäre z.B. die geringe Einarbeitungszeit aufgrund der kleineren EInstiegshürde. Das ZF kann man ohne vernünftige OOP Kenntnisse nicht wirklich verwenden …
und was sind die Nachteile von CI?
Sorry, aber nach dem Satz „Unterstützung von PHP 4“ brauch ich doch gar nicht mehr weiterlesen? Brüsten wir uns neuerdings damit, dass unsere Frontends auch mit dem IE6 zu benutzen sind? -.-
Und man sollte nicht vergessen, dass es für das relativ junge CI bereits mit Kohana einen ersten Fork gibt. So etwas kann problematisch werden, da dadurch Ressourcen auf mehrere Projekte verteilt werden. Und es spricht für eine Uneinigkeit in der CI Community.
Ansonsten bin ich der Meinung, dass jeder mit dem Framework glücklich werden soll, dass ihm oder ihr am besten liegt.
wie schauts denn im vergleich zu symfony aus? ich hab dieses vor kurzem für mich entdeckt und fand es sehr gut.
Zitat: „Jedoch kann man auch Smarty als Template Engine integrieren.“
Man kann jedes Template-System einbinden. Nur auf Smarty reduzieren ist nicht richtig.
Ralf Eggert: „Ansonsten bin ich der Meinung, dass jeder mit dem Framework glücklich werden soll, dass ihm oder ihr am besten liegt.“
Genau so ist es!
Ich finde CI richtig interessant. Zwar hab ich es seit ich mit ZF unterwegs bin nicht mal mehr schräg angeschaut, fand es aber „damals“ sehr toll. Vor allem ist es als Einsteigerframework nur zu empfehlen, da sehr leicht zu lernen und verstehen. Dinge wie MVC und Bootstraping werden einem sehr einfach nahe gebracht.
Kurze Anmerkung zu Kohana und Fork:
Kohana ist wohl rein auf Grund der Tatsache, der doch recht schwachen Dokumentation und inneren Streitigkeiten (Die dürften sich wohl nun auch noch teilen) nicht als ganz so wichtig zu sehen. Junges CI – Nun ja, 2006 halte ich als nicht ganz so jung.
PHP 4:
Ich persönlich sehe das auch nicht zwangsweise als Vorteil, aber manche nutzen das wohl. Erwähnen sollte man es meiner Meinung nach aber schon.
Zu Symfony kann ich leider nichts weiter sagen. Die Infos hier, habe ich selbst im Rahmen einer Evaluierung vor etwa einem Jahr zusammengetragen.
@juhu ich denke die nachteile sind ganz klar, dass die libs „nur“ auf das wesentliche ausgerichtet sind, wobei beim ZF beispielsweise oft die eierlegende Wollmichlsau gebaut wurde – siehe zum Beispiel Zend_Date (was jetzt nicht als schlecht anzusehen ist.). Wenn ich nen „leichtgewichtiges“ Framework suche sind so Sachen wie CI oder aber auch yiiFramework interessant. Man sollte sich aber eher von Projekt zu Projekt entscheiden, so halte ich das in der Regel…
Beste Grüße
Stefan Riede
Ja, sehe es genauso wie Stefan.
Es kommt doch auf die „Benötigten Features“ und Projektgröße an.
Mein 1. Framework war CI dank der guten Dokumentation und den Möglichkeiten und hat mir eine gute Wissensbasis in Richtung MVC & Frameworks beschärt.
Mittlerweile sind „wir“ auf das CakePHP für kleinere Projekte und ZF für Größere Projekte umgestiegen.
Method chaining als ein besonderes Feature eines Frameworks hervorzuheben finde ich höchst zweifelhaft. Das geht mit allen möglichen Programmiersprachen und Frameworks. Die Frage ist nur, ob es, wie in dem genannten Beispiel, zur Lesbarkeit beiträgt.
Das oben gezeigte ist ein sinnvolles Beispiel. Aber häufig sehe ich auch gern mal eine extra Zeile Code im Sinne der Lesbarkeit (und ggf. bequemeres Handling im Debugger).
@kim Method chaining war hier nicht als besonderes Feature gedacht, sondern als Beispiel für Funktionalität die auch in Version 1.x von CI mit Hilfe von PHP 5 gelöst wurden.
Benutzen sollte man es klarerweise nur bei kurzen Statements.
Leutz, das Argument „dahinter steckt ’ne grosse Community“ ist durchaus ok, nur ist es in die gleiche Kategorie wie „das ist Tradition“ oder „warum etwas Neues lernen?“ einzustufen.
Alles hat mal mit einem oder zwei Entwicklern angefangen, auch sowas wie der Moloch Google. Und wer nicht stets lernt, wird dumm.
Und was ist übrigens an Uneinigkeit oder Forks schlimm? Daraus ensteht oft auch etwas besseres, gibt es da nicht etliche Beispiele in anderen Bereichen?
Leider ist es eine Art Bequemlichkeit geworden, auch im Net stets das Bekannte und Massenkompatible zu bevorzugen, der Mainstream ist immer im Recht…
Aktuell benutze ich ein superschlankes MVC Framework für ein Projekt, an dem nur eine Person arbeitet. Das Konzept überzeugt aber ganz einfach und die Person ist sehr kompetent und hilfreich. Wenn man auch kleinen, neuen und anderen Ansätzen keine Chance gibt, dann muss man am Ende mit einem Monopolisten leben. Und das ist der sichere Tod.
Was will ich nun eigentlich sagen?
Nun, das es nicht unbedingt auf die Bekanntheit oder die Größe der Community ankommt, auch nicht auf die Dokumentation oder analfixierte Einhaltung von irgendwelchen Coding styles, sondern darauf, sich für ein sein oder ein spezielles Problem auch mal andere Ansätze anzuschauen und seinen Horizont zu erweitern. Und für dieses eine Problem die richtige Lösung finden. Damit kann man zwar auch baden gehen aber ebenso auch neue Planeten besiedeln.
Alles andere ist Bequemlichkeit und Engstirnigkeit.
But you know „No pain, no gain“…
Yo!
@ChristianK
„(…) und [CodeIgniter] bietet auch die Möglichkeit bei der Erstellung von Datenbankabfragen per active record die Methoden zu verketten (…)“
Vielleicht bin ich ja kleinkariert, aber ein weniger erfahrener Programmierer könnte das vielleicht falsch verstehen. Ich finde, das liest sich schon verwirrend.
@kim Das gehört noch zum „CI selbst nutzt unter PHP 5 zum Beispiel…“. Wie auch immer. War nicht als besonderes Feature gedacht.
@Don:
Grundsätzlich muss ich dir natürlich recht geben. Wenn sich jeder nur den größten anschließt und nur das macht, erhält man weniger Erfahrung und lernt somit auch weniger.
Allerdings ist es eben so, dass man eben auch referenzieren sollte, ob es sich rentiert ein Tool zu benutzen, dass noch nicht sicher im Markt steht.
Mit CI habe ich mich vor ca. 1.5 Jahren intensiver beschäftigt und 3 Projekte damit umgesetzt. Es ist schnell und hat eine exzellente Dokumentation, allerdings muss man viel von Hand bauen und ORM war damals auch noch im Bastelstadium.
Deswegen bin ich dann zu CakePHP gewechselt, was mir mit dem Prinzip „Konvention über Konfiguration“ mehr zusagte.
Da aber im Herbst 2009 der Lead Dev. das Projekt verliess, PHP 4.x Unterstützung nach wie vor eine grosse Rolle im 1.x Branch spielt und Cake teilweise richtig lahm ist (200-500 ms (!!!) Renderzeit ohne DB Abfrage bei einem leerem Projekt, CI bleibt leer unter 100 ms), stellte sich mir die Frage, ob es sinnvoll ist, weiter Zeit mit CakePHP zu verbringen.
Kurzum: Nachdem ich serverseitig die technische Basis gut im Griff hatte, bin ich nun bei Ruby und Rails gelandet. Ruby hat halt noch den Vorteil, dass man es genauso wie Perl gut auf OS-Systemebene einsetzen kann. Und als Sprache ist es ganz interessant.
Es gibt sicher Dinge wo das ZF seine Berechtigung hat. Dinge die länger leben, Dinge die größer werden sollen, Dinge die von vielen gewartet werden. Wenn man aber nur eine kleine Webseite oder ein kleines Gästebuch oder whatever schreiben mag oder einfach erstmal in die Sprache PHP einsteigen möchte, da ist das CI deutlich besser. ZF ist wie schon geschrieben oft mit Kanonen auf Spatzen geschossen. Der Vorteil des CI ist, dass es viele Helper-Funktionen mitbringt und das es auch von Einsteigern schnell durchdrungen werden kann.
Wenn man in den Enterpricebereich geht sieht das ganze wie gesagt natürlich ganz anders aus!
Ich bin ein bißchen überrascht, dass manche Leute mehrere Frameworks für verschiedene Projekte einsetzen! Wieso? Wenn ich in einem Framework richtig gut bin und damit mehrere Projekte / Problemstellungen gelöst habe, dann kann ich dies doch für zukünftige Sachen viel besser verwenden (vor allem wirtschaftlich gesehen).
Sicherlich mag das ZF nicht für jedes kleine Projekt sinnvoll sein, wenn ich aber Ahnung davon habe, dann stelle ich mir doch lieber einen leistungstärkeren Server hin als mich einem Monat in ein neues Framework einzuarbeiten. Dazu muss ich dann bei zwei (oder mehr) Framework up-to-date bleiben.
Versteht mich nicht falsch, den Blick über den Tellerrand erachte ich als absolut sinnvoll, aber (Fach-)Experte in mehreren Framework zu werden halte ich für ungünstig. Ich glaube die Fokussierung auf bestimmte Themengebiete ist noch viel zu gering im PHP-Bereich. Man will immer alles machen (sowohl von den Framework als auch Tools sowie JS, CSS, HTML usw.), was mit dem heutigen PHP doch gar nicht möglich und auch notwendig ist.
Ja, du hast schon recht mit der Fokusierung, aber nicht ein jeder (Kunde zB) hat einen eigenen Server.
@juhu Also bis jetzt sind mir 2 Sachen als Negativ aufgefallen:
1. Code Completion funktioniert nur, wenn man zusätzlich noch zum Beispiel: @property CI_Loader $load im Controller angibt.
2. Die Datenbank Klasse erlaubt nicht immer alle Abfragen per Active Record zu erstellen. Dann kann man entweder auf normale SQL Abfragen ausweichen, oder muss die Methoden direkt im Core hinzufügen. Es gibt noch keine offizielle Möglichkeit die Datenbankklasse zu erweitern. (In der Richtung wird sich wohl in der 2er Version noch etwas tun)
@Kaiuwe Ich habe Smarty einfach mal als Test für eine mögliche Einbindung anderer Templatesysteme gewählt. Habe den Text aber noch angepasst, damit man erkennt, dass Smarty nur ein Beispiel ist.
Ich hatte mir auch mal CodeIgniter angeschaut. Anfangs ganz toll, allerdings finde ich es ein wenig beschränkt, wenn man etwas größeres machen will.
Ich wurde dann auf Kohana (dem Fork von CI) aufmerksam. Gefällt mir viel besser, allerdings lässt die Dokumentation zu wünschen übrig. Vor allem von Kohana v3. 😀
Reicht allerdings für Kleinigkeiten. Und im IRC kriegt man auch schnell Hilfe.
Ansonsten bevorzuge ich immer noch das Zend Framework für größere Projekte.
CodeIgniter:
Nimm PHP 4.3.2 oder irgendwas anders.
Benutze templates oder nicht.
Tu so als seist du ein bisschen ORM oder scher dich nicht drum.
Nimm MVC als Architekturmuster oder lass es.
Ich kenne CI nicht aber: _Was soll das?_
@Ulf
Weil es vielleicht auch Projekte abseits von einfachen Redaktionssystemen für den Kurzwarenhandel oder Kochrezeptverwaltungen gibt?
Weil es auch um Performance, Verteilung, Mobile Apps, NoSql, Legacy-Systeme und -KnowHow, usw usw geht?
Ich benutze nicht immer denselben Schraubenzieher für jede Schraube, abgesehen von Kreuz und Schlitz brauche ich auch manchmal mehr Drehmoment oder ein feineres Werkzeug.
@ragtek
Natürlich hat nicht jeder Kunde / jeses Projekt einen eigenen / performanten Webserver, aber die High-End-Webseite mit tausenden von Funktionen zu programmieren benötigt nun auch mal ein bißchen Server-Load. Und wirtschaftlich ist es fast immer am Sinnvollsten den Server zu upgraden als die Applikation umzuprogrammieren. Wenn ich entscheiden müsste zwischen neues Framework lernen vs. neuer Server würde ich aber ganz klar den neuen Server bevorzugen, weil es deutlich günstiger ist. Auch über die Zeit!
@Don
Ich baue aber auch nicht jedes Mal das Haus neu, nur weil ich eine Schraube wechsele. 😉 Ansonsten habe ich ja geschrieben, dass Weiterbildung verdammt wichtig (und motivierend!) ist, aber das beinhaltet für mich nicht unbedingt das Erlernen eines neuen Frameworks. Wenn ein Kunde bsw. ein neues CMS nutzen möchte, setze ich doch auch nicht erst die über 100 vorhandenen CMS auf sondern vertraue auf eine von mir bekannte Lösung. Und wenn der Kunde unbedingt CMS xy nutzen möchte, aber ich keine Ahnung habe, dann ist es eben auch mal sinnvoll das Projekt /den Kunden abzugeben, dass meinte ich z.B. mit Fokusierung.
@Mathias: Grins, wir reden hier von PHP (Globale Variablen, liberale Scopes…). Du musst gar nichts, wenn du nichts willst.
Frameworks sind dazu da, dir dein Leben zu erleichtern. Wenn du dich nicht drauf einlässt, dann stehen dir die meisten Frameworks auch nicht im Weg.
Hi!
Ich nutzte CI jetzt schon seit einiger Zeit und bin sehr zufrieden damit.
Was mich nur stört ist der PHP4 „Stil“, ich hoffe, dass sich die Entwickler für die Version 2.0 dazu entscheiden, ganz auf die PHP4 Kompatibilität zu verzichten.
Ansonsten ist CI sehr schlank, schnell, benötigt kaum Einarbeitungszeit und bietet einem doch alles, was man braucht.
Eins kann ich nach drei Tagen „PHP Summit“ aber noch sagen, man kann alles nutzten, nur bitte nicht CakePHP! ;o)
Grüße,
Jacka
Why not cakePHP?
@christian
ActiveRecord IST eine ORM-Implementierung, demzufolge bietet CI eine eigene Lösung dafür.
@Marc Binder
Wenn du nur Investitionsschutz im Sinne hast steig auf Java um -> das wird es auch in 25 Jahren noch geben.
@Dennis Becker
Ohne solide OO-Kenntnisse sollte man sich mit Frameworks nicht auseinander setzen, da man ansonsten nur „frickelt“
@ragtek
Deine Frameworkauswahl versteh ich nicht wirklich… Wieso ein zweites, kleineres Framework für kleine Projekte verwenden? ZF stemmt kleine UND große! Du duplizierst andernfalls die Komplexität in deinen Projekten…
Mein Tipp: Schaut euch RoR an um zum einen Ruby als moderne Sprache kennen zu lernen (PHP fehlen in dieser Hinsicht viele Dinge => Elegante Closures, Mixins, syntaktische traumhafte Konsistenz) und zum andern RoR als Beispiel dafür wie man durch die Verwendung einer schlanken DSL-Syntax jedes andere Framework an Produktivät um das doppelte übertrifft.
Ich persönlich empfinde PHP inzwischen eigentlich als Frickelsprache, die an einen „dirty hack“ auf Compilerebene erinnert – die hässliche und inkonsistente Syntax ist ja nur die Spitze des Eisbergs… wenn ich meinen Code auf Compilerebene im Griff habe, kann ich neue Features auch elegant und konsistent implementieren -> scheint bei PHP nicht ganz so zu klappen.
Desweiteren gibt es kein eigenes Konzept, es werden nur die hübschen Features anderer Sprachen nachgebaut, erst das OO-Modell von Java, jetzt Closures aus Ruby/Python… bald Mixins aus Ruby/Scala…
Ich kann mir die Beliebtheit von PHP eigentlich nicht erklären, ganz ehrlich!
Hey, das CMS ist ja geil! Hab gar nicht gewusst das es so was auch für gibt.
@ragtek
Langsam, hoher Speicherverbrauch, Unit-Test untauglich, etc…
Die Herren von der thePHP.cc haben am Montag auf dem PHP-Summit eine Code-Review zu cakePHP durchgeführt und kein gutes Haar daran gelassen.
Das war schon regelrecht ein „Running Gag“ der den ganzen Workshop mitlief.
Ich selbst habe es nie ausprobiert, eigene Erfahrungen habe ich daher nicht.
Die Jungs sagen aber ganz klar: Finger weg!
@Tom Myer
Warum liest du dann einen Blog zu PHP, wenn du PHP für überflüssig hältst?
@Jacka
ich halte php nicht für überflüssig! ich verdiene selbst geld damit – inzwischen aber mehr in kürzerer zeit und mit besserer laune mir ror. jedoch finde ich es angebracht mal darauf aufmerksam zu machen wie sich php eigentlich im vergleich mit anderen technologien schlägt. viele (php-)programmierer halten an ihrer technologie/sprache fest und kommen, was den allgemeinen überblick angeht nicht vom fleck. meinen erfahrungen nach will man nach 30 minuten ror nicht mehr zu php/zend/…
grund dafür ist u.a. ruby: eine programmiersprache wie sie sein sollte – für menschen gemacht und nicht für maschinen! es sei denn du hast einen compilter im kopf…
@Tom: Das ist ein Prozess, den du offenbar auch durchmachen musstest. Nicht jeder, der beginnt zu programmieren, kann gleich mit OO und ORM und Codegeneration und XML und und und… anfangen.
Deshalb ist PHP auch so populär: Man fängt ganz gemütlich mit prozeduralem Programmieren an, schnappt sich ein Framework, lernt OO damit.
Frag mal all bei den Ruby-Leuten rum, womit die begonnen haben.
@christian
Deine Aussage hat sicher was wahres, gar keine Frage! Ich glaube aber auch dass PHP ein Überbleibsel ist, was die Vor-Web2.0-Ära angeht, da gabs ja nur java/php/perl. Steht die kommende Generation vor der Wahl zwischen PHP Ruby würde es mich wundern wenn nicht Ruby das rennen macht!
Ich war auch lange Zeit auf der suche nach einem geeigneten Framework. Zend ist zwar immer noch das non-plus-ultra, allerdings finde CodeIgniter einfach klasse, da es einfach zu lernen ist und außerdem einem nicht den oder auch seinen Standard aufdrängen möchte. Jeder Jeck is anders!
Gruß Roger
Sorry, that I m in english speaking here. but anyway,what could I say – CodeIgniter is the best framework in my opinion.