© istockphoto.com/SireAnko
Mit dem Zend Framework 2 die richtige Route finden

Auf der Route 66


Bei der Konfiguration des Routings einer Zend-Framework-2-Anwendung gibt es einiges zu beachten, um unnötige Probleme frühzeitig zu vermeiden. Mit den passend ausgewählten Routentypen und einer durchdachten Struktur können Sie der Performance des Zend-Framework-2-Routers ordentlich einheizen. Zudem helfen eine gleichbleibende Benennung und eine feste Struktur der Routen dabei, nicht viel Zeit bei der Generierung von URLs in der View und im Controller zu verlieren.

In diesem Artikel erfahren Sie zunächst einiges über die Grundlagen des Routings im Zend Framework 2 und welche Routentypen Ihnen zur Verfügung stehen. Danach bauen wir auf Basis einiger Controller eine erste Routenkonfiguration auf und verbessern diese schrittweise hinsichtlich des Speicherverbrauchs und der Performance. Zusätzlich erfahren Sie alles Wissenswerte über die Ausgabe von URLs auf Basis Ihrer Routenkonfiguration und erhalten einen Ausblick auf das Routing im Zend Framework 3.

ZF2-Beispielanwendung

Damit Sie die Beispiele selbst nachvollziehen können, steht eine Beispielanwendung auf GitHub für Sie bereit [1]. Darin wollen wir mit dem Routing einer Anwendung experimentieren und schauen, was es alles zu dem Thema zu beachten gilt. Sie können das Projekt wie folgt klonen (bitte ggf. die Verzeichnisse anpassen) und installieren. Dabei setzen wir auch noch die Schreibrechte des /data/-Verzeichnisses und wechseln Sie dann zum start-Branch:

$ cd /home/devhost $ git clone https://github.com/RalfEggert/phpmagazin.routing $ cd phpmagazin.routing $ php composer.phar selfupdate $ php composer.phar install $ sudo chmod 777 -R data/ $ git checkout start

Danach richten Sie einen Virtual Host für die Adresse phpmagazin.routing ein. Wenn Sie nun http://phpmagazin.­routing/ in Ihrem Browser aufrufen, sollte die Seite ungefähr wie in Abbildung 1 aussehen. Die Listings zu diesem Artikel finden Sie sowohl auf GitHub [2] als auch in diesem Repository im Verzeichnis /listings/. Damit sind die Vorbereitungen abgeschlossen, und wir können loslegen.

eggert_routing_1.tif_fmt1.jpgAbb. 1: Der erste Aufruf von http://phpmagazin.routing

Grundlagen zum Routing

Das Routing einer Anwendung hat generell die Aufgabe, auf Basis einer Serveranfrage herauszufinden, welcher Controller aufgerufen werden soll. Dafür wird der URL der Anfrage analysiert und mithilfe der Routenkonfiguration die passende Route ermittelt. Im Zend Framework 1 stand eine vordefinierte Route bereit, mit der sich theoretisch das Routing einer gesamten Anwendung umsetzen ließ. Alle URLs nach folgendem Schema konnten damit ohne weitere Konfiguration verwendet werden: http://meine.domain.de/module/controller/­action/key1/value1/key2/value2.

Der erste Parameter war somit ein Platzhalter für den Namen eines Moduls, der zweite Parameter definierte den Controller und der dritte die aufzurufende Aktion. Für alle drei Ebenen standen Default-Werte bereit, sodass diese auch weggelassen werden konnten. Werden für eine Route weitere Parameter benötigt, können sie als Schlüssel-Wert-Paare angegeben werden. Folgender URL folgt diesem Schema: http://meine.domain.de/shop/basket/add/id/42/quantity/23.

Für das Modul „Shop“ soll im Controller Basket die Aktion add mit den Parametern id (Wert: 42) und quantity (Wert: 23) ausgeführt werden.

Im Zend Framework 2 steht diese vordefinierte Route nicht mehr zur Verfügung. Die grundlegende Idee dahinter ist, dass jedes Modul selbst für sein Routing verantwortlich sein und die entsprechende Konfiguration beinhalten soll. Sie könnten theoretisch zwar auch eine Standardroute nach dem obigen Schema anlegen und für alle Module nutzen, jedoch würde dies Abhängigkeiten zwischen den Modulen schaffen, die in der Praxis zu mehr Problemen und weniger Nutzen führen würden.

Wenn jedes Modul sein eigenes Routing mit sich bringen soll, dann müssen Sie als Entwickler darauf achten, dass sich die Routen der einzelnen Module nicht gegenseitig überlagern – das könnte sonst zu unvorhersehbaren Effekten führen. Wie Sie dies in Ihrer Anwendung umsetzen und was es bei der Konfiguration der Routen innerhalb Ihrer Module noch zu beachten gilt, erfahren Sie im weiteren Verlauf dieses Artikels.

Um eine Route im Zend Framework 2 definieren zu können, stehen Ihnen verschiedene Routentypen zur Verfügung. Eine Übersicht finden Sie in Tabelle 1. Im Folgenden werden wir für verschiedene dieser Routentypen einige Beispiele durchgehen. Bitte beachten Sie, dass der Einsatz der Routentypen „Query“ und „Wildcard“ aus Sicherheitsgründen nicht mehr empfohlen wird. Ein Großteil der Routen eines Projekts lässt sich in der Praxis meist auf Basis der Routentypen Literal und Segment umsetzen.

Routentyp

Beschreibung

Hostname

Wertet den Servernamen der Anfrage anhand der Routendefinition aus

Literal

Legt eine feste Zeichenkette für den URL der Anfrage fest

Method

Wertet die HTTP-Methode der Anfrage aus

Part

Ermöglicht den hierarchischen Aufbau von Routen der anderen Typen

Regex

Wertet den URL der Anfrage anhand eines regulären Ausdrucks aus

Scheme

Wertet das URI-Schema der Anfrage aus (z. B. http:// oder https://)

Segment

Wertet die einzelnen, durch einen Slash getrennten Segmente einer Route aus

Query

Wertet Query-Parameter am Ende des URLs aus (deprecated)

Wildcard

Wertet Segmente anhand von Schlüssel-Wert-Paaren aus (deprecated)

Tabelle 1: Routentypen im Zend Framework:

Bevor wir tiefer in einige Beispiele einsteigen können, noch ein paar Worte zur Konfiguration der Routen: Alle Routen eines Moduls werden idealerweise in der Modulkonfigurationsdatei des Moduls definiert. Alle Konfigurationsdateien aller aktivierten Module Ihrer ZF2-Anwendung werden bei der Ausführung Ihrer Anwendung gelesen – damit wird entsprechend auch die Routenkonfiguration zusammengeführt.

Weitere Informationen zum Routing im Zend Framework 2 finden Sie auch im Referenzhandbuch [3].

Literalrouten

In der Beispielanwendung wurden im Modul „Shop“ einige Controller und Aktionen angelegt. Das Routing für dieses Modul möchten wir zum Einstieg vollständig mit dem Literal-Routentyp umsetzen. Ob es technisch sinnvoll ist, alle Routen nur mit Literals umsetzen zu wollen, lassen wir an dieser Stelle einmal außer Acht.

In Listing 1 sehen Sie einen Ausschnitt aus der Modulkonfigurationsdatei /module/Shop/config/module.config.php unseres Beispielprojekts. Dort wird die Definition einer Route für die Startseite unseres Shopmoduls sowie für einen Controller abgebildet. Das Routing für das Modul muss unter dem Schlüssel router definiert werden, darunter wird der Schlüssel routes mit Ihren Routendefinitionen erwartet. Der Schlüssel shop auf der dritten Ebene legt den Namen dieser Route fest. Sie wird später bei der Ausgabe eines URLs auf Basis dieser Route benötigt. Auf der vierten Ebene wurde der Typ auf Literal gesetzt, und es wurden die Optionen für diese Route definiert. Die Routen vom Typ Literal müssen als feste Zeichenkette festgelegt werden, in diesem Fall lautet sie /shop. Das bedeutet, dass diese Route zu einem Treffer führt, wenn der URL der Anfrage an den Server genau /shop lautet. Zusätzlich werden bei den Optionen noch die Default-Werte für diese Route angegeben. Es ist wichtig, dass jede Route einen Wert für den Controller und die Aktion bekommt; sie müssen beim Literal als Default-Werte festgelegt werden. Der Wert für __NAMESPACE__ wird als Präfix für den Namen des Controllers verwendet.

Listing 1

return array( 'controllers' => array( 'invokables' => array( 'Shop\\Index' => 'Shop\\Controller\\IndexController', ), ), 'router' => array( 'routes...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang