Es lassen sich aber noch weitere Aufgaben in die Routen auslagern. Datenbankabfragen sind eine Sache, die in fast jeder Aktion zusammen mit Prüfungen auf Request-Parameter vorkommt. Um diese Aufgaben zu vereinfachen, gibt es nun die Routing-Klassen „sfPropelRoute“ und „sfDoctrineRoute“, mit denen Datenbankabfragen in der Route selbst ausgeführt werden können. Um zu der zuvor genannten URL immer eine Datenbankabfrage nach dem Artikel mit der übergebenen ID durchzuführen, reicht folgende Einstellung in der routing.yml:

article:
	  url:           /article/:id
	  param:    { module: article, action: show }
	  class:      sfDoctrineRoute
	  options:  { model: Article, type: object }

Diese Konfiguration der Route bewirkt die Durchsuchung der Tabelle „article“ nach dem Datensatz, der den Request Parameter „id“ als Primary Key enthält. Findet die Route den Datensatz nicht, erfolgt eine Weiterleitung auf die 404-Seite. Um den Datensatz in der entsprechenden Action zu erhalten, muss in ihr noch folgende Zeile Code eingefügt werden:

$this->article = $this->getRoute()->getObject();

Dadurch reduziert sich der Code in den meisten Aktionen auf eine Zeile. Allerdings ist dabei die REST-Architektur verloren gegangen. Außerdem müsste man mit vielen Routen in der routing.yml eine REST-Architektur zusammenbauen. Genau diese Problematik gehen die Collection-Routing-Klassen an – es gibt sie einmal ohne und mit Datenbankunterstützung. Collection-Routen definieren ein Bündel aus Routen für eine Ressource im Sinne von REST. Würde man also wieder das Artikel-Beispiel bemühen, könnte eine datenbankgestützte Collection-Route folgende Konfiguration in der routing.yml verwenden:

articles:
	  class:   sfDoctrineRouteCollection
	  options: { model: Article, module: article }

Als Ergebnis erhält man eine Kombination aus beiden zuvor genannten Varianten, was bedeutet, dass Routen die typischen Aktionen einer REST-Ressource erhalten (list, new, create, update usw.) und diese gleichzeitig schon die Datenbankabfragen erledigen. Dadurch wird der Code sowohl in den Aktionen als auch in der routing.yml noch weiter verringert und man kann sofort mit der Entwicklung von individuellen Features der zu entwickelnden Applikation beginnen.

Alle Macht dem Admin!

Das Wiedererfinden des Rads ist eine Disziplin, in der sich Entwickler immer wieder als sehr gut erweisen. Backends für den späteren Benutzer machen da keine Ausnahme. Da sich die Aufgaben für Backends meistens auf die Aktionen „erstellen, verändern, anzeigen und löschen“ minimieren lassen, haben die Symfony-Entwickler den Admin-Generator erstellt. Möchte man beispielsweise ein Backend für seine Artikel erstellen, genügen folgende CLI-Befehle:

./symfony generate:app backend
./symfony doctrine:generate-admin backend Article
./symfony cache:clear

Der ausgeführte Befehl legt ein Modul mit dem Namen „article“ in der Applikation „backend“ an, welches durch http://example.com/backend.php/article aufgerufen werden kann. Dies liefert ein bereits vollständig funktionierendes Admin-Interface für die article-Tabelle der Datenbank. Das erstellte Modul kann weiter konfiguriert werden, um es an die eigenen Bedürfnisse anzupassen. Reicht die generierte Funktionalität nicht aus, können die bestehenden Funktionen überschrieben und erweitert werden. Hierbei legt Symfony den generierten Code in seinem internen Cache ab und lässt die generierten Dateien dabei völlig unberührt. Dadurch kann der Entwickler die Dateien und Methoden anpassen, ohne sich Gedanken darüber machen zu müssen, dass sein Code irgendwann durch Symfony überschrieben werden könnte.

All diese Funktionalitäten weist das Framework bereits seit Version 1.0 auf. Neu hinzugekommen ist, dass der Admin-Generator auch mit Doctrine funktioniert, auf das Forms Framework aufsetzt und das neue Routing-System verwendet, wodurch die Konfiguration und Anpassung an die eigenen Bedürfnisse nochmals vereinfacht wurden.

Do you Jobeet?!

Kurz nach der Veröffentlichung des Release legte das Core-Team zusammen mit Community-Mitgliedern noch einen drauf und veröffentlichte das Jobeet-Tutorial [3], das in 24 Lektionen einen kompletten Rundgang durch das Framework bietet. Das Tutorial steht als Ausführung für Propel oder Doctrine bereit. Jedem, der tiefer in die Materie einsteigen möchte, sei das Tutorial wärmstens empfohlen. Und wer lieber mit Büchern arbeitet, kann seit neuestem das Tutorial auch in gedruckter Version käuflich [4] erwerben.

Der Autor

Dennis Benkert ist Webentwickler bei der Interlutions GmbH in Köln, die für ihre Projekte auf den Einsatz von Symfony setzt. Mit Interlutions zusammen betreut er Kunden wie Renault, Nintendo of Europe und ImmobilienScout 24. Privat beteiligt er sich aktiv mit Plugins und Hilfestellungen an der Symfony-Community und versucht als Evangelist, so vielen Menschen wie möglich die Vorteile von Symfony näher zu bringen.