Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 15

Einblicke in Version 1.2: Symfonys neueste Komposition

Die letzten Monate des Jahres 2008 standen für die Symfony-Community ganz im Zeichen der neuen Version 1.2, welche am 1. Dezember das Licht der Welt erblickte. Großen Wert legte das Core-Team für dieses Release auf die Unabhängigkeit von den mitgelieferten Bibliotheken. Mit Doctrine ist ein zweiter Datenbank-Mapper neben Propel getreten. Außerdem erweitert das Core-Team den internen Einsatz des Forms-Frameworks und hat damit den Admin Generator komplett neu geschrieben.

Für den direkten Einstieg in die neueste Version von Symfony empfiehlt sich die Installation der Sandbox [1] anhand der Dokumentation [2]. Um die Codebeispiele des Artikels ausprobieren zu können, sollte man außerdem noch ein Datenbank-Schema in der Datei „config/doctrine/schema.yml“ anlegen.

Die Auswahl macht's

In Sachen Datenbankabstraktion ist Symfony den nächsten Schritt gegangen und lässt dem Entwickler die freie Entscheidung zwischen den Mappern Propel und Doctrine, ohne dabei auf eines der Features von Symfony verzichten zu müssen. Das heißt alle Funktionen, wie der Admin-Generator, das Symfony Command Line Interface (CLI) oder die neuen datenbankgestützten Routen funktionieren mit beiden absolut gleichwertig. Das Aktivieren des gewünschten Mappers gestaltet sich denkbar einfach durch zwei Zeilen Code in der Datei „config/ProjectConfiguration.class.php“:

PHP

$this->enablePlugins(array('sfDoctrinePlugin'));
$this->disablePlugins(array('sfPropelPlugin'));

Listing 1

Nach dem Leeren des Symfony-Caches durch das Symfony CLI ist nun Doctrine als Mapper aktiviert und kann benutzt werden.

Sprichst du DQL?

Wie Propel bietet auch Doctrine die Möglichkeit, Anfragen an die Datenbank zu stellen, ohne dabei eine Zeile SQL-Code schreiben zu müssen. Doctrine verwendet hierzu die Doctrine Query Language (DQL), die eine vom verwendeten Datenbanksystem unabhängige, objektorientierte Schnittstelle zu SQL darstellt. Eine Abfrage nach allen Artikeln eines Blogs würde in DQL so aussehen:

PHP

$query = Doctrine::getTable('Article')->createQuery('a');
$articles = $query->fetchArray();

Listing 2

Doctrine führt den erstellten Query aus und legt das Ergebnis der Abfrage in einem assoziativen Array ab. Das Ergebnis der Abfrage kann dann zum Beispiel mit einer foreach-Schleife durchlaufen werden, die Spalten der abgefragten Tabelle lassen sich hierbei als Index ansprechen. Möchte man etwa den Titel des ersten Artikels anzeigen, reicht folgende Zeile Code völlig aus:

PHP

echo $articles[0]['title'];

Listing 3

Die volle Stärke von DQL zeigt sich allerdings erst, wenn Beziehungen zwischen den Tabellen ins Spiel kommen. Um zum Beispiel den Artikel mit der ID 1 und seine Kommentare anzuzeigen, würde das DQL Statement so aussehen:

PHP

$query = Doctrine_Query::create()
	    ->from('Article a')
	    ->leftJoin('a.Comments c')
	    ->where('a.id = ?', 1);
$article = $query->fetchOne();

Listing 4

Das Ergebnis kann wieder auf dieselbe Weise ausgelesen werden. Das Array „Index Comments“ enthält alle zum Artikel gehörenden Kommentare und kann auch als Array durchlaufen werden:

PHP

foreach ($article['Comments'] as $comment) {
	    echo $comment['body'];
}

Listing 5

Viele Routen führen nach Rom

Um URLs in der Form „http://example.com/artikel/1“ aufzulösen, verwendet Symfony ein eigenes Routing-System. Dieses wurde für das aktuelle Release komplett umgeschrieben, ist nun vollkommen objektorientiert und unterstützt die REST-Architektur. In älteren Versionen diente das System als eine Art statische Vermittlungsstelle zwischen Request und Controller. Da jede Route nun ein Objekt ist, können in den enthaltenen Actions oft wiederkehrende Aufgaben untergebracht werden.

Um etwa eine RESTful-API zur Verfügung zu stellen, können Routen der Klasse „sfRequestRoute“ die grundlegende Logik für REST-Anfragen erledigen. Die URL „example.com/article/1“ liefert zum Beispiel über eine HTTP-GET-Anfrage die Ressource mit der angegebenen ID zurück. Normalerweise würde ein Entwickler in der dazugehörigen Action jedesmal prüfen, ob die Request-Methode auch wirklich GET ist. Dies übernimmt in der neuen Version die folgende Einstellung in der Datei „routing.yml“:

YAML

article:
	  url:                   /article/:id
	  param:             { module: article, action: show }
	  requirements:  { sf_method: get }
	  class:               sfRequestRoute

Listing 6

Versucht der User nun, mit einer anderen Request-Methode als HTTP-GET die URL aufzurufen, wird er automatisch auf eine 404-Fehlerseite weitergeleitet.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden