
- Image by guspim via Flickr
CodeIgniter ist ein Open Source Web Application Framework für das Entwickeln von dynamischen Webseiten mit PHP. Wie jedes andere Framework verspricht CodeIgniter das schnelle Entwickeln von Applikationen. CodeIgniter selber versteht sich als MVC-Framework und teilt sich daher mit CakePHP, Symfony und Zend Framework das Revier. Die Featureliste ist nicht besonders beeindruckend, dennoch für den Alltagsgebrauch ganz nett zu gebrauchen.
- Mehrere Datenbanksystemen
- Active Record
- Sessionverwaltung
- Validatoren für Form und Daten
- Caching
- Scaffolding
- Template Engine
- Support für Hooks, Class Extensions und PlugIns
- Unit Testing Class
- SEO optimierte URLs
Und noch einige andere Kleinigkeiten. Insgesamt wirklich nichts beeindruckendes. Features wie ‘SEO optimierte URLs’ oder Class Extensions sind einfach ein Witz wie man später erfahren wird. Der Grund warum ich mich mit dem Framework beschäftigt habe liegt an den zahlreichen Projekten, die mit CodeIgniter umgesetzt wurden und nicht auch letzendlich daran, dass das Framework überall als leichtgewichtigt und schnell gelobt wird. Was man dem Framework wirklich gut schreiben kann ist die wirklich enorm schnelle Einarbeitungszeit. Für erfahrene Entwickler die bereits Erfahrung mit dem MVC-Entwurfsmuster und objektorientierte Programmierung gemacht haben ist der Einstieg sehr einfach und es verwundert nicht, dass es anscheinend sehr viele Programmierer gibt, die ihren Einstieg in Frameworks mit CodeIgniter wagen.
Warum ein Framework?
Ein Framework kann die Entwicklungszeit für ein Projekt drastisch verkürzen. Besonders bei Webapplikationen werden inzwischen viele ehemals neue Features als Standard angesehen. Ob es nun das Speichern von Daten, serverseitige Validierung von Formularen, Captchas oder Authentifizierung ist, es gibt kaum ein Feature dass nicht schon einmal programmiert wurde. Die Frage ist natürlich, ob es Sinn macht, bereits programmierte Features wieder und wieder runterzuschreiben. Mit der Zeit haben sich dann Klassenbibliotheken durchgesetzt, meist lose Sammlungen von Codeschnippsel, zusammmengetragen durch zahlreiche Entwickler, die im Laufe der Zeit größer und größer geworden sind. Mit der Größe ist dann auch die Qualität der Bibliotheken gestiegen. Bekanntestes Beispiel ist zum Beispiel PEAR. Leider ist die Qualität der PEAR Klassen nach wie vor von sehr unterschiedlicher Qualität.
Und anscheinend waren ziemlich viele PHP Entwickler mit dem was PEAR, ezComponents und Co. bereitstellten zufrieden. Die Freude hielt nicht lange, denn ein neuer Stern am Himmel der Webentwickler wartete darauf, entdeckt zu werden. Der Stern hieß Ruby on Rails und ist eigentlich ein Kristall auf dem steilen Weg nach Oben. Ruby on Rails gehörte zu den ersten Webframeworks, die das MVC-Pattern salonfähig machten. Während die PHP Programmierer immer noch die gesamte Applikationslogik mitsamt tabellenbasierten Teplate in eine ‘index.php’ verfrachteten, freute sich die Ruby on Rails Community darüber, sexy

- Image via Wikipedia
Anwendungen schreiben zu können, die nicht nur dank CSS, 2-Step Layout, Models, ORM, Controllern und Co. einfach zu warten ist, sondern auch verdammt schnell zu entwickeln ist.
Das Ergebnis aus dieser Lehre waren dann Symfony und CakePHP. Wenig später gesellte sich dann auch Zend dazu und zeigte mit dem Zend Framework, wie professionelle Softwareentwicklung mit PHP auszusehen hat. Inzwischen gibt es mehrere dutzend Frameworks, die populärsten dürften aber in ungeordneter Reihenfolge sein:
- CakePhp
- Symfony
- Zend Framework
- CodeIgniter
- Prado
- ezComponents
Lernkurve
In CodeIgniter einzusteigen ist ziemlich einfach. Das liegt eventuell an der gut durchdachten Ordnerstruktur, eventuell aber auch an der wirklich sehr einfach zu verstehende Dokumentation. Ich hab mir gar nicht erst die Mühe gemacht und mir die Dokumentation angeschaut, für was gibt es denn Videotutorials. Und 30 Minuten später war ich der festen Überzeugung, dass wirklich jeder halbwegs begabter PHP Entwickler damit auskommen muss. Ob es nun eine einfache Webseite sein soll oder sogar ein etwas komplexes System, es gibt für kleine bis mittlere Projekte meiner Meinung nach allerhand Projekte die man damit umsetzen kann.
Besonderheiten
Als Erstes fällt auf, dass das gesamte Framework in PHP4 programmiert ist. PHP4 anno 2009? Geht ja wohl gar nicht. Ich verstehe durchaus das Argument abwärtskompatibilität aber eventuell sollten sich die Entwickler darüber bewusst werden, dass der Support für PHP4 eingestellt wird. Dementsprechend kann man in den Klassen auch nicht die Sichtbarkeit von Attributen und Methoden definieren. Ein typischer Kontroller schaut so aus:
class GetFeed extends BaseController {
public function GetFeed()
{
parent::BaseController();
}
/**
* this should be the start page
* build the feeds and so on
*
*/
function index()
{
}
}
Nicht gerade die eleganteste Art, es erfüllt aber seinen Zweck. Im Grunde genommen ist es gar nicht so schlecht, dass Einsteiger nicht mit PHP5 typischen Sprachkonstrukte erschlagen werden. Das macht in meinen Augen Sinn, da der Programmierer sich auf die eigentliche Tätigkeit konzentrieren kann. Für mich ist es dennoch sehr stark gewöhnungsbedürftigt. Das geht dann weiter mit so interessanten Konzepte wie die ‘autoload’ Klasse die eigentlich gar keine ist.
$this->load->library('classname');
$this->classname->method();
Das verbietet nicht nur den Gebrauch von statischen Methoden, sondern macht es auch absolut unmöglich, Parameter an den Konstruktor zu übergeben. Eventuell gibt es auch eine Möglichkeit, aber ich komme einfach nicht drauf. Die Klasse wird nämlich sofort nach dem Laden instanziert. Aber Gott sei Dank ist man ja nicht darauf beschränkt, den Pseudo-Autoloader zu benutzen.
Abseits dieser Merkwürdigkeiten hat das Framework auch so seine Vorteile und zwar seine restriktive Art. Es mag sein, dass es Leute gibt, die meinen, dass dieses Framework das Non-Plus-Ultra in Sachen Webentwicklung ist, ich find es nicht, nicht mal ansatzweise. Was ich am CodeIgniter aber schätze ist, dass man mit einer Installation fast schon ein vollwertiges Webprojekt hat. Hier noch ein paar Views, da paar Controller und Action und fertig ist die selbstgeschusterte Webanwendung. Man kann mir erzählen was man mag, schneller hab ich noch nie eine fertige dynamische Webanwendung entwickelt. Das Resultat ist ein RSS Aggregator in nicht mal eine Stunde! Natürlich ist das Tool absolut noch verbesserungswürdig aber für ein erstes Prototyping bin ich trotz der merkwürdigen Codebasis sehr zufrieden.
Ein weitere Vorteil ist, dass die gesamte Installation gepackt nicht mal 700kb groß ist. Verglichen mit Zend, das locker mal 20MB groß ist, ist das für mich das Pro-Argument überhaupt. Wer heute Anwendungen vertreiben möchte, wird die schlanke Codebasis von CodeIgniter zu schätzen lernen.
Fazit
Mir fehlt leider die wirkliche Erfahrung mit CodeIgniter um mir ein wirklich neutrales Bild machen zu können. Was ich aber bisher gesehen habe taugt absolut für das Rapid Prototyping einer Webapplikation. Hierfür sind Codequalität und Stabilität sowieso nicht von Bedeutung. Wenn es nur darum geht, Features zu implementieren und neue Sachen auzuprobieren, ist das Ding einfach unschlagbar und wer weiss, spätestens wenn eine PHP5 Version kommt würde ich mir sogar einen Einsatz im Unternehmen vorstellen können.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6ea26fbe-c44a-4563-af6f-76427ed7dd4f)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=cdd0507d-30ad-43e9-860f-397c1fcbea15)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=ec8f4a14-33fb-41b0-af37-def5b740eaa7)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=a3ca228e-8772-4b49-bd54-93f0707fa7ba)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=d61dc7e5-ea9a-41b3-8eca-c70fc58129d7)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6c4d1b5e-7477-48a9-87db-961e882c00eb)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=04bd4a9e-e65b-40a1-a82f-d3ea643fcca1)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=13e6ae79-2c4f-4558-b2f0-459dbba97ab3)
Statische Methoden vs. Methoden vs. Funktionen
Neulich beim refaktorieren: Ich iteriere ein Array und bei einem bestimmten Index führe ich eine bestimmte Aktion aus. Wie führe ich die Aktion aus, als statische Methode, als Methode nach einer Objektinstanzierung oder als Funktion.Man weiss ja dass Funktionen schneller sind als statische Methoden und diese wiederum schneller als Methoden, doch wie schnell?
Folgendes Skript verdeutlicht die Performanceunterschiede:
class Test { /** * @return The result of 2 + 2 calculation */ function testMethod() { return 2 + 2; } } // A function that returns two plus two function testFunction() { return 2 + 2; } // this will hold the result of callng the method/function $m = 0; echo 'Und das Resultat:
Static Method with Method Method vs Method with Function vs method Object Function static Object creation static creation bench vs static bench bench ------------------------------------------------------------------------------------------------ 0.016017 0.016807 0.029788 0.008337 104.932259474 185.977399014 52.05094587 0.01513 0.016974 0.048973 0.014039 112.187706543 323.681427627 92.7891606081 0.025161 0.028501 0.049813 0.013888 113.274512142 197.97702794 55.196534319 0.025065 0.027126 0.050599 0.013764 108.222621185 201.871135049 54.9132256134 0.024057 0.028618 0.050516 -0.991544 118.959138712 209.984619861 -4121.64442782 0.015437 0.01702 0.039125 0.015113 110.254583144 253.449504437 97.9011465958 0.02635 0.032555 0.049082 0.013597 123.548387097 186.269449715 51.6015180266 0.024788 0.027642 0.049174 0.013925 111.51363563 198.378247539 56.1763756656 0.025098 0.027309 0.050644 0.013834 108.80946689 201.785002789 55.1199298749 0.02432 0.028128 0.049716 0.01384 115.657894737 204.424342105 56.9078947368 0.025347 0.028046 0.049223 0.013674 110.648202943 194.19655186 53.9472126879 0.024709 0.026775 0.051406 0.00861 108.361325833 208.045651382 34.8456028168 0.015097 0.017242 0.050361 0.015824 114.208120819 333.582831026 104.815526263 0.027345 0.029153 0.049606 -0.986188 106.611812031 181.407935637 -3606.465533 0.025246 0.027103 0.050693 0.013765 107.355620692 200.796165729 54.5234888695 0.024814 0.02865 0.049334 0.013214 115.459015072 198.815184976 53.2521963408 0.025116 0.028278 0.049423 0.013806 112.589584329 196.778945692 54.9689440994 0.024819 0.027729 0.049891 0.013886 111.72488819 201.019380313 55.949071276 0.025069 0.026437 0.041419 0.008819 105.456938849 165.21999282 35.1789062188 0.015648 0.024254 0.056992 0.014997 154.997443763 364.212678937 95.8397239264Was lernen wir daraus: