CodeIgniter – das Leichtgewicht unter den PHP-Frameworks
CodeIgniter gilt als Web-Application-Framework für Entwickler, die Geschwindigkeit einem üppigen Funktionsumfang vorziehen. Zentrales Design-Ziel des quelloffenen PHP-Frameworks ist es der offiziellen Projektseite zufolge, ein Maximum an Performance und Flexibilität im kleinstmöglichen Programmgerüst unterzubringen.
Was ist CodeIgniter?
Bei CodeIgniter handelt es sich um ein in PHP geschriebenes Webframework, das sich damit rühmt, die Entwicklung von Webanwendungen durch ein kompaktes Software-Design schneller und effizienter zu gestalten. Schöpfer von CodeIgniter ist die US-amerikanische Software-Firma EllisLab, die im Februar 2006 die erste öffentliche Version herausgab. Am 9. Juli 2013 kündigte EllisLab an, die nötigen Ressourcen für eine Weiterentwicklung der Software allein nicht mehr aufbringen zu können. Ein Jahr später erfolgte die Übernahme des Projekts durch das British Columbia Institute of Technology (BCIT). Der Quellcode des Frameworks steht unter der MIT-Lizenz und kann über den Onlinedienst GitHub bezogen werden. Als letzte stabile Version wird CodeIgniter 3.1.2 seit Oktober 2016 auf der offiziellen Projektseite kostenlos zum Download angeboten.
Aufbau und Struktur des Frameworks
Das Performance-orientierte Design von CodeIgniter zeigt sich im schlanken Aufbau des PHP-Frameworks. Dieses orientiert sich am Software-Architekturmuster Model-View-Controller (MVC). Das Grundprinzip hinter MVC ist die strikte Trennung von Programmcode und Präsentation. Diese wird durch einen modularen Software-Aufbau und die Auslagereng von PHP-Code realisiert. Man unterscheidet drei zentrale Komponenten: das Datenmodell (Model), die Präsentation (View) und die Steuerung (Controller).
- Das Datenmodell (Model) repräsentiert die Datenstruktur einer auf Basis von CodeIgniter entwickelten Webanwendung. Dazu werden im Quellcode sogenannte Modellklassen („model classes“) definiert. Diese beinhalten spezielle Funktionen, mit denen Informationen aus einer Datenbank abgerufen, in dieser hinterlegt oder aktualisiert werden können.
- Die Präsentation (View) ist der Teil einer Anwendung, der dem Endnutzer präsentiert wird. In der Regel handelt es sich dabei um ein HTML-Dokument, in das Inhalte via PHP dynamisch eingebunden werden. Ein View ist somit eine Art Template. CodeIgniter bietet zudem die Möglichkeit, Webpage-Fragmente wie Header und Footer oder RSS-Seiten als View zu definieren. In der Regel nutzen Webanwendungen mehrere Views, die Ihre Inhalte über dasselbe Datenmodell beziehen. So lassen sich unterschiedliche Programm-Features in verschiedenen Ansichten präsentieren.
- Die Steuerung (Controller) dient als vermittelnde Instanz zwischen Model, View und jeder anderen Ressource, die benötigt wird, um eine HTTP-Anfrage zu bearbeiten oder eine Webpage dynamisch zu erzeugen. Diese Komponente nimmt eingehende Anfragen entgegen, validiert den Input, sucht den gewünschten View heraus und reicht Inhalte, die das Datenmodell aus einer Datenbank geladen hat, an diesen weiter.
Folgende Grafik zeigt das Zusammenspiel der MVC-Komponenten in einer schematischen Darstellung:
Die MVC-Struktur ermöglicht ein flexibles Software-Design, bei dem einzelne Programm-Module mit minimalem Aufwand ausgetauscht, überarbeitet und wiederverwendet werden können. Änderungen an einer Komponente haben in der Regel keine Auswirkung auf den Quellcode anderer Komponenten (vorausgesetzt es werden keine Änderungen an den Schnittstellen vorgenommen).
Die strikte Trennung zwischen Programmlogik und Präsentation sorgt für einen übersichtlichen, gut strukturierten Programmcode. Webapplikationen auf MVC-Basis gelten als wartungsfreundlich. Im Fehlerfall beschränkt sich die Suche nach der Fehlerquelle meist auf eine der Komponenten.
Darüber hinaus bietet das MVC-Architekturmuster die Möglichkeit, Logik und Layout einer Webanwendung separat zu entwickelt. Arbeiten Back-End- und Front-End-Entwickler dabei parallel, lassen sich Anwendungen deutlich schneller fertigstellen.
CodeIgniter macht sich MVC zunutze, bindet Anwender jedoch nicht komplett an dieses Architekturmuster. Während es sich bei den Komponenten Controller und View um obligatorische Bestandteile handelt, sind Verbindungen zu Datenbanken via Model optional. Darüber hinaus lässt sich eine Anwendung auf Basis von CodeIgniter auch mit einer Hierarchical-MVC-Architektur (HMVC) realisieren, die das klassische MVC-Muster um eine hierarchische Logik erweitert.
Der Anwendungsfluss des PHP-Frameworks
CodeIgniter basiert auf einem URL-Konzept. Das bedeutet, der Controller als zentrale Steuereinheit zwischen View und Model wird durch die Eingabe einer URL in die Suchleiste des Webbrowsers angesprochen. Entwickler erstellen dazu sogenannte Controller-Klassen (classes). Dabei handelt es sich um PHP-Dateien, die diverse Funktionen beinhalten, um Bibliotheken (libraries), Erweiterungen (plugins) oder Helfer-Klassen (helper) zu laden, Verbindungen zu Datenbanken herzustellen, ein Datenmodell einzubinden oder einen bestimmten View herauszusuchen.
Der Anwendungsfluss von CodeIgniter basiert dabei auf folgendem URL-Grundschema:
example.com/class/function/parameter
Auf die Domain (example.com) folgt eine Controller-Klasse, die angesprochen werden soll, sowie eine bestimmte Controller-Funktion. Den Abschluss bilden optionale Parameter. Diese dienen dazu, dem ausgewählten Controller IDs oder Variablen zu übergeben.
In der Praxis könnte eine CodeIgniter-URL wie folgt aussehen:
example.com/news/article/511
Eine solche URL spricht den Controller news auf der Domain example.com an und veranlasst diesen, die Funktion article auszuführen (beispielsweise, um einen gleichnamigen View für die Artikelansicht zu laden). Welche Inhalte über das Datenmodell aus der Datenbank abgerufen werden sollen, geben optionale Parameter an, die dem Controller mit der URL übergeben werden – in diesem Beispiel ein Artikel mit der ID 511.
In der Ausgangskonfiguration führt CodeIgniter die index.php in jeder Anwendungs-URL auf:
example.com/index.php/news/article/511
Diese PHP-Datei beinhaltet Informationen darüber, wo sich die Core-Dateien des Frameworks sowie eingebundene Bibliotheken, Erweiterungen oder Helfer-Klassen befinden und in welchem Verzeichnis die Applikationsdateien liegen. Die index.php dient somit der Initialisierung sämtlicher Basisressourcen.
Läuft CodeIgniter auf einem Apache HTTP Server, lässt sich die index.php via mod_rewrite aus den Anwendungs-URLs entfernen, um Endnutzern und Suchmaschinen-Crawlern „saubere“ Webadressen zur Verfügung zu stellen. Entwickler fügen dazu folgenden Codeblock in die .htaccess-Datei des Webservers ein:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]Die Grundstruktur des PHP-Frameworks stützt sich in erster Linie auf Controller-Klassen, Modell-Klassen und View-Templates.
Controller-Klassen
CodeIgniter bietet Entwicklern die Möglichkeit, individuelle Controller als benutzerdefinierte Klassen zu programmieren. Dazu legen Webentwickler für jeden Controller eine separate PHP-Datei im Verzeichnis application/controllers/ an. Controller enthalten die Programmlogik einer mit CodeIgniter entwickelten Webanwendung und werden als Unterklassen der CI_Controller class erstellt. Im Quellcode realisieren Programmierer dies mithilfe des Schlüsselworts extends.
class News extends CI_Controller {
}Als untergeordnete Klasse erbt News von der Elternklasse CI_Controller sämtliche Funktionen der Sichtbarkeit public und protected.
Die Schlüsselwörter public, protected oder private dienen in PHP dazu, die Sichtbarkeit einer Eigenschaft oder Funktion zu definieren. Wird ein Element als public deklariert, haben alle Klassen einer Software Zugriff auf das Element. Soll dieser Zugriff auf Elternklassen und abgeleitete Klassen beschränkt werden, verwenden Programmierer das Schlüsselwort protected. Ein Element, das als private deklariert wurde, steht lediglich der Klasse zur Verfügung, die das Element definiert.
Jede benutzerdefinierte Controller-Klasse muss zudem eine Konstruktor-Funktion enthalten, mit der sich Bibliotheken, ein Datenmodell, Datenbanken oder Helfer-Klassen einbinden lassen. Ab PHP5 wird __construct() als standardisierte Konstruktor-Funktion verwendet.
<?php
class News extends CI_Controller {
public function __construct() { //definiert den Konstruktor
parent::__construct(); //ruft den Konstruktor der übergeordneten Klasse ab
$this->load->helper('url'); //lädt eine Helfer-Klasse für die Arbeit mit URLs
$this->load->helper('file'); //lädt eine Helfer-Klasse für die Arbeit mit Dateien
$this->load->database(); //lädt eine Datenbank
$this->load->model('News_model'); //lädt ein Model mit dem Namen „News_model“
}
?>Das Beispiel zeigt die Klasse News als Unterklasse von CI_Controller. Die Konstruktor-Funktion __construct() bindet zwei Helfer-Klassen, eine Datenbank und das Datenmodell News_model ein. Die einzelnen Codezeilen sind im Quelltext auskommentiert.
Alle Controller-Klassen, die in PHP für CodeIgniter definiert werden, müssen mit einem Großbuchstaben beginnen (News statt news). In der URL schreibt man sie hingegen klein.
Controller-Funktionen
Steht das Grundgerüst des benutzerdefinierten Controllers, folgt die eigentliche Programmlogik in Form von Controller-Funktionen, mit denen sich Views abrufen oder Interaktionen mit einem eingebundenen Datenmodell realisieren lassen.
Damit der Controller einen View laden kann, muss das zugrundeliegende HTML-Dokument als PHP-Datei im Verzeichnis application/views/ abgelegt werden. Ein einfacher View für eine Artikelansicht könnte beispielsweise so aussehen:
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<title><?php echo $title; ?></title>
</head>
<body >
<h1><?php echo $headline ?></h1>
<p><?php echo $content_body ?></p>
</body>
</html>HTML-Dokumente, die PHP-Code enthalten, müssen als PHP-Dateien gespeichert werden (.php). Nur so lässt sich sicherstellen, dass der PHP-Interpreter des Webservers Skripts ausführt und den PHP-Code nicht lediglich als Text ausgibt.
Um einen View in den Controller zu laden, wird eine benutzerdefinierte Funktion benötigt. Im nachfolgenden Codebeispiel kommt die Funktion article() zum Einsatz, um den View article.php zu laden.
public function article() {
if (!file_exists(application/views/article.php)) {
show_404();
}
$this->load->view('article');
}Der Programmcode liest sich wie folgt: Zunächst prüft CodeIgniter, ob das Verzeichnis application/views/ eine Datei mit dem Namen article.php enthält. Diese Abfrage wird durch das Sprachkonstrukt if und die verneinte (!) Bedingung file exists() realisiert.
Trifft die Bedingung zu und es findet sich keine gleichnamige Datei im entsprechenden Verzeichnis, gibt if den Wert TRUE zurück, und CodeIgniter führt die unter if aufgeführte Funktion show_404() aus. Ein Anwender bekäme in diesem Fall den Hinweis, dass die angefragte Datei nicht existiert. Ist die if-Bedingung jedoch nicht erfüllt und wird !file_exists als FALSE evaluiert, führt CodeIgniter die Funktion $this->load->view('article') aus. Diese dient dazu, die entsprechende Datei als View in die Anwendung zu laden.
Sofern es sich um das Format PHP handelt, kann die gewünschte Datei in der Funktion view() ohne Suffix aufgeführt werden. Sollen andere Formate geladen werden, ist das jeweilige Dateisuffix obligatorisch.
CodeIgniter kommt in der Regel im Rahmen dynamischer Webanwendungen zum Einsatz. Diese spielen Anwendern statt statischer HTML-Seiten dynamisch erzeugte Webpages aus. Dies lässt sich realisieren, indem man den View mit Daten füllt, die den Parametern entsprechen, die CodeIgniter mit der URL übergeben bekommt.
example.com/news/article/511
Bisher wurde mit der Funktion $this->load->view('article') lediglich eine Ansicht für die Artikeldarstellung geladen. Nun gilt es, speziell die Inhalte einzubinden, die mit dem Parameter 511 verknüpft sind. Wir gehen davon aus, dass sich dabei um eine ID handelt, die mithilfe eines Datenbank-Management-Systems mit einem bestimmten Newsartikel verbunden ist. Um diesen aus der Datenbank ins Programm zu laden, muss das obenstehende Beispiel so ergänzt werden, dass das im Konstruktor eingebundene Datenmodell angesprochen wird.
public function article($id) {
if (!file_exists(application/views/article.php)) {
show_404();
}
$data = $this->News_model->get_data($id);
$this->load->view('article', $data);}Das übergebene Funktionsargument (hier unter dem Variablennamen $id) entspricht dem ID-Teil der URL – beispielsweise 511. Die noch zu schreibende Modell-Funktion get_data() dient dazu, den mit der ID verknüpften Artikelinhalt aus der Datenbank zu laden. Die view()-Methode ruft den article-View auf und übergibt ihm diese Daten in Form eines assoziativen Arrays ($data). Das Datenmodell News_model übergibt also die ausgelesenen Daten dem Controller News, der diese an den View weiterreicht.
Alle mit dem Datenabruf verbundenen Operationen werden an das eingebundene Datenmodell ausgelagert.
Modell-Klassen
Datenmodelle kommen bei CodeIgniter zum Einsatz, um Funktionen bereitzustellen, mit denen sich bestimmte Datenbank-Operationen durchführen lassen. Genau wie Controller-Klassen lassen sich auch Modell-Klassen mit dem PHP-Framework benutzerdefiniert programmieren.
Um eine Modell-Klasse anzulegen, wird zunächst ein Klassenname vergeben – in diesem Fall News_model. Analog zu Controller-Klassen sind alle benutzerdefinierten Modell-Klassen Unterklassen der Elternklasse CI_Model. Die Vererbung wird durch das Schlüsselwort extends realisiert. Auch Modell-Klassen binden Datenbanken und andere Ressourcen über die Konstruktor-Funktion ein.
class News_model extends CI_Model {
public function __construct() {
parent::__construct();
$this->load->database();
}
}Auf diese Grundstruktur folgen sogenannte Modell-Funktionen, in denen Entwickler alle Datenbank-Operationen definieren, die dem Controller über das jeweilige Datenmodell zur Verfügung stehen sollen.
Modell-Funktionen
Modell-Klassen ermöglichen es Entwicklern, individuelle Funktionen für Datenbank-Operationen zu definieren. In einem vorhergehenden Beispiel haben wir in der Controller-Klasse News die benutzerdefinierte Funktion get_data() verwendet, um Artikelinhalte aus der Datenbank in den View zu laden. Im Modell definieren wir nun, welche Datenbank-Operationen sich hinter dieser Funktion verbergen.
class News_model extends CI_Model {
public function __construct() {
parent::__construct();
$this->load->database();
}
public function get_data($id) {
$this->db->select('content');
$this->db->from('example_table');
$this->db->where('id', $id);
$query = $this->db->get();
return $query->result();
}In der Modellklasse News_model wird die oben benutzte Funktion get_data() als Datenbank-Operation definiert, die die unter select() angegebene Spalte des Datensatzes mit der übergebenen ID-Nummer ($id) aus der unter from() angegebenen Datenbanktabelle via get() abfragt und mithilfe der Funktion result() als Array zurückgibt. Ein Datenmodell stellt in der Regel eine Vielzahl an Modell-Funktionen bereit. Entwickler können dabei auf die Klasse Query Builder zurückgreifen, die eine Reihe vordefinierter Funktionen für klassische Datenbank-Operationen umfasst. Einen Überblick finden Sie in der offiziellen Dokumentation des CodeIgniter Frameworks.
Routing mit CodeIgniter
Welche Controller-Klasse und -Funktion angesprochen werden sollen, wird CodeIgniter mit einer URL vorgegeben. Das Webframework nutzt dafür die URL-Struktur Klasse/Funktion/Parameter. Dieses Grundschema lässt sich bei Bedarf anpassen. CodeIgniter stellt dazu die Datei routes.php im Verzeichnis application/config/ zur Verfügung. Diese enthält ein Array namens $route, das es Entwicklern ermöglicht, eigene Routing-Kriterien zu definieren.
In der Ausgangskonfiguration finden sich im Array $route drei Default-Einträge: der Standard-Controller, eine Routing-Regel für das 404-Override sowie eine Regel für das automatische Ersetzen von Bindestrichen (-) durch Unterstriche (_).
$route['default_controller'] = 'home/welcome';
$route['404_override'] = 'home/welcome';
$route['translate_uri_dashes'] = FALSE;Der erste Default-Eintrag bestimmt den Standard-Controller der Anwendung. Dieser wird von CodeIgniter immer dann geladen, wenn eine URL außer der Domain keine weiteren Routing-Informationen enthält. Im aktuellen Beispiel definiert die Routing-Regel die Controller-Klasse home als Standard-Controller. Besucher, die in der URL keine Angaben zur Ziel-Webpage machen, werden somit auf home umgeleitet und bekommen den View welcome präsentiert. Üblich ist eine Umleitung auf die Startseite. Wurde kein Controller als Standard definiert, zeigt CodeIgniter beim Aufruf der Startseite eine 404-Fehlerseite an.
Der zweite Default-Eintrag im $route-Array definiert einen Controller, der immer dann aufgerufen wird, wenn der durch die URL angesprochene Controller in den Applikationsdateien nicht gefunden wurde. Die Routing-Regel $route['404_override'] = 'home' überschreibt die 404-Fehlerseite, die in einem solchen Fall normalerweise ausgespielt wird, und leitet stattdessen auf die Controller-Klasse home um.
Der dritte Default-Eintrag im $route-Array verhindert Routing-Fehler aufgrund von Bindestrichen. Der Bindestrich ist kein valides Zeichen für Klassen- oder Funktionsnamen und wird daher bereits in der Standardeistellung in URLs automatisch ersetzt.
Soll eine benutzerdefinierte Routing-Regel für eine dynamische URL erstellt werden, stehen Webentwicklern mit CodeIgniter zwei Möglichkeiten zur Verfügung: Routing-Einträge für dynamische URLs lassen sich mit Wildcards (Platzhalter) oder mit regulären Ausdrücken definieren.
Die routes.php unterstützt zwei Arten von Platzhaltern:
Webseiten mit einer großen Anzahl an 404-Fehlerseiten sind schlecht zu crawlen und erschweren Suchmaschinen den Zugriff auf relevante Inhalte. Dies kann – neben den Auswirkungen auf die User-Experience – einen negativen Einfluss auf das Ranking in der Suchmaschine haben. In der Regel sind Webentwickler daher bemüht, 404-Fehlerseiten zu vermeiden.
| Wildcards der routes.php | Beschreibung |
|---|---|
| :num | Fungiert als Platzhalter für Integer (Ganzzahlen) |
| :any | Fungiert als Platzhalter für einen String (Zeichenkette) |
Folgendes Bespiel zeigt einen Eintrag in der routes.php, der es ermöglicht, die Funktion (article) aus der URL zu streichen:
$route['news/article/(:num)'] = 'news/$1';Durch den Platzhalter :num wird der Parameter einer dynamischen URL ausgelesen und in der Variablen $1 gespeichert. Sofern Sie Routing-Regeln mit :num oder :any definieren, müssen Sie diese in der routes.php in einfache Klammern setzen.
Die routes.php akzeptiert zudem Routing-Regeln in Form von regulären Ausdrücken. Die beiden Platzhalter-Typen lassen sich somit auch folgendermaßen notieren:
:num entspricht \d+
:any entspricht [^/]+Eine Alternative zum obenstehenden Beispiel wäre somit folgende Schreibweise:
$route['news/article/(\d+ )'] = 'news/$1';Auch reguläre Ausdrücke werden in der routes.php eingeklammert.
Der Anwendungsfluss im Überblick
Folgende Grafik fasst den Application Flow einer Anwendung auf Basis von CodeIgniter in sieben Schritten zusammen:
1. Die index.php dient CodeIgniter als Front-Controller für eingehende HTTP-Requests. Hier werden alle Basisressourcen initialisiert, die benötigt werden, um die Anwendung auszuführen.
2. Im Rahmen des Routings prüft CodeIgniter, welche Aktion ausgeführt werden soll. Dazu gleicht die Anwendung die URL in der Anfrage mit den in der routes.php definierten Routing-Regeln ab.
3. Auf das Routing folgt das Caching. Findet sich eine zum Request passende Antwort im Cache der Anwendung, wird diese direkt an den anfragenden Webbrowser ausgeliefert. Andernfalls wird der während des Routings ermittelte Controller mit vorgeschalteter Filterfunktion ausgeführt.
4. Das CodeIgniter-Framework beinhaltet einen integrierten Filter, der schädliche Anfragen abfängt. Bevor die Anwendung einen zur Anfrage passenden Controller lädt, wird jeder HTTP-Request einem Sicherheitscheck unterzogen.
5. Passiert die Anfrage den Filter, wird der Controller ausgeführt. Dieser wählt einen passenden View aus und lädt das Datenmodell sowie alle Bibliotheken, Helfer-Klassen, Erweiterungen und Skripte, die benötigt werden, um die Anfrage zu beantworten.
6. Sobald dem View alle relevanten Daten übergeben wurden, kann dieser an den Webbrowser ausgeliefert werden.
7. Ist ein Caching aktiviert, hält CodeIgniter ausgehende Daten temporär vor, um sich wiederholende Abfragen direkt beantworten zu können.
Vorteile des CodeIgniter Frameworks
Mit mehr als 13.000 Sternen ist CodeIgniter ein viel beachtetes GitHub-Entwicklungsprojekt und auf Platz 3 der beliebtesten PHP-Frameworks. Doch wie jede Software hat CodeIgniter sowohl Vor- als auch Nachteile. Diese gilt es gegeneinander abzuwägen, bevor Sie sich als Webentwickler für das schlanke PHP-Framework entscheiden. Dies sind die Vorteile der Anwendung:
- Geringer Konfigurationsaufwand: CodeIgniter bietet einen schnellen Einstieg. Nutzer brauchen sich nicht lange mit der Konfiguration des Frameworks aufhalten, sondern können nahezu unmittelbar nach der Installation mit der Entwicklung der geplanten Anwendung beginnen. Der Konfigurationsaufwand beschränkt sich im Wesentlichen auf die Einstellungen in der config.php im Verzeichnis application/config/. Anwender definieren hier einen Standardpfad für den Zugriff per Webbrowser, einen Schlüssel für die Verschlüsselung, einen Namen für den Session-Cookie und Einstellungen zum Cross-Site-Scripting (XSS). Zudem empfiehlt es sich, eine .htaccess-Datei anzulegen, um die index.php via RewriteRule aus dem Pfad der Anwendungs-URLs zu entfernen. Darüber hinaus ist eine Konfigurationen der Datenbank-Verbindung notwendig, die Sie in die Datei database.php eintragen.
- Small Footprint: CodeIgniter hinterlässt nur einen kleinen Fußabdruck im System. Das Download-Paket des Frameworks umfasst rund 11 MB. Mehr als 9 MB entfallen dabei auf die ausführliche Dokumentation der Software. Der geringe Codeumfang kommt dadurch zustande, dass das CodeIgniter-Basissystem lediglich ein paar kleine Bibliotheken umfasst. Zusätzliche Ressourcen lassen sich bei Bedarf laden.
- Sehr gute Performance: Das schlanke Basissystem führt dazu, dass CodeIgniter im Vergleich zu anderen PHP-Frameworks mit einer hohen Geschwindigkeit punkten kann. Gelobt wurde diese u. a. vom PHP-Erfinder Rasmus Lerdorf. Dieser verkündete 2008 auf der Free and Open Source Conference (FrOSCon), dass ihm CodeIgniter gefalle, da es schneller, leichtgewichtiger und weniger wie ein Framework sei („because it is faster, lighter and the least like a framework“).
- „Saubere“ URLs: CodeIgniter generiert automatisch nutzerfreundliche, suchmaschinengeeigneteURLs. Statt den Zugriff auf dynamische Webinhalte wie andere PHP-Frameworks durch Query Strings zu realisieren, setzt CodeIgniter auf einen segmentbasierten Ansatz.
URL mit Query String: example.com?controller=news&function=article&id=511
Segmentbasierte URL: example.com/news/article/511.
- Freier Programmierstil: CodeIgniter basiert auf einer freien Interpretation des MVC-Architekturmusters. Entwicklern ist somit kein Programmierstil vorgegeben.
- Umfangreiche Dokumentation: CodeIgniter verfügt über eine ausführliche Dokumentation in englischer Sprache inklusive Einsteiger-Tutorial. Zudem ist der Quellcode übersichtlich und gut kommentiert. Die CodeIgniter-Dokumentation steht auf der Projekt-Website als Onlineguide und Download-Version zur Verfügung.
- Community-Support: Entwickler, die Anwendungen auf Basis von CodeIgniter entwickeln, können sich auf die Hilfe anderer Nutzer stützen. Das Projekt wird von einer aktiven Community begleitet. Ein öffentliches Forum wird unter https://forum.codeigniter.com angeboten. Aktuell tauschen sich dort mehr als 7.300 Anwender in rund 65.000 Threads über den Einsatz und die Weiterentwicklung des Frameworks aus.
Nachteile des CodeIgniter-Frameworks
Da die Entwicklung des CodeIgniter-Frameworks vor der Übernahme durch das BCIT zeitweise stagnierte, suchen Entwickler einige technologische Entwicklungen, die von vergleichbaren Frameworks in den vergangenen Jahren adaptiert wurden, bei CodeIgniter vergeblich.
- ORM nur über Drittanbieter: Unter objektrelationaler Abbildung („object-relational mapping“, ORM) versteht man eine Technik der Software-Entwicklung, die es Anwendungen ermöglicht, in einer objektorientierten Programmiersprache wie PHP geschriebene Objekte in einer relationalen Datenbank abzulegen. CodeIgniter unterstützt ORM nicht nativ. Die Technik kann jedoch durch Drittanbieter eingebunden werden.
- Keine Template-Engine: CodeIgniter rühmt sich damit, ohne Template-Engine auszukommen. Stattdessen stellt das Framework optional einen einfachen Template-Parser zur Verfügung. Dies kann als Vorteil angesehen werden. Der Einsatz einer Template-Engine ist in der Regel mit einem Performance-Overhead (Zusatzaufwand zur Laufzeit) verbunden. Darüber hinaus muss zusätzlich zum Framework auch der Gebrauch der Template-Sprache erlernt werden. Andererseits erlaubt es eine Template-Engine, die Datengenerierung vom Code für die Präsentation zu separieren, und führt so in der Regel zu einem übersichtlich strukturierten Quellcode. Kommt eine Template-Engine mit schlanker Syntax zum Einsatz, kann dies den Gesamtumfang des Application-Codes deutlich reduzieren.
- Kein Namespacing: Mit Namespaces bietet PHP die Möglichkeit, Code verschiedener Anwendungsgruppen zu trennen. PHP-Entwickler machen sich dieses Feature zunutze, um Konflikte zu vermeiden, die bei der Benennung von Klassen und Funktionen auftreten. Gängig sind beispielsweise Namenskollisionen mit internen PHP-Klassen, -Funktionen, -Konstanten oder -Elementen, die von Drittanbietern eingebunden werden. CodeIgniter nutzt dieses PHP-Feature bislang nicht.
- Kein PHP-Auto-Loading: Seit Version 5 bietet PHP mit __autoload() und spl_autoload_register() zwei Funktionen, die es ermöglichen, Klassendefinitionen bei Bedarf automatisch zu laden. Im CodeIgniter-Framework steht dieses Feature nicht zur Verfügung.
- Weniger Built-in-Bibliotheken als andere PHP-Frameworks: Aufgrund des schlanken Software-Designs bietet CodeIgniter in der Ausgangskonfiguration deutlich weniger Bibliotheken als andere PHP-Frameworks. Diese umfassen in erste Linie die wichtigsten Aufgaben der Webentwicklung wie Datenbankzugriffe, E-Mail-Versand, die Validierung von Formulardaten, das Aufrechterhalten von Sessions oder die Arbeit mit XML-RPC. Für Aufgaben, die über die Basis-Features hinausgehen, müssen eigene Bibliotheken oder Ressourcen von Drittanbietern eingebunden werden. Ein Punkt, den Entwicklern, die ein auf das Minimum reduziertes Framework suchen, auch als Vorteil interpretieren können.
CodeIgniter für den eiligen Leser
Nachstehende Tabelle zeigt die Eckdaten des CodeIgniter-Frameworks in der Übersicht:
| CodeIgniter | |
|---|---|
| Entwickler | British Columbia Institute of Technology (BCIT) |
| Aktuelles Release | Version 3.1.2 |
| Design-Muster | MVC/HMVC, Active Record, Chain of Responsibility |
| Benötigte Kenntnisse | PHP, Objektorientierte Programmierung (OOP) |
| Programmiersprache | PHP 5.6 oder höher |
| Lizenz | MIT-Lizenz |
| Datenbankunterstützung | MySQL (5.1+), Oracle, PostgreSQL, MS SQL, SQLite, CUBRID, Interbase/Firebird, ODBC |
| ORM | Nur über Drittanbieter |
| Caching | ja |
| Template-Engine | nein |
| Namespaces | nein |
| PHP-Auto-Loading | nein |
| Suchmaschinenfreundliche URLs | nein |
| Sicherheits-Features | Cross-Site-Request-Forgery (XSRF), Cross-Site-Scripting (XSS), SQL-Injection |
| Testing-Library | PHP Unit |
Mit seinem kompakten Design und der einsteigerfreundlichen Syntax eignet sich CodeIgniter vor allem für angehende Programmierer. Wer bereits erste Erfahrungen mit der dynamischen Webentwicklung auf Basis von PHP gemacht hat, wird sich auch in das PHP-basierte Lightweight-Framework in kürzester Zeit einarbeiten. Und auch erfahrende Webentwickler schätzen die Flexibilität, die ihnen ein auf Grundfunktionalitäten reduziertes PHP-Framework einräumt.
Wer CodeIgniter nutzen möchte, sollte sich jedoch mit dem MVC-Architekturmuster anfreunden und auf eine Template-Engine sowie natives ORM verzichten können. Trotz minimalem Codeumfang eignet sich CodeIgniter gleichermaßen für kleine und große Webprojekte.