Christian Renner (ch12r)

Zend Framework – Tutorial 1. Teil – Hello World

Zend Framework - Tutorial 1. Teil - Hello World
Leider ist mein Tutorial nach der Einführung von Zend_Application (ab ZF 1.8) nicht mehr auf dem aktuellen Stand. Das Tutorial basiert auf einer veralteten Version (ZF 1.7). Da ich momentan sehr eingespannt bin, habe ich momentan leider auch nicht die Zeit, die entsprechenden Teile zu aktualisieren. Zudem steht auch schon seit einiger Zeit der Release des ZF 2.0 im Raum, was bestimmt auch noch einige Veränderungen mit sich bringen wird.

Deswegen hier vorerst einmal Linktipps:

Für ein generelles Verständnis halte ich die beiden Teile dennoch nach wie vor geeignet.


Anlässlich eines Projektes, welches ich mit dem Zend Frameworks umsetzen möchte, dachte ich mir, dass ich gleichzeitig meine Ergebnisse im Rahmen eines Tutorials festhalte, da deutsche Tutorials zu diesem Thema rar sind oder zumindest ab einem bestimmten Punkt nicht mehr weiter geführt wurden. Dementsprechend klopfe ich mal auf Holz, dass ich das Ding hier durchziehe 😉

Version und Voraussetzungen

Zum jetzigen Zeitpunkt (Jan ’09) hat das Framework die Version 1.7.2. Zusätzlich zu den Systemvoraussetzungen, sollte auch jeder prüfen, ob der Einsatz eines Frameworks für das jeweilige Projekt gerechtfertigt ist, was folgender Abschnitt versucht herauszustellen.

Wozu ein Framework und warum Zend?

Zunächst möchte ich die Eigenschaften und Vorteile des Frameworks herausgreifen. Mit Hilfe derer sollte jeder noch einmal genau überlegen, ob er der Komplexität des Frameworks gewachsen ist und die daraus entstehenden Vorteile überhaupt benötigt oder nicht. Diejenigen, die sich dessen sicher sind, können diesen Abschnitt getrost überspringen und direkt mit dem Abschnitt “Download & Installation” beginnen. Blutige Anfänger, die bisher noch nie etwas mit PHP oder anderen serverseitigen Skriptsprachen zu tun hatten, sollten sich zunächst durch eines der zahlreich existierenden PHP-Anfänger-Tutorials durcharbeiten. Das wohl bekannteste – mit dem auch meine Wenigkeit vor einigen Jahren begonnen hat – ist wohl das PHP-Tutorial von Quakenet.

Aber nun zu den Vorteilen und Stärken des Zend Frameworks.

Die Stärken des Frameworks liegen grob gesagt in zwei Bereichen. Zum einen erweitert es, wie die meisten Frameworks, die PHP-Standardbibliothek um einen nicht unerheblichen Teil an zusätzlichen Klassen (Caching, Datenbank, Userverwaltung, …) und APIs zu anderen Diensteanbietern (Google, Youtube, …). Auf der anderen Seite bietet es die Möglichkeit mit relativ geringem Aufwand seine Projekte in einer sauberen Architektur (MVC, Webservices) umzusetzen. Letzteres benötigt eine gewisse Einarbeitungszeit in die Systematik, wie das Framework MVC umsetzt. Dies kann auf den ersten Blick mühsam erscheinen, lohnt sich aber, da durch die Architektur automatisch eine Trennung der drei Einheiten Datenmodell, Programmlogik und Präsentation erfolgt. Daraus resultiert, vor allem in großen Projekten mit mehreren Entwicklern und Spezialisten (Datenbankprogrammierer, Webdesigner, …), durch die solide Schnittstellendefinition, eine höhere Stabilität bei Änderungen während der Entwicklungsphase und eine höhere Wartungsfreundlichkeit nach der Auslieferung. Alles in allem wird dadurch die Fehleranfälligkeit reduziert. Durch eine integrierte Testumgebung (Zend_Test) lassen sich zudem sehr schnell Unit-Tests erstellen, wodurch sich das Risiko der Fehlerproduktion beim Refactoring oder bei der Umsetzung von Änderungsanforderung während der Entwicklungsphase reduzieren (C.R.A.P. Index) lässt. Wer sich mehr mit dem Thema “Qualitätssicherung in PHP-Projekten” befassen möchte, empfehle ich den Blog von Sebastian Bergmann (PHPUnit, ezComponents). Für Einsteiger ist eventuell diese Präsentation hiilfreich.

Ein weiterer Vorteil des Zend Frameworks ist die sehr gute Dokumentation. Außerdem erfreut es sich – Open Source sei Dank – einer recht großen und aktiven Community, innerhalb welcher sich auch ein deutschsprachiges Forum etabliert hat.

So viele Möglichkeiten das Framework auch bietet, für die meisten kleinen Projekte, innerhalb derer weder eine Datenbank noch eine Userverwaltung benötigt wird, bringt es einen unvertretbaren Overhead an Speicherplatz und Einrichtungs- bzw. vor allem auch Einarbeitungszeit mit sich. Sobald man sich aber dafür entscheidet ein etwas größeres Projekt umzusetzen, welches eine klar strukturierte Architektur haben oder mittels kleinen Widgets verschiedene Webservices nutzen soll, ohne dass man dabei auf fertige Produkte oder Teilprodukte zurückgreifen will, ist das Zend Framework eine mehr als in Erwägung zu ziehende Alternative.
Eventuell lohnt sich aber auch ein Blick auf Konkurrenzprodukte, wie zum Beispiel CakePHP oder Symfony.

So nun aber los:

Download & Installation

Zunächst beginnen wir mit dem Download der benötigten Komponenten. Um das Framework herunterladen zu können, muss man sich erst einmal registrieren. Je nachdem, wie die spätere Anwendung konzipiert ist, muss man an der Stelle schon die erste Entscheidung treffen, ob man das All-Inclusive-Paket (ca. 25MB, zip) oder die Minimalversion (ca. 4MB, zip) von der Herstellerseite herunterladen möchte.
Für Einsteiger und Leute, die später mit dem Dojo Toolkit arbeiten möchten empfehle ich die Vollversion herunterzuladen, da hier das Dojo Toolkit und einige Demos enthalten sind, die man sehr leicht ausprobieren und anschließend anhand des Quelltextes nachvollziehen kann.
Für eine lokale Testumgebung bietet sich eine Xampp-Installation mit einem Editor nach Wahl (z.B. Aptana Studio oder als Plugin für Eclipse) an. Da das Framework für die Umsetzung einer MVC-Architektur eingesetzt werden soll, empfiehlt es sich, die auf der Herstellerseite vorgeschlagene Verzeichnisstruktur zu übernehmen.
Diese wird im htdocs-Verzeichnis des Apachen angelegt und sieht dann für ein Beispielprojekt “XSampleBlog”, folgendermaßen aus:

htdocs/XSampleBlog/
|
|- application/controllers/
|
|- application/views/
|
|- application/views/scripts
|
|- library
|
|- public

Nun werden die Klassen des Frameworks, welche sich im library-Verzeichnis der entpackten Dateien (ZendFramework-1.x/library/) befinden, in das library-Verzeichnis unserer soeben erstellten Dateistruktur kopiert. Damit ist die “Installation” abgeschlossen.

Zugriffsschutz und Rewriting mittels htaccess

Da nur die Dateien, die sich im Verzeichnis “public” befinden, öffentlich zugänglich sein sollen, heißt das im Umkehrschluss, dass man die beiden anderen Verzeichnis vor einer Auslieferung durch den Webserver bewahren muss. Da man bei den meisten Webhostern auf die direkte Konfiguration des Webservers keinen Einfluss hat, bleibt nur die Konfiguration mittels htaccess-Dateien. Die beiden Verzeichnisse werden also jeweils mittels einer htaccess-Datei mit folgendem Inhalt bestückt, was eine Auslieferung durch den Webserver verhindert (Vertiefung):

deny from all

Außerdem muss der Apache so konfiguriert werden, dass die Variable $_SERVER[‘DOCUMENT_ROOT’] auf das public-Verzeichnis verweist. In dieses Verzeichnis wird anschließend eine htaccess-Datei mit Rewrite-Regeln abgelegt. Diese Regeln sorgen dafür, dass für eine gegebene URL, die jeweilige Datei (falls existent) statisch ausgeliefert wird, oder in allen anderen Fällen, die Anfrage dynamisch von der im public-Ordner abgelegten index.php behandelt wird. Die index-Datei entspricht somit einem sogenannten Frontcontroller, welcher alle Anfragen des Nutzers empfängt und an den konkreten Controller übergibt.

Anlegen der bootstrap- und index-Datei

Der nächste Schritt ist das Anlegen der bootstrap- und der index-Datei. Die erstere wird von der zweiten eingebunden. Der funktionale Ablauf ist folgender:

  1. Setzen von globalen Pfadangaben (APPLICATION_PATH) (index.php)
  2. Aktivieren des Zend_Loader (index.php)
  3. Definition von globalen Konstanten (APPLICATION_PATH, APPLICATION_ENVIRONMENT) (bootstrap.php)
  4. Erzeugen einer Singleton-Instanz des Zend_Controller_Front (bootstrap.php)
  5. Registrieren des controller-Verzeichnisses am Frontcontroller (bootstrap.php)
  6. Registrieren des env-Parameters (development, staging, testing, production) am Frontcontroller (bootstrap.php)
  7. Löschen der eben erzeugten Variable $frontcontroller (bootstrap.php)
  8. Dispatchen des Requests am Frontcontroller (index.php)

Erläuterungen:
zu 7.: In Schritt 4 wurde die Frontcontroller-Instanz an eine Variable gebunden. Da der Frontcontroller jedoch das Singleton-Pattern implementiert, wird diese Variable nicht mehr benötigt und daher gelöscht.

Die Quellcodes für die beiden Dateien sind auf der Herstellerseite zu finden. Damit ist die Anwendung vorerst ausreichend konfiguriert, um nun endlich unsere “Hello World!”-Ausgabe erzeugen zu können.

Hello World!

Unter der Haube wird vom Frontcontroller der Request anhand der übermittelten URL an einen Actioncontroller übergeben. Dies geschieht natürlich nicht willkürlich, sondern folgt folgender Gesetzmäßigkeit. Nehmen wir einmal an, dass die URL “example.com” auf unser public-Verzeichnis zeigt. Wird mit der URL kein weiterer Parameter übergeben, wird am Actioncontroller “IndexController” die Methode “indexAction” aufgerufen. Das selbe Ergebnis würde auch sowohl mit der URL “example.com/index” als auch mit der URL “example.com/index/index” erreicht. Das Schema ist also:

hostname/class/method

. Nach diesem Prinzip lassen sich weitere Actioncontroller bzw. deren Methoden aufrufen.
Besteht ein Klassen- bzw. Methodenname aus mehreren Wörtern, wie im Fall von “HelloWorld” mit der zugehörigen Methode “sayHello”, erfordert dies eine URL mit dem Wert “example.com/hello-world/say-hello” oder “example.com/hello.world/say.hello”. In diesem Falle wird dann am Actioncontroller mit dem Namen “HelloWorldController” die Methode mit dem Namen “sayHelloAction” aufruft. In unserem Fall sieht die Klasse “HelloWorldController” wie folgt aus:

class HelloWorldController extends Zend_Controller_Action {

    public function indexAction() {
        $this->render('say-hello');
    }

    public function sayHelloAction() {
    }

}

Unsere “Hello World!”-Klasse hat zwei Methoden. Die Methode “indexAction” wird aufgerufen, wenn die URL nur einen Parameter enthält, nämlich den der Klasse. Dieses Prinzip ist analog zu der Eigenschaft des Apache Webservers Requests, die nicht auf eine bestimmte Datei zeigen, auf die index-Datei des jeweiligen Ordners weiterzuleiten. In unserem Fall ruft die Methode “indexAction” die render()-Methode auf mit dem Wert “say-hello”. Dies hat zur Folge, dass das View Skript mit dem Pfadnamen

application/views/scripts/hello-world/say-hello.phtml

gerendert wird. Genau das selbe passiert auch implizit, wenn man diesen Parameter über die URL mitgibt. In dem Fall wird nämlich die zweite Methode unserer Klasse aufgerufen, also “sayHelloAction”. Da hier kein expliziter render-Aufruf enthalten ist, wird standardmäßig das View Skript gerendert, welches den per URL übergebenen Parametern entspricht. Ein Beispiel für eine phtml-Datei gibt es hier.

Das war’s. Bei Fragen oder Problemen darf gerne ein Kommentar hinterlassen werden.

Weiterlesen: Zend Framework – Tutorial 2. Teil – Von der Anfrage zum Controller

This entry was posted in Development and tagged , , , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

3 Comments

  1. Dennis Becker
    Posted 9. March 2009 at 11:37 | Permalink

    Schön das noch jemand ein ZF Tutorial schreibt 🙂 Ich bin nur eben drüber geflogen, da ich eigentlich gerade auf der Suche nach einem PHPUnit Tutorial bin. Ich selbst bin auch sehr aktiv auf der zfforum.de Seite – ich denke mal da findet sich auch sehr schnell kompetente Hilfe 🙂 Ich werd mal deinen Blog im Auge behalten und dein Tutorial weiter empfehlen, finde es wirklich gut gelungen!

  2. Posted 22. December 2010 at 16:09 | Permalink

    Ist das richtig ?
    In diesem Falle wird dann am Actioncontroller mit dem Namen “HelloWorldController” die Methode mit dem Namen “helloWorldAction” aufruft.

    ruft der HelloWorldController nicht die Methode sayHelloAction auf?
    Fang grad erst an mich einzulesen in das Framework, deswegen weiss ich das nicht und wundere mich grad 🙂

  3. Posted 23. December 2010 at 15:14 | Permalink

    Vielen Dank für den Hinweis. Der Einwand ist natürlich völlig korrekt!

2 Trackbacks

Post a Comment

Your email is never published nor shared.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="">