ZF2 – ein Cookbook

In 3 Schritten einen URL-Shortener mit dem neuen Zend Framework 2 bauen [Schritt 1]
Kommentare

Gute Nachrichten für Zend-Framework-Entwickler und alle, die es werden wollen: Zend Framework ist am 6. September in der Version 2 erschienen. Und wer schon einmal in den Code reingeschaut hat oder einen Blick in die Doku geworfen hat, wird feststellen, dass sich doch einiges seit der ersten Version geändert hat. Grund genug, in einem Cookbook zu beschreiben, wie mit ZF2 losgelegt werden kann.

Zu Schritt 2 geht es hier.

Zu Schritt 3 geht es hier.

ZF2 – ein Cookbook

Der Artikel „ZF2 – ein Cookbook“ von Jan Burkl ist erstmalig erschienen im PHP Magazin 1.2013

Als Beispielapplikation möchte ich einen einfachen URL-Shortener à la bit.ly implementieren. Der Funktionsumfang ist überschaubar, dennoch gibt es so einige spannende Punkte, die sehr elegant mit dem ZF2 gemeistert werden können. In diesem Artikel werden zwar immer wieder Verweise auf die erste Version des Zend Frameworks zu finden sein, aber auch für ZF-Neulinge sollte das Nachimplementieren kein Problem darstellen.

Was ist der Use Case? Anstatt eines langen, beliebigen URL möchte ich nur einen kurzen Text, der an den Host-Namen gehängt wird, eingeben. Ein Beispiel: Wenn ich auf ein bestimmtes Webinar auf der Zend-Seite verknüpfen möchte, könnte der entsprechende URL wie folgt aussehen: http://www.zend.com/de/resources/webinars/php-and-cloud#PDitC. Schöner wäre es, einen kurzen Link zend.com/cloud zu verwenden. Der Pfad /cloud soll natürlich frei gewählt werden können und das Verhalten des CMS nicht verändert werden. Also brauchen wir ein Formular mit zwei Feldern (original_uri und der trim_path) zur Eingabe. Diese Werte sollten auch in einer Datenbank gespeichert werden können. Der Einfachheit halber nutzen wir SQLite. Eine Liste aller eingetragenen URLs wäre nicht schlecht, genauso wie die Möglichkeit, einzelne Einträge wieder zu löschen. Und natürlich der Redirect-Mechanismus der neuen, „virtuellen“ Pfade. Unsere App nennen wir Zhorty.

Installation und Skeleton-App

Bevor wir mit der Businesslogik von Zhorty beginnen können, müssen wir noch einige Kleinigkeit vorbereiten – im Wesentlichen brauchen wir natürlich auch den Zend-Framework-2-Code.

Zum einen brauchen wir den ZF2-Code, zum anderen möchte ich mit der offiziellen Skeleton-App arbeiten. Die eigene Applikation auf der Skeleton-App aufzusetzen, ist der empfohlene Weg, mit neuen Projekten im ZF2 zu starten. ZF2 kann man in der aktuellen Version unter [1] herunterladen. Die Skeleton-App liegt auf GitHub und wird als ZIP-Paket unter [2] bereitgestellt. Jetzt wird der eine oder andere denken: „Warum Download? Ich dachte, ZF unterstützt Composer und Pyrus?“. Das ist richtig. ZF2 stellt verschiedene Möglichkeiten bereit, ein Projekt anzulegen. Darunter auch das mittlerweile populäre Composer. Jedoch ist das auch eine Komponente, die vielleicht manch einem noch nicht geläufig ist und somit eine zusätzliche Hürde bei der Installation darstellen würde. Aus diesem Grund werden wir das Setup manuell durchführen. Und bei der Größe dieses Projekts ist dieser Aufwand auch überschaubar. Also, Skeleton-App und ZF2 herunterladen und entpacken. Die Skeleton-App könnte z. B. unter Linux im Pfad /var/www landen. Als Nächstes sollte der Webserver entsprechend konfiguriert werden. Hier gibt es selbstverständlich sehr viele Möglichkeiten, dies umzusetzen, abhängig von IDE, Betriebssystem und natürlich auch vom Webserver selbst. Ich selbst arbeite in der Regel mit einem Ubuntu-System, welches in einer virtuellen Maschine auf einem Windows-Host-System läuft. Über das „Shared Folder“-Feature mounte ich auf dem Linux-Gast-System den Ordner der Skeleton-App vom Windows Host. Als Webserver wird Apache verwendet, der idealerweise einen VirtualHost, der z. B. auf den Servernamen „zhorty.dev“ hört, so einsetzt, dass der DocumentRoot auf das public-Verzeichnis der Skeleton-App zeigt. Diese Anleitung ist mit Absicht sehr knapp gehalten, da die beschriebene Vorgehensweise keine Grundvoraussetzung für die Entwicklung mit ZF2 ist. Prinzipiell ist das initale Setup für ZF2 genau wie für ZF1. Bitte auch beachten, dass der Virtual Host das Auslesen der .htaccess-Datei unterstützt.

Die Skeleton-App weiß zu diesem Zeitpunkt noch nichts von ZF2. Das lässt sich ändern, indem das library-Verzeichnis des entpackten ZF2 in den vendor/ZF2-Ordner der Skeleton-App gelegt wird. Das vendor-Verzeichnis ist neu gegenüber ZF1 und prinzipiell für alle Librarys (auch Third-Party-Libraries) bzw. Module gedacht, die von der eigentlichen Applikation genutzt werden sollen. So auch der ZF2 Core.

ZF2 Workflow

Das war es schon für die Skeleton-App. Jetzt kann im Browser getestet werden, ob auch alles funktioniert hat (Abb. 1). Sieht alles schon ganz gut aus – das liegt mitunter an dem verwendeten Twitter Bootstrap Style, der standardmäßig für das Layout verwendet wird.

Abb. 1: ZF2 Skeleton-App-Startseite

Aber was ist genau passiert? Schauen wir uns den Workflow etwas näher an. Die .htaccess-Datei sorgt dafür, dass jeder Request auf die index.php geroutet wird. Sie ist sehr leichtgewichtig. Als Erstes wird die init_autoloader.php inkludiert. Sie prüft, ob es den Pfad vendor/ZF2/library gibt bzw. dass dieser Ordner existiert. Dafür haben wir weiter oben gesorgt. Daher wird der StandardAutoloader registriert, der dafür sorgt, dass alle Klassen des ZF2 ohne require geladen werden. Wie beschrieben, ist das allerdings nicht der einzige Weg, das ZF2 einzubinden. Sehr einfach geht es zum Beispiel auch, wenn eine Environment-Variable ZF2_PATH in der Serverkonfiguration gesetzt wird. Natürlich kann die init_autoload.php nach Einsatzzweck frei gestaltet werden, der oben beschriebene Weg ist allerdings für den Anfang der schnellste.

Nach dem Setup des Autoloaders wird die Applikation initialisiert (ZendMvcApplication::init()). Als Parameter wird die Applikationskonfiguration als Array übergeben. Hier sehen wir auch direkt eine Besonderheit gegenüber ZF1: In der Vorgängerversion wurde primär mit ini-Konfigurationsdateien gearbeitet. Aus Performancegründen geht man wieder „back to the roots“: Assoziative Arrays sind schneller, da sie nicht erst in eine PHP-Struktur überführt werden müssen, und wirklich unleserlicher als ini-Dateien sind sie auch nicht. Das Konfigurations-Array wird auch nicht in einer Variablen gespeichert, sondern einfach mittels return zurückgegeben. Sehr pragmatisch. Dem Inhalt der Applikationskonfiguration werden wir uns später widmen.

Im Inneren der init()-Methode passiert jetzt natürlich eine Menge: Im Wesentlichen werden alle registrierten Module vorbereitet. Modul? Das gab es doch auch schon in ZF1. Korrekt, allerdings haben Module in ZF2 eine viel zentralere Bedeutung (Kasten: „Module“). Genauer gesagt: Ohne Modul geht gar nichts.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -