Quicknavi |
|
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
http://codeigniter.de/{Controlle}/{Action}[/{Param}]/../{ParamN}]
an die zentrale Datei index.php weiterleitet. Die erstellte .htaccess-Datei hat
folgenden Inhalt:
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:
class Layout {
var $obj; var $layout;
function Layout($layout) { $this->obj =& get_instance(); $this->layout = $layout; }
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
<td width="180" height="400" valign="top" class="menu">
<?php echo $content_for_menu; ?>
</td>
als auch ein
<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:
$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.
class Seite extends Controller {
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'); }
function index(){ $this->Startseite(); }
function Startseite(){ echo $this->layout->view('demosite/content/startseite'); }
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:
function index(){
// Action-Parameter holen $Action = $this->uri->segment(2);
if(!method_exists($this,$Action)){
// Action-Methode ausführen $this->{$Action}();
// end if } else{
if(file_exists('system/application/views/demosite/content/'.strtolower($Action).'.php')){
// View rendern $this->_output($this->layout->view('views/demosite/content/'.strtolower($Action));
// end if } else{
// Zur Startseite leiten redirect('Seite');
// end else }
// end else }
// end function }
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:
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);
// end function }
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:
function highlight($content){
// Quelltext parsen return preg_replace_callback('=\<php\:highlight\>(.*?)\<\/php\:highlight\>=si','highlight_it',$content);
// end function }
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>';
// end function }
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:
<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:
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));
// end else } else{ $this->_output($this->layout->view('demosite/content/kontakt_success','content_for_layout',$data)); // end else }
// end function }
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
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
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:
$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.
|