CodeIgniter: meh

Om een of andere reden dacht ik dat CodeIgniter wat beter was dan CakePHP. Cake gaf me altijd de indruk dat ik te maken had met een logge gorilla. Krachtig en indrukwekkend, maar moeilijk in een kooi te stoppen. CodeIgniter daarentegen is een lichtgewicht, snel op zijn voeten en flexibel. Dat is me tot nu toe wat tegengevallen.

CodeIgniter biedt je exact wat je nodig hebt, plus wat extra’s: een heleboel helpers. Maar daar begint het al mank te lopen.

Forms en validatie

Om invoer te valideren bind je velden en de overeenkomstige vereisten aan $this->validation. Zo kan je bijvoorbeeld $_POST['key'] binden aan $this->validation->key. Dat is dan ook doorgaans de waarde die je zou willen zien in je invoerveld met de naam key, maar de form-helper werkt zo niet. Je moet zelf een waarde meegeven.

Soit, met wat extra code los je dat snel op.

Active Record

Active Records: dat ding dat programmeren zoveel gemakkelijker maakt omdat je bijna geen SQL meer moet schrijven. Ruby On Rails dankt er zijn faam aan. Plak er “ORM-mapping” op en je ziet dat dit in Java-land het domein is van Hibernate.

En je vindt het ook terug in CodeIgniter. Alleen worden JOINs niet fatsoenlijk ondersteund. Bummer.

Soit, met wat extra code los je dat snel op door gewoon SQL te gebruiken en wat functies naar een base class te halen die de code die je moet schrijven minimaliseren.

Je kan alle klassen overriden

Behalve de base class voor models. Soit, met een include los je dat snel op.

MVC

Een pure implementatie van het model-view-controller-pattern is bwekes. Ik haat vette klassen. Ik wil geen PHP-file met meer dan 2000 lijnen omdat het daar hoort volgens het gekozen pattern. Ik wil een lichtgewicht model, ik wil enkele functies daaraan koppelen en ik wil een controller die enkel beslist wat er moet gebeuren. Ik heb dus nog iets nodig tussen controller en model. Een business layer. Euh, ja, die zetten we dan maar bij de libraries, hoewel me dat meer iets lijkt voor thirdparty dinges.

Alles onder $this

Dus in de controller laad ik de juiste library, laat die de juiste operaties uitvoeren en bekijk wat ik op basis van het resultaat van die operaties moet doen (”Alles ging goed” of “Euhm… probleempje”).

Dat laden dus, van een library, dat doe je met $this->load->library('NaamVanDeLibrary'). Daarna vind je die library terug onder $this->naamvandelibrary. Model laden? $this->load->model('MijnModel', 'naamvanmodel') en je vindt het terug onder $this->naamvanmodel.

Blergh. Lelijk. Waarom moet dat onder $this zitten? Omdat $this de context is. In een library heb je geen context (het zou idealiter eenrichtingsverkeer zijn), dus moet je eerst een referentie naar de singleton-context halen, het model laden onder die context en je bent er. Not a fan.

Modules

CodeIgniter biedt niet de mogelijkheid om je applicatie te organiseren in modules. Gelukkig is het wel zo flexibel dat gebruikers dit er zelf kunnen inbouwen. Dat gezegd zijnde is het ook flexibel genoeg om er Drupal mee na te maken. Maar wie wil dat nu doen? Right.

Geen $_GET

CodeIgniter vereist dat alle handelingen via $_POST worden verricht. De $_GET-array wordt immers leeggemaakt om veiligheidsredenen. Voor veel voorkomende acties als zoeken zit er dus niets anders op dan de search string te encoderen en te redirecten.

Er zijn workarounds voor natuurlijk. Het is echter niet de bedoeling dat ik een framework altijd moet patchen om het te laten werken zoals ik het wil.

PHP 4

Stop. Het.

Alternatieven

CodeIgniter is niet mijn favoriete framework, maar het is niet barslecht. Het doet de meeste dingen goed tot zeer goed. Maar het kan beter. Misschien wordt Kohana, gebaseerd op CodeIgniter, wel beter - het is in ieder geval al bestemd voor PHP 5 - als de documentatie op punt staat.

CakePHP zit ondertussen nog altijd niet aan versie 1.2 en die zat er een jaar geleden al aan te komen. Symfony blijft steunen op PEAR. Blijft er vooral nog over: Zend Framework. De filosofie staat me alvast enorm aan: take what you need.

Oooooh! Klinkt geweldig.

Dit artikel werd opgenomen in ontwikkeling.


3 reacties

  1. Avatar van Bart Bart 18 Nov 2007 19:58

    Al die frameworks staan precies nog serieus in hun kinderschoenen, niet?

  2. Avatar van Kevin Kevin 18 Nov 2007 20:45

    Volgens mij zijn ze eigenlijk allemaal erg volwassen (behalve Kohana misschien, waaraan nog hard wordt gewerkt). Op een bepaald punt moet je nu eenmaal de knoop doorhakken wat betreft features. Als iedereen wachtte om een framework uit te brengen totdat alle features erin zaten, dan waren we nu nog altijd allemaal zelf wat aan het verzinnen.

    Maar dat zal ik dan toch maar gaan doen op basis van het Zend Framework, vooral omdat het me toelaat om ook niet met MVC te werken (probeer bijvoorbeeld het gebruik van templates eens in een MVC-model te stoppen).

  3. Avatar van -FoX- -FoX- 20 Nov 2007 09:58

    Een gepast framework vinden blijkt toch nog altijd niet zo evident te zijn. Toch valt de keuze aardig mee met PHP. In tegenstelling tot Java, waar je enkel voor het web al meer dan 40 frameworks hebt (gelukkig maar een 15 tal serieuze).

    Ik denk dat Zend hier echt een serieuze speler is, alleen al omdat dit framework gebackupped wordt door een grote speler. Daarnaast is het net de bedoeling van Zend om een gestandardiseerd framework uit te brengen, zodat dit een evidente keuze blijkt.

    Naast de al vermelde frameworks zie ik nog een paar die mogelijk nog iets kunnen betekenen:
    - Seagull (http://seagullproject.org/)
    - Stratos (http://www.stratosframework.com/)
    - Prado (http://www.pradosoft.com/)
    * disclaimer: ik heb geen ervaring met deze frameworks, maar geef ze voor de volledigheid gewoon even mee..

    In het kleine aantal PHP projecten die ik gedaan heb, is er nooit echt een framework aan te pas gekomen. Enkel het Joomla ‘framework’ heb ik overlaatst nog gebruikt om een aantal custom componenten te maken, en op zich werkte dat ook wel aardig.