PHP-Frameworks im Test (4)

3.2. CodeIgniter


3.2.1. Allgemeines

Roadmap des Projekts
Auf der Seite http://codeigniter.com/ und den angeschlossenene Seiten findet sich leider keine Roadmap, die über den weiteren Verlauf der Entwicklungen Aufschluss geben könnte. Einzig das Bug-Tracking-System oder das Forum lassen vermuten, welche Features im nächsten Release eingeführt werden.


Aktualität der Version
Die unter http://codeigniter.com/download.php (Download startet sofort) verfügbare Version stammt vom 12.07.2007. Das Release-Datum und die Aktivitäten im Bug-Tracking-System stellen sicher, dass der Code aktuell ist und das Projekt regelmäßig gepflegt wird.


Release-Packages in verschiedenen Formaten
Das Release von CodeIgniter ist nur in einer ZIP-Version verfügbar. Somit ist nicht sichergestellt, dass die Pakete auch auf Nicht-Windows-Betriebssystemen einfach verwendet werden können.


CVS/SVN-Repositories
Für CodeIgniter ist kein öffentliches CVS- oder SVN-Repository zugänglich, über das z.B. "nightly builds" bezogen werden können.


Bug-Tracking / Ticketing
Unter http://codeigniter.com/bug_tracker/ können Bugs berichtet werden. Zudem existiert mit http://codeigniter.com/forums/viewforum/51/ ein Bug-Report- Forum, das sowohl zum Reporting als auch zur Diskussion mit den Entwicklern genutzt wird.


Version für PHP 4
Die installierte Version ist zu PHP 4 (im Test: Version 4.4.6) kompatibel.


Version für PHP 5
Die installierte Version ist zu PHP 5 (im Test: Version 5.2.1) kompatibel.


3.2.2. Installation

Extract & Go
Auch bei CodeIgniter ist keine aufwändige Vorbereitung notwendig. Nach dem Entpacken des Paketes in den Document-Root des zu Test-Zwecken erstellten VHOSTs ist die Demo-Applikation verfügbar. Positiv auffällig ist der grafisch übersichtlich und inhaltlich gut strukturierte User-Guide, der dem Benutzer den Einstieg erleichtert.

Konfiguration
Die notwendigen Konfigurationsarbeiten sind im User-Guide auf der Seite http://codeigniter.com/user_gu...index.html beschrieben. Hauptsächlich geht es dabei um das Setup des absoluten Pfads, in dem CodeIgniter ausgeführt wird und die Datenbank Zugangsdaten. Um das URL-Layout von CodeIgniter nutzen zu können, sind manuelle Anpassungen notwendig. Hierzu wurde eine Apache RewriteRule erstellt, die alle Anfragen der Form
APF-Template
http://codeigniter.de/{Controlle}/{Action}[/{Param}]/../{ParamN}]
an die zentrale Datei index.php weiterleitet. Die erstellte .htaccess-Datei hat folgenden Inhalt:
APF-Template
RewriteEngine On RewriteRule !(index.php|css|jpe?g|png|gif)$ /index.php?%{REQUEST_URI} [NC,L]
(Quelle: http://codeigniter.com/user_gu.../urls.html)


3.2.3. Erste Schritte

Demo-Software
Das PHP-Framework CodeIgniter bringt, ähnlich wie CakePHP, eine Demo-Seite sowie einen Offline-User-Guide mit. Die Einstiegsseite gibt dem Anwender Informationen darüber, wo in das System eingegriffen werden muss um Änderungen an der angezeigten Seite durchzuführen, bzw. wo das Manual zu finden ist. Die Seite bringt jedoch keine Demo-Applikation bzw. -Module mit, die dem Entwickler ein Gefühl für die Funktionsweise geben.

Einführung / Quickstart
Das Manual enthält einige ausführliche Kapitel, über die ersten Schritte. An dieser Stelle sie nochmals auf http://codeigniter.com/user_gu...index.html hingewiesen. Die Seite dient dem CodeIgniter-Anfänger als Einstiegsseite.
Etwas negativ fällt auf, dass der Benutzer direkt nach der Installations-Seite an die Referenz verwiesen wird ohne etwa eine "Hallo Welt!"-Applikation oder ähnliches zwischen zu lagern. Eine "Hallo Welt!"-Applikation findet sich in Form eines Video Tutorials unter http://codeigniter.com/tutorials/watch/intro/ allerdings wird im Manual nicht darauf verwiesen.


3.2.4. Erstellung einer Webseite

Template-Bau / Layoutgestaltung
Die Standard-Seite, die mit dem Release mitgeliefert wird beschreibt bereits, welche Dateien bearbeitet werden müssen um auf die Ausgabe Einfluss nehmen zu können. Nagativ fällt sofort ins Auge, dass CodeIgniter standardmäßig keine Layouts unterstützt, wie dies z.B. CakePHP tut. Um ein zentrales Seiten-Layout einsetzen zu können ist eine Erweiterung der eingesetzten Klassen notwendig. Eine Anleitung dazu kann unter http://codeigniter.com/wiki/layout_library/ gefunden werden. Nach einer erneuten Recherche konnte eine weitere Lösung für das Layout- Thema gefunden werden: YATS, ein erweitertes Template-System für CodeIgniter. Dieses gehört jedoch ebenso wie der Quick-Hack im Wiki nicht zum Standard-Release. YATS kann unter http://codeigniter.com/wiki/Ye...te_System/ heruntergeladen und installiert werden. Postitiv ist zu vermerken, dass das AddOn ein eigenes Support-Forum mitbringt. YATS ersetzt bei der Installation einige der Standard-Bibliotheken von CodeIgniter, was zur Folge hat, dass einige der bisher erstellten Applikationen unter Umständen nicht mehr korrekt ausgeführt werden können.

Für die Untersuchung des Frameworks wurde beim Template-Bau die erweiterte Layout-Library des WIKIs genutzt. Das Erstellen von Templates erfolgt damit einer ähnlichen Vorgehensweise, die bei CakePHP state-of-the-art ist. View-Templates (Endung: .php) werden als PHP-Skripte eingebunden und können beliebigen PHP-Code enthalten. Zunächst wurde unter /system/application/views/demosite eine Layout-Datei mit dem Namen basic_layout.php angelegt um das gemeinsame Layout abbilden zu können. Diese enthält, ebenso wie beim Test des vorangegangenen Probanden die Bereiche für Menü, Top-Menü, News und Content.

Da CodeIgniter auch mit der erweiterten Layout-Library das Handeln von mehr als einem View-Bereich im Layout-Template nicht unterstützt, wurde die Layout-Library wie folgt erweitert:
PHP-Code
class Layout { var $obj; var $layout; public function Layout($layout) { $this->obj =& get_instance(); $this->layout = $layout; } public function view($view, $layoutvar = 'content_for_layout',$data=null, $return=true) { $data[$layoutvar] = $this->obj->load->view($view,$data,true); if($return) { $output = $this->obj->load->view($this->layout,$data, true); return $output; } else { $this->obj->load->view($this->layout,$data, false); } } }
Damit ist es dem Entwickler möglich mehrere Bereiche im zentralen Layout zu definieren und den Inhalt unterschiedlicher Views dynamisch dort zu platzieren. Im Beispiel konnte damit sowohl ein
APF-Template
<td width="180" height="400" valign="top" class="menu"> <?php echo $content_for_menu; ?> </td>
als auch ein
APF-Template
<td height="20" class="topmenu"> <?php echo $content_for_topmenu; ?> </td>
im Template definiert und im zugehörigen Controller gefüllt werden.


Handling von Controllern
Um ein einheitliches URL-Bild erstellen zu können muss auch hier das Routing angepasst werden. Dies erfolgt in der Datei /system/application/config/routes.php. Dort werden u.a. die Default-Route und Benutzer-eigene Routen definiert. Für den Test muss lediglich die Default-Route angepasst und ein Mapping auf den Seite-Controller eingetragen werden:
PHP-Code
$route['default_controller'] = 'Seite'; $route['Seite'] = 'Seite/Startseite';
Der bereits angesprochene Action-Controller implementiert die mitgelieferte Controller-Klasse und steuert die Befüllung der einzelnen Views. Der Konstruktor der Klasse wir dazu genutzt um die o.g. Layout-Library zu laden und die allgemeinen Views (Menü, Top-Menü) mit Daten zu füllen.
PHP-Code
class Seite extends Controller { public function Seite(){ parent::Controller(); $this->load->library('layout','demosite/basic_layout'); $this->layout->view('demosite/menu','content_for_menu'); $this->layout->view('demosite/topmenu','content_for_topmenu'); } public function index(){ $this->Startseite(); } public function Startseite(){ echo $this->layout->view('demosite/content/startseite'); } public function Benchmark(){ echo $this->layout->view('demosite/content/benchmark'); } }
Die Methode index() wird immer dann vom Dispatcher aufgerufen, wenn keine Methode in der URL angegeben ist. Wird eine Methode in der URL angegeben, die nicht im Controller existert wird die etwas unverständliche Meldung angezeigt, dass die aufgerufene Seite nicht auf dem Server existiert (Fehler 404). Die Ursache konnte erst nach einer Zeit der Nachforschung herausgefunden werden. Es ist bei CodeIgniter tatsächlich so, dass jede "virtuelle" Methode der URL auch eine konkrete Implementierung im Controller benötigt. Interessant wäre an dieser Stelle eine Bootstrap-Methode, die alle Aufrufe, in denen lediglich Inhalte per URL-Parameter geladen werden müssen, abfängt. Auf Grund der URL-Struktur kann dies beispielsweise über den URL-Helper in der Methode index() realisiert werden:
PHP-Code
public function index(){ // Action-Parameter holen $Action = $this->uri->segment(2); if(!method_exists($this,$Action)){ // Action-Methode ausführen $this->{$Action}(); } else{ if(file_exists('system/application/views/demosite/content/'.strtolower($Action).'.php')){ // View rendern $this->_output($this->layout->view('views/demosite/content/'.strtolower($Action)); } else{ // Zur Startseite leiten redirect('Seite'); } } }
Um den Test zu komplettieren, wurden - wie bereits im Code des Controllers zu sehen ist - die Seiten Startseite, Benchmark und Formulare mit Inhalten gefüllt.


Erweiterbarkeit der GUI-Komponenten
Im Quellcode der Datei benchmark.php befinden sich neben "normalen" HTML-Tags auch XML-Tags, zwischen den PHP-Codes eingeschlossen sind, der formatiert auf der Seite dargestellt werden sollen. CakePHP und das Adventure PHP Framework bieten dazu generische Tag-Parser bzw. TagLibs, die diese Ausgaben erzeugen. CodeIgniter verfügt zwar ebenso wie CakePHP über Helper-Funktionen, die allerdings nativ keine XML-Tags parsen können. Um dieses Verhalten nachstellen zu können wird die interne Controller-Methode _output() für die Aufgabe des XML-Tag-Parsings modifiziert. Es wurde jedoch davon abgesehen eine generische Implementierung für diese Aufgabe zu wählen, da dies sonst den Rahmen der Evaluierung sprengen würde. Die Bereiche Navigation innerhalb des Dokumentationsbereich wurde nicht als Tag, sondern als zusätzlicher View realisiert, damit die Codierung nicht zu stark vom CodeIgniter-Standard abweicht:
PHP-Code
public function _output($output){ // load helper $this->load->helper('highlight'); // Include Tag parsing // We could go so far to include a generic tag-parser, that can be configured in any // configuration file, but i refrain from doing that. this is just a non generic parser echo highlight($output); }
Um die Funktion des Parsens auszulagern wurde ein Helper programmiert, der das Tag-Parsen über Ersetzung regulärer Such-Strings realisiert. Die Datei /system/application/helpers/highlight_helper.php hat demnach folgenden Inhalt:
PHP-Code
public function highlight($content){ // Quelltext parsen return preg_replace_callback('=\<php\:highlight\>(.*?)\<\/php\:highlight\>=si','highlight_it',$content); } public function highlight_it($content){ $HighlightedContent = highlight_string(trim('<?php'.ltrim(rtrim($content[1]),"\x0A..\x0D").' ?>'),true); // PHP-Anfangstag ersetzen $HighlightedContent = str_replace('< font color="#007700"><?< /font>', '', $HighlightedContent); $HighlightedContent = str_replace('< font color="#0000BB"><?php ', '< font color="#0000BB">', $HighlightedContent); $HighlightedContent = str_replace('< font color="#0000BB">php', '< font color="#0000BB">', $HighlightedContent); $HighlightedContent = str_replace('< font color="#0000BB"> < /font>', '', $HighlightedContent); // PHP-Endtag ersetzen $HighlightedContent = str_replace('< font color="#0000BB">?>< /font>','',$HighlightedContent); // Code im DIV zurückgeben return '< div class="phpcode">'.$HighlightedContent.'< /div>'; }


Komplexe Layouts
Da bereits die Gestaltung einer einfachen Webseite nicht ohne einige Hindernisse möglich ist, sieht der Autor auch bei diesem Framework Schwierigkeiten beim Aufsetzen von komplexen Layouts und verschachtelten Funktionen. Auch bei CodeIgniter konnten Menü und Top-Menü nur als statische Views eingebunden werden. Eine Art "Controller für Views", mit dem weiterer dynamischer HTML-Code generiert werden kann - um beispielsweise ein Menü aus einem Model-Objekt darzustellen - ist nicht vorgesehen.

Auch hier wurde keine weitere Prüfung unternommen, da keine Beschreibungen für eine offizielle Lösung unter den CodeIgniter-Seiten gefunden werden konnte. Ansätze waren unter zu finden. Diese waren jedoch nicht auf das Problem zugeschnitten und eine Evaluierung von Smarty im Zusammenspiel mit CodeIgniter ist nicht Teil der Betrachtungen.


FormularDesign
Zur Erstellung eines Formulars bietet CodeIgniter den FormHelper (http://codeigniter.com/user_gu...elper.html). Um die Vergleichbarkeit zu wahren wird auch hier das bereits unter 3.1.4. beschriebene Formular erstellt. Da das Formular in die bereits bestehende Seite eingebunden werden soll, wird neues View-Template mit dem Namen kontakt.php unter /system/application/views/demosite/content angelegt. Dieses hat den folgenden Inhalt:
APF-Template
<font style="font-size: 26px; font-weight: bold;">Kontakt-Formular</font> <br /> <br /> Wenn Sie mit mir in Kontakt treten möchten, dann benutzen Sie einfach dieses Formular. Geben Sie Ihre Nachricht ein und schon kann es los gehen. Ich werden mich dann umgehend mit Ihnen in Verbindung setzten. <strong>Bitte füllen Sie das Formular vollständig aus!</strong>. <br /> <br /> <?php echo $this->validation->error_string; ?> <?php echo form_open('/Seite/Kontakt'); ?> <span style="width: 47px; border: 0px solid black; margin-right: 69px;">Person:</span> <?php echo form_dropdown('person', array( '' => '', '1' => 'Max Mustermann', '2' => 'Bianka Mustermann' ), null, 'class="eingabe_feld"' ); ?> <br /> <br /> <span style="width: 56x; border: 0px solid black; margin-right: 64px;">Ihr Name:</span> <?php echo form_input(array( 'name' => 'name', 'value' => $this->validation->name, 'class' => 'eingabe_feld', 'style' => 'width: 280px;'.$ContactNameStyle ) ); ?> <?php echo $ContactNameErrorMessage; ?> <br /> <br /> <span style="width: 108px; border: 0px solid black; margin-right: 10px;">Ihre eMail-Adresse:</span> <?php echo form_input(array( 'name' => 'email', 'value' => $this->validation->email, 'class' => 'eingabe_feld', 'style' => 'width: 280px;'.$ContactEMailStyle ) ); ?> <?php echo $ContactEMailErrorMessage; ?> <br /> <br /> <span style="width: 57px; border: 0px solid black; margin-right: 61px;">Ihr Betreff:</span> <?php echo form_input(array( 'name' => 'subject', 'value' => $this->validation->subject, 'class' => 'eingabe_feld', 'style' => 'width: 280px;'.$ContactSubjectStyle ) ); ?> <?php echo $ContactSubjectErrorMessage; ?> <br /> <br /> Ihre Nachricht: <br /> <?php echo form_textarea(array( 'name' => 'note', 'value' => $this->validation->note, 'class' => 'eingabe_feld', 'style' => 'height: 200px; width: 400px; overflow: auto;'.$ContactNoteStyle ) ); ?> <br /> <br /> <?php echo form_submit('Absenden','Absenden','class="eingabe_feld"'); ?> <?php echo form_close(); ?>
Das Template zeigt, dass der Entwickler und Template-Bauer mit dem Form-Helper die Möglichkeit hat Formular-Felder per Helper-Funktionen generieren zu lassen. Hier stehen ihm beispielsweise die Funktionen form_input() oder form_textarea() zur Verfügung. Auch Formular-Tags können automatisch generiert werden.
Im Gegensatz zu CakePHP verfügt das Framework CodeIgniter über eine eingebaute Formular- Validierung mit sehr vielseitigen Einstellungsmöglichkeiten. Der Quellcode der zugehörigen Controller-Methode zeigt die Anwendung:
PHP-Code
public function Kontakt(){ // Libraries und Helper laden $this->load->helper('form'); $this->load->helper('url'); $this->load->library('validation'); // View-Daten vorbereiten $data['ContactNameStyle'] = ''; $data['ContactEMailStyle'] = ''; $data['ContactSubjectStyle'] = ''; $data['ContactNoteStyle'] = ''; // Validierung konfigurieren $rules['person'] = 'required|empty'; $rules['name'] = 'required|min_length[3]'; $rules['email'] = 'required|valid_email'; $rules['subject'] = 'required|min_length[3]'; $rules['note'] = 'required|min_length[5]'; $this->validation->set_rules($rules); // Feldernamen für Validierung bezeichnen $fields['person'] = 'Person'; $fields['name'] = 'Name'; $fields['email'] = 'E-Mail'; $fields['subject'] = 'Betreff'; $fields['note'] = 'Notiz'; $this->validation->set_fields($fields); // Validierung starten if($this->validation->run() == FALSE){ // Falls die Error-Member-Variable gesetzt ist, roten Rahmen zeichnen if($this->validation->name_error){ $data['ContactNameStyle'] = 'border: 2px solid red;'; } if($this->validation->email_error){ $data['ContactEMailStyle'] = 'border: 2px solid red;'; } if($this->validation->subject_error){ $data['ContactSubjectStyle'] = 'border: 2px solid red;'; } if($this->validation->note_error){ $data['ContactNoteStyle'] = 'border: 2px solid red;'; } // View rendern $this->_output($this->layout->view('demosite/content/kontakt','content_for_layout',$data)); } else{ $this->_output($this->layout->view('demosite/content/kontakt_success','content_for_layout',$data)); } }
Im ersten Anweisungsblock werden die Helper und Libraries geladen, die zur Validierung benötigt werden. Der zweite Block definiert einen Satz von Daten, die an den Formular-View übergeben werden sollen um die Formatierung der Felder bei Bedarf um ein weiteres Style-Attribut zu ergänzen. Anschließend wird die Validierung konfiguriert. Wie unter http://codeigniter.com/user_gu...ation.html nachzulesen ist, können beliebig viele Validierungsmethoden kaskadiert und neue vom Anwender programmiert werden. Damit die Ausgabe der Fehlermeldungen zum aktuellen Anwendungsfall passt, wird der Validator-Library im nächsten Schritt bekannt gemacht, wie die Felder-Namen heißen. Diese Definition ist vor allem deshalb wichtig, damit später mit
PHP-Code
if($this->validation->name_error){ $data['ContactNameStyle'] = 'border: 2px solid red;'; }
der zusätzliche CSS-Tag ergänz werden kann um die Felder mit roten Rahmen zu markieren.

Nachteilig an der aufgezeigten Vorgehensweise ist, dass CodeIgniter das Füllen von POST-Werten nicht selbständig bei Verwendung der Form-Helper-Funktionen erledigt, sondern dies zu Fuß über die Validate-Library programmiert werden muss. Auch problematisch sieht der Autor, dass das Presetting von POST-Werten in Select-Feldern nur dann funktioniert, wenn das Select-Feld manuell angelegt wird. Bei Verwendung der Helper-Funktion form_dropdown() gibt es keine generische Möglichkeit dies zu realisieren. Darüber hinaus ist die Validierung von Formular-Feldern zwar unterstützt, jedoch recht umständlich in der Anwendung.

Fazit: Das Formular-Handling ist im Bereich der Validierung dem von CakePHP überlegen, jedoch fehlen in CodeIgniter wiederum einige Features, die in CakePHP Standard sind (Presetting). Vergleicht man nur diese beiden Frameworks, so wäre eine Mischung wünschenswert.



3.2.5. URL-Handling

Unterstützung von URL-Rewriting
URL-Rewriting wird von CodeIgniter nativ unterstützt. Hierzu müssen zwar entsprechende RewriteRules angelegt werden und diese leiten die Anfragen alle an die zentrale Bootstrap-Datei index.php zur Verarbeitung weiter. Ein Betrieb ohne URL-Rewriting ist aber ebenso möglich. Dazu müssen einige Konfigurationseinstellungen in der config.php, die unter http://codeigniter.com/user_gu.../urls.html beschrieben sind, geändert werden.

Generik des URL-Layouts
Das URL-Layout hat zur Zeit der Auslieferung das Format
APF-Template
http://www.example.com/{Controller}/{Action}[/{Param1}/.../{ParamN}]
Über die Routing-Einträge können unterschiedliche URL-Teile als Kenner für bestimmte Aktionen verwendet werden. Das Aufbrechenen des URL-Layouts hinsichtlich der Ausführung mehrerer Controller zur Laufzeit ist jedoch nicht möglich. Die Übergabe von beliebig vielen und beliebig gearteten GET-Parametern ist nur im Non-Rewrite-URL-Moduls möglich und auch nur dann, wenn das globale Zurücksetzen des $_GET-Arrays im Code verhindert wird.


URL-Manipulations-Tools / Linkgenerierung
Zur Generierung von URLs steht der URL-Helper zur Verfügung. Dieser besitzt die unter http://codeigniter.com/user_gu...elper.html beschriebenen Funktionen. Es ist sowohl möglich eine URL mit site_url() oder base_url() zu generieren, als auch mit anchor() einen Anker-Link zu erstellen. Darüber hinaus bietet die URL-Library(http://codeigniter.com/user_gu...s/uri.html) diverse Manipulations-Möglichkeiten einer URL. Herausgegriffen sei an dieser Stelle die Methoden uri_to_assoc und assoc_to_uri(), die zur Manipulation einer URL an Hand eines Array möglich macht. Dies könnte in etwa so aussehen:
PHP-Code
$this->load->library('uri'); $ParamArray = array( 'MyParam1' => 'value1', 'MyParam2' => 'value2' ); $URLParams = $this->uri->uri_to_assoc(10); $URLParams = array_merge($ParamArray,$URL); $URL = $this->uri->assoc_to_uri($URLParams);


3.2.6. Design des Frameworks

Umfang der mitgelieferten Komponenten
CodeIgniter liefert einen großen Umfang an Bibliotheken mit dem Release aus. Hierzu gehören alle Komponenten rund um die MVC-Implementierung und deren Helper, sowie Klassen, die als Basis für GUI-Module dienen wie die Kalender- oder die File-Upload-Klasse. Einzusehen sind die Dokumentationen im User-Guide / Sektion "Class Reference" unter http://codeigniter.com/user_guide. Die Seite http://codeigniter.com/projects/ und das Wiki (http://codeigniter.com/wiki/) sind eine gute Ressource für fertige Applikationen und Artikel mit Code-Beispielen rund um CodeIgniter. Ein netter Ansatz ist der Quick-Reference-Table, der alle Methoden im Überblick zeigt. So hat der Entwickler eine weitere Möglichkeit, sich schnell einen Überblick über die Komponenten und deren Möglichkeiten zu verschaffen. Die Quick-Reference kann auf http://codeigniter.com/user_gu...rence.html im Manual nachgeschlagen werden.
Ein weiterer positiver Punkt ist, dass CodeIgniter eine direkte Unterstützung von Unit-Tests mitbringt. Die Komponente CI_Unit_test kann dazu verwendet werden automatisierte Unit-Tests von CodeIgniter-Applikationen ablaufen zu lassen.


Einsatz von Design-Pattern
Um während der Evaluierung ein besseres Verständnis des Designs des Frameworks zu bekommen wurde mit Hilfe von Doxygen und Dot eine API-Dokumentation generiert. Auffällig ist, dass kein einheitliches Klassen-Modell existiert. Gegenüber CakePHP und dem Adventure PHP Framework basiert nicht jede Klasse auf einer gemeinsamen Basis-Klasse, sondern jede Klasse jedes Unter-Namespaces hat ihre eigene Basis-Klasse. Das Singleton-Pattern wird zudem für einige Klassen jeweils neu implementiert. Ein abstrakter Ansatz wird nicht verfolgt, was dazu führt, dass der Anwender darauf beschränkt ist, nur diejenigen Klassen singleton instanziieren zu können, die das Feature auch unterstützen. Positiv zu bewerten ist jedoch hier, dass ein generischer Benchmarker im Lieferumfang enthalten ist, mit dem beliebige Code-Stellen gemessen werden können. Das Handling des Benchmarkers ist jedoch hinsichtlich der mark()-Methode etwas gewöhnungsbedürftig. Die Ausgabe hingegen ist sehr übersichtlich und erleichtert die Performance-Optimierung.


Struktur des Quellcodes / Design der Klassen
Der Aufbau des Packages ist sehr übersichtlich gestaltet. Die Benennung der Klassen kann jedoch bei der Komponente "Controller" nicht ganz nachvollzogen werden, da es sich offensichtlich um eine Core-Komponente handelt, die jedoch nicht mit "CI_" gepräfixt ist. Die Klassen an sich sind gut dokumentiert, die Klassen-Variablen wurden in die Dokumentation leider nicht einbezogen.


Einsetzbarkeit für mehrere Applikationen
CodeIgniter bringt für die generische Implementierung von Applikationen und Modulen mehrere Komponenten mit: CI_Language und CI_Config. Diese beiden Bibliotheken, und insbesondere CI_Config bringen jedoch keine weitere Abstraktionsebene mit, die unterscheidet, in welchem Umfeld und in welche Applikation ein Modul eingesetzt ist.


Erweiterbarkeit
Der modulare Design-Ansatz ermöglicht es dem engagierten Entwickler die Funktionalitäten des Frameworks beliebig zu erweitern. Durch das nicht durchgängige Klassen-Modell sind Erweiterungen jedoch nicht durch ein Interface definiert und es besteht die Gefahr, dass CodeIgniter durch zu viele Erweiterungen zu einer monolithischen Klassensammlung wie PEAR mutieren könnte. Auch im GUI-Bereich von CodeIgniter stoßen die Entwickler schnell an die Grenzen und müssen auf Erweiterungen oder den Einsatz von Drittprodukten ausweichen.


Scaffolding
Genau wie CakePHP bringt CodeIgniter ein Rapid Development Feature mit, das wie CakePHP Benutzern hilft, Applikationen schnell zu entwickeln. CodeIgniter weißt im Manual jedoch extra darauf hin, dass Scaffolding-Applikationen nicht im Live-Betrieb eingesetzt werden sollten, was die Intension des Rapid Development ein Stück weit relativiert. Das hier betrachtete Beispiel ist ein auf einem auf CodeIgniter aufsetzenden "Framework" basiertes Beispiel. Rapyd besitzt eine eigene Webseite, die die gewüählten Beispiele näher erläutert. Auf http://www.rapyd.com/samples.php/rapyd/samples kann dieses bei Bedarf noch einmal nachvollzogen werden. Die CodeIgniter-Seite selbst geizt mit Anwendungsbeispielen des Scaffolding-Features. Wirklich ausführliche Beispiele finden sich nur auf externen Seiten.


3.2.7. Dokumentation

Dokumentation des Quellcodes
Wie bereits erwähnt ist der Quellcode gut dokumentiert, bei den Klassen-Variablen findet sich jedoch wenig bis keine Dokumentation zur Bedeutung und Verwendung derselben. Durch die übersichtliche Strukturierung des Paketes findet sich der Anwender aber schnell im Quellcode zurecht, sollte der Blick in das Manual nicht ausreichen.


API-Dokumentation
Für CodeIgniter ist weder online noch offline eine API-Dokumentation verfügbar. Zu Evaluationszwecken wurde diese manuell mit Doxygen generiert, ersetzt jedoch nicht die Notwendigkeit, dass diese vom Entwicklungsteam zur Verfügung gestellt wird.


Einführungen, Tutorials und Anwendungs-Beispiele
Die Seiten http://codeigniter.com/user_guide/ und http://codeigniter.com/wiki dienen dem Anwender als Ressourcen für Einführungen, Tutorials und Anwendungsbeispiele. Unter http://codeigniter.com/tutorials/ finden sich 2 Video Tutorials, die ebenfalls den Einstieg erleichtern sollen. Ein Link, der auf eine externe Seite führt, zeigt die Erstellung einer Applikation mit AJAX Features (http://video.derekallard.com/).
Im Vergleich zu den Hinweisen auf Projekte, die bereits auf CodeIgniter aufgesetzt wurden (http://codeigniter.com/projects/) wartet das User-Manual mit relativ wenigen Einführungsbeispielen auf und versteht sich eher als Referenz. Im Wiki finden sich unter http://codeigniter.com/wiki/Special:Categories jedoch viele Kategorien, in denen der Entwickler Anwendungsbeispiele beziehen kann. Abgesehen von der etwas unglücklichen Strukturierung und den nicht ganz als solche zu verstehende Hinweisen auf das Wiki kann von einer guten Auswahl an Dokumentationselementen gesprochen werden.


ChangeLogs / Migrations-Hinweise für API-Änderungen
Eine öffentlich zugängliche Release-Planung scheint kein Feature der CodeIgniter-Webseite zu sein, denn auch in den News ist keine weitere Planung für das Feature-Set des Frameworks zu sehen. ChangeLogs zu den einzelnen Releases finden sich dagegen in den Newseinträgen der jeweiligen Anlkündigungen der neuen Features. Alte Releases sind jedoch nach einem neuen Release nicht mehr zugänglich.



3.2.8. Support
Support erfährt der Entwickler im direkt angeschlossenen Forum (http://codeigniter.com/forums/), per Suche im Wiki, oder in diversen anderen Foren, die sich mit dem Thema PHP-Entwicklung beschäftigen. Das eigene Forum ist gut strukturiert und gliedert sich auf in Foren für Feature-Requests und Support. Bugfixes finden sich zudem auch im WIKI, was schnelle Hilfe verspricht. Eine Newsgroup zu CodeIgniter findet sich unter http://groups.google.de/group/...?lnk=gschg, ein IRC-Channel wurde unter http://codeigniter.com/forums/viewthread/57381/ bekannt gegeben.



3.2.9. Benchmark
Im Benchmark-Test konnte mit den CodeIgniter-eigenen Mitteln eine Rendering-Zeit von durchschnittlich 0.12434 s gemessen werden. Die Rendering-Zeit ist hier die komplette Ausführungszeit ohne Rendering-Zeit für eine Sub-Navigation. Diese wurde aus genannten Gründen nicht implementiert.


» Weiter auf Seite 5 (Bewertung Zend Framework).


Kommentare

Möchten Sie den Artikel eine Anmerkung hinzufügen, oder haben Sie ergänzende Hinweise? Dann können Sie diese hier einfügen. Die bereits verfassten Anmerkungen und Kommentare finden Sie in der untenstehenden Liste.
« 1   »
Einträge/Seite: | 5 | 10 | 15 | 20 |
1
name 23.06.2008, 16:38:27
Die deutschen User tun sich sehr schwer mit der überfüllten Dokumentationen in englisch und es besteht ein extremer Bedarf an deutschsprachigen Seiten bzw. Dokus.