Und als wären das nicht schon genug Geschenke: Nach dem Beispiel des inzwischen schon in die Jahre gekommenen Adventskalender “Askeet”, einem Tutorial über 24 Tage, gibt es dieses Jahr einen neuen Adventskalender! Jobeet heißt das Projekt und die ersten vier Tage sind schon online und lohnen sich zu lesen:

• Jobeet – Tag 1 – Starting up the Project
• Jobeet – Tag 2 – The Project
• Jobeet – Tag 3 – The Data Model
• Jobeet – Tag 4 – The Controller and the View

Ich habe mich noch nicht intensiv mit Doctrine auseinander gesetzt, aber ein paar der Features sind verdammt interessant, so dass ich in nächster Zeit mal einen genaueren Blick darauf werfen werde:

• Geschwindigkeit: Seit Propel 1.3 auch auf PDO aufsetzt, ist dies kein Kriterium mehr und Propel 1.3 scheint sogar die Nase knapp vorn zu haben, wenn es um Geschwindigkeit geht.
• Behaviors: Ein geiles Feature. Von Propel kennt man es im Zusammenspiel mit Symfony schon, dass z.B. created_at Zeilen automatisch gepflegt werden. Mit Behaviors hat Doctrine etwas ähnliches an Board, allerdings noch weitaus mächtiger. Definiere ich eine Spalte als Sluggable, wird mir automatisch dafür ein Slug(*) erzeugt. Damit entfällt viel Code, den ich sonst selber schreiben müsste. Das Versionable-Behavior ermöglich es von einer Zeile bzw. einem Objekt mehrere Versionen in der Datenbank zu verwalten. Damit lässt sich ganz einfach und unkompliziert eine Versionsverwaltung aufbauen. Noch ein paar weitere Behaviors runden das Ganze ab.
• Memcache-Driver: Geplant ist ein ähnliches Feature auch für Propel 2.0. Aber Doctrine bringt es schon mit – die Möglichkeit Objekte nicht nur in eine Datenbank zu pressen, sondern auch in einen Cache (bzw. Memcache). Für verteilte Anwendungen mit mehreren Servern bzw. einem Projekt mit Datenbankreplikationen ein Traum!
• Magic Finders: Wie oft ist die erste Handlung, nach dem generieren der Propel-Objekte, angepasste Methoden für die xxxPeer-Klasse zu schreiben, für Fälle bei denen Objekte nicht nur per Primary Key aus der Datenbank geholt werden sollen. Doctrine bietet mit den Magic Finders eine ganze Reihe von Möglichkeiten, das schnell zu bewerkstelligen.
• Inheritance: Das Feature gefällt mir verdammt gut. Vererbung! Möchte man zum Beispiel auf seiner Seite ein Gästebuch und an anderer Stelle Kommentare haben, so haben beide im Grunde die gleiche Basis: Eine Tabelle in die beispielsweise Name, E-Mail, Homepage und Text des Autors gespeichert werden. Aber jeweils beide, Gästebuch-Eintrag und Kommentar, haben eventuell noch zusätzliche, unterschiedliche Felder. Mit Doctrine ist es möglich eine gemeinsame Basis-Tabelle zu definieren und darauf aufbauend weitere Tabellen, die die Eigenschaft der Basis-Tabelle dann in einem Objekt vereinen. Das wird eins der ersten Features sein, die ich unbedingt mal ausprobieren möchte.
• DQL: Doctrine kommt mit einer mächtigen Sprache für Queries daher: DQL. Gerade bei etwas umfangreicheren, verschachtelten Abfragen wird das bauen eines Criteria/Criterion-Objekts mit Propel etwas umständlich. Mit DQL soll dies weitaus leichter sein.

Soviel zunächst zu den, für mich wichtigen, Vorteilen von Doctrine. Es sind auf jedenfall wie gesagt genug, so dass ich mich mal intensiver mit Doctrine beschäftigen möchte. Mir sind auch ein paar Nachteile aufgefallen, bei denen ich noch genauer nachsehen muss, ob es denn welche sind. Aber diese werde ich in einem weiteren Artikel verbloggen.

Auch Propel plant einige geniale Features für die Version 2.0 – so z.B. die angesprochene Möglichkeit Objekte zu cachen – nur ist es halt noch in Entwicklung.

* Slug: Ein Slug ist z.B. für eine URL angepasster Titel eines Artikels, damit dieser lesbar bleibt und in der URL verwendet werden kann. Außerdem muss ein Slug immer eindeutig sein, im Gegensatz allerdings zum Titel eines Artikels, der häufiger vorkommen kann.

Der Hauptgrund war eigentlich, dass 1.2 schon in drei Wochen, genauer am 26.10.2008, erscheinen soll, laut Roadmap. Daraus schließe ich, dass die aktuelle Version aus dem Trunk doch schon relativ stabil sein sollte. Die Features von Propel 1.3 sind einfach zu gut um nicht genutzt zu werden.

Für alle, die Propel 1.3 mit Symfony 1.1 benutzen wollen, gibt es eine gute Anleitung im Symfony Cookbook. Dennoch wollte ich, wenn schon, auch die neuen Features von Symfony 1.2 direkt haben.

Aber auch das Zend Framework ist damit nicht ganz aus dem Rennen. Symfony bietet mit der sfZendFrameworkBridge eine Möglichkeit das Zend Framework innerhalb von Symfony zu benutzen. Da das Zend Framework viele brauchbare Features auch abseits des alltäglichen MVC-Prinzips bietet, ist das eine gute Möglichkeit nicht für alles das Rad neu erfinden zu müssen.

Der Grund: Propel 1.3 kommt mit Symfony 1.2. Und ich würde gerne ein neues Feature von Propel 1.3 nutzen: 1:1-Relationen. Leider funktioniert das in Symfony 1.1 noch nicht so ganz. Das Prinzip ist eigentlich ganz einfach und logisch: Eine Tabelle hat einen PrimaryKey und die andere Tabelle hat darauf einen ForeignKey und einen PrimaryKey. Somit ist logisch festgelegt, dass nur eine 1:1-Beziehung bestehen kann. Propel erkennt dies und im Modell hat man nun get-Methoden, die nur ein Objekt zurückgeben, statt einem Array.

Mit der aktuellen Version von Symfony aus dem Trunk (1.1.5-DEV) scheint das leider noch nicht zu funktionieren. Die Tabelle mit dem Primary-Key gibt einen Array zurück und die Tabelle mit dem Foreign-Key, wie es richtig ist, nur ein Objekt.

Jetzt für mich die große Frage: Warten auf Symfony 1.2? Oder Symfony 1.1 benutzen und vorerst die Methoden selber schreiben und später auf Symfony 1.2 wechseln, wenn das überhaupt problemlos klappt? Oder gar nicht Symfony benutzen und auf Zend Framework + Propel aufbauen? Die Lösung überlege ich mir jetzt wohl erstmal bei einem Kaffee…

Anmerkung: Texte und Kommentare wurden, soweit möglich, ins Deutsche übersetzt, damit sie dem Verständnis helfen. Den Sourcecode selbst habe ich Englisch gelassen, da Symfony-Funktionen und -Methoden, sowie PHP selbst, in Englisch sind und daher eine Übersetzung keinen Sinn machen würde. Im Allgemeinen empfiehlt es sich Sourcecode immer auf englisch zu schreiben. Bei den Kommentaren und der Dokumentation kommt es auf den Einzelfall an.

Die Geschichte

Refaktorisierung bedeutet eine Menge an Code zu verändern. Deshalb braucht man eine Möglichkeit zu Überprüfen, dass man dabei nichts kaputt macht. Also fragte Fabien, vor dem Beginn der Refaktorisierung, Vince nach seinen Unit- und Funktionstests.

Aber Vince hatte leider keine Unit- oder Funktionstests. Also entschieden sie sich, vor Beginn der Refaktorisierung, zunächst ein paar dieser Tests zu schreiben.

Der Symfony-Browser

In Symfony kann man, dank der sfTestBrowser-Klasse, seine Anwendung testen in dem man das Verhalten eines Browsers simuliert. Die Klasse verhält sich wie ein echter Browser aber sie nutzt nicht das HTTP-Protokoll um Symfony-Module aufzurufen. Das hat zwei Vorteile: Es ist einfach schneller und man hat zusätzlich die Möglichkeit Symfony-Objekte nach jedem Request direkt zu überprüfen.

// test/functional/frontend/productActionsTest.php
include(dirname(__FILE__).'/../../bootstrap/functional.php');
 
$browser = new sfTestBrowser();

Die Testdaten (Fixtures)

Da der Test reproduzierbar sein soll, müssen wir sicherstellen, dass die Daten in der Datenbank auch immer die Selben sind, wenn wir den Test starten. Also ging Vince hin und erstellte ein paar Testdaten:

// data/fixtures/product.yml
// Angepasste, eingedeutschte Daten
Category:
  toy_story:
    name: Toy Story
 
  Wall-E:
    name: Wall-E
 
Product:
  U-Command:
    title: Ferngesteuerter Wall-E
    image: walle.jpg
    description: |
      Ein ferngesteuerter Wall-E mit ganz vielen Funktionen.
      Unverzichtbar für jeden "Wall-E"-Fan!
    price:  59.99
    is_new: true
    is_in_stock: true
    category_id: Wall-E
 
  Interaction-Eve:
    title: Interaktive Eve
    image: eve.jpg
    description: |
      Eine sehr interaktive Eve.
      Sollte jeder zu Hause haben!
    price: 65.99
    is_new: true
    is_in_stock: true
    category_id: Wall-E
 
  vending:
    title: Wall-E Figurenset
    image: set.jpg
    description: |
      Komplettes Set mit 8 Figuren.
      Wer das nicht hat ... der hat's nicht!
    price: 6.99
    is_new: true
    is_in_stock: false
    category_id: Wall-E
 
  woody:
    title: Toy Story Woody
    image: woody.jpg
    description: |
      Woody aus dem bekannten Film Toy Story.
    price: 24.99
    is_new: false
    is_in_stock: true
    category_id: toy_story

In dieser Fixure-Datei haben wir zwei Kategorien und vier Produkte definiert. Bis auf das “Wall-E Figurenset” sind alle Produkte im Bestand.

Um die Daten aus der Fixure-Datei zu laden, benutzen wir die sfPropelData-Klasse. Standardmäßig löscht sfPropelData alle Daten aus den Datenbanktabellen, in die wir importieren, so dass jedes mal eine saubere Datenbank für unsere Tests zur Verfügung steht.

// initialize the database with fixtures
$databaseManager = new sfDatabaseManager($configuration);
$loader = new sfPropelData();
$loader->loadData(sfConfig::get('sf_data_dir').'/fixtures');

Symfony benutzt die Datenbank-Konfiguration der Testumgebung, wenn es für einen Funktionstest (functional test) genutzt wird. Wenn man sich also nicht die Standarddatenbank, die man zum Entwickeln benutzt, zerstören will, sollte man sich durch einen “test”-Eintrag in der database.yml-Konfigurationsdatei, eine spezielle Konfiguration für die Tests anlegen.

Jetzt wird bei jedem Start des Skripts die Datenbank aufgeräumt und die Fixture-Daten geladen. Selbst wenn unser Test die Daten verändert, wird dies keine Auswirkung auf den nächsten Testdurchlauf haben.

CSS3-Selektoren

Auf der Startseite müssen wir sicherstellen, dass wir eine Liste von Produkten vorfinden und das alle Produkte, die angezeigt werden, im Bestand sind. Wir testen jetzt ob das Produkt “Toy Story Woody” angezeigt wird, aber nicht das “Wall-E Figurenset”.

$browser->
  get('/')->
  isStatusCode(200)->
  isRequestParameter('module', 'product')->
  isRequestParameter('action', 'index')->
  checkResponseElement('body', '/Toy Story Woody/')->
  checkResponseElement('body', '!/Wall-E Figurenset/')
;

Das Skript ist selbsterklärend:

• Ruf die Startseite ab (/).
• Überprüfe, dass der Body (<body>) den Produkttitel enthält.
• Überprüfe, dass die Seite nicht das Produkt enthält, dass nicht im Bestand ist.

Wenn ein Produkt neu ist (is_new Spalte in der Datenbank), wird der Text “NEU!” an den Titel angehängt. Bevor wir den Test schreiben, der überprüft ob das korrekt funktioniert, schauen wir uns das Template der Startseite an:

<h1>Unsere Produkte</h1>
 
<?php foreach ($products as $product): ?>
  <div>
    <h2>
      <?php echo $product->getTitle() ?>
      <?php if ($product->getIsNew()): ?><span style="margin-left: 10px; color: #e55">NEU!</span><?php endif; ?>
    </h2>
    <div style="margin-bottom: 10px">
      <em>Kategorie</em>: <?php echo $product->getCategory()->getName() ?> -
      <em>Preis</em>: Only $<?php echo $product->getPrice() ?> - 
      <?php if (in_array($product->getId(), array_keys($sf_user->getAttribute('favorites', array())))): ?>
        <a href="<?php echo url_for('product/removeFromFavorites?id='.$product->getId()) ?>"><img src="/images/favorite.png" /></a>
      <?php else: ?>
        <small><?php echo link_to('Zu meinen Favoriten hinzufügen', 'product/addToFavorites?id='.$product->getId()) ?></small>
      <?php endif; ?>
    </div>
    <div>
      <div style="float: left">
        <img width="100px" src="/images/products/<?php echo $product->getImage() ?>" />
      </div>
      <p>
        <?php echo $product->getDescription() ?>
        <?php if ($sf_user->isAuthenticated()): ?>
          <p style="text-align: right"><a href="<?php echo url_for('product/edit?id='.$product->getId()) ?>">Produkt editieren</a></p>
        <?php endif; ?>
      </p>
      <br style="clear: both" />
    </div>
    <div style="text-align: right">
      <?php echo link_to(image_tag('/images/add_to_cart.png'), 'product/buy?id='.$product->getId()) ?>
    </div>
    <hr />
  </div>
<?php endforeach; ?>

Um zu Überprüfen ob der Text “NEU” hinter den Produkttitel gesetzt wird, können wir nicht einfach überprüfen ob “NEU” im Body-Tag steht. Das wäre etwas ungenau und für einen brauchbareren Test müssen wir den Test präziser schreiben. In Symfony ist dies ziemlich einfach, da die checkResponseElement()-Methode CSS3-Selektoren als erstes Argument annimmt:

$browser->
  get('/')->
  checkResponseElement('h2:contains("NEU")', 2)
;

Hier überprüfen wir, dass es genau zwei H2-Tags haben, die das Wort “NEU” enthalten.

Jetzt müssen wir noch das Editieren von Produkten testen. Das Szenario dafür ist das folgende:

• Einloggen als Administrator
• Auf den “Produkt editieren”-Link klicken
• Das Formular mit neuen Daten ausfüllen und eine neue Datei hochladen
• Das Formular abschicken
• Überprüfen, dass die abgeschickten Daten auf der Homepage angezeigt werden
• Ausloggen

Um uns als Administrator einzuloggen, müssen wir auf den “Einloggen”-Link klicken:

$browser->
  click('Einloggen')->
  isRedirected()->
  isRequestParameter('module', 'user')->
 
  isRequestParameter('action', 'signin')->
  followRedirect()->
  isStatusCode(200)->
  isRequestParameter('module', 'product')->
  isRequestParameter('action', 'index')->
  checkResponseElement('body', '!/Einloggen/')->
  checkResponseElement('body', '/Ausloggen/')
;

Nach der Authentifizierung, leitet die signin-Action den Benutzer bzw. Browser auf die Startseite. Wir überprüfen dann, dass der “Einloggen”-Link nicht mehr existiert und durch einen “Ausloggen”-Link ersetzt wurde.

Jetzt wo wir eingeloggt sind, können wir auf den “Produkt editieren”-Link klicken. Aber auf der Startseite sind mehrere Links mit diesem Namen. Wir nehmen also an, wir wollen auf den zweiten Link klicken:

// Das position-Attribute ist neu in Symfony 1.2
$browser->
  click('Edit this product', array(), array('position' => 2))->
  isStatusCode(200)->
  isRequestParameter('module', 'product')->
  isRequestParameter('action', 'edit')->
  checkResponseElement('h2', '/Ferngesteuerter Wall-E/')
;

Nach ein paar grundlegenden Überprüfungen auf der Seite, sind wir bereit das Formular abzuschicken:

$browser->
  click('Save', array('product' => array(
    'price'  => '10',
    'image'  => dirname(__FILE__).'/../../../web/images/products/eve.jpg',
    'is_new' => false,
  )))
;

Wenn man mit click() einen Button anklickt, kann man die Werte für Felder, die wir überschreiben wollen, mit übergeben. In diesem Beispiel ändern wir die Werte der Felder price, is_new und wir laden ein Bild hoch in dem wir den vollständigen Pfad zu der Datei angeben, die wir hochladen wollen.

Nachdem wir überprüft haben, dass wir wieder auf die Startseite weitergeleitet worden sind, können wir testen ob unsere Änderungen aufgenommen wurden:

$browser->
  isRedirected()->
  followRedirect()->
  isStatusCode(200)->
  isRequestParameter('module', 'product')->
  isRequestParameter('action', 'index')
  checkResponseElement('h2:contains("NEU")', 1)->
  checkResponseElement(sprintf('img[src$="%s"]', sha1('eve.jpg').'.jpg'))
;

Jetzt können wir uns ausloggen:

$browser->
  click('Ausloggen')->
  isRequestParameter('module', 'user')->
  isRequestParameter('action', 'signout')->
  isRedirected()->
  followRedirect()->
  isStatusCode(200)->
  isRequestParameter('module', 'product')->
  isRequestParameter('action', 'index')->
  checkResponseElement('body', '/Einloggen/')->
  checkResponseElement('body', '!/Ausloggen/')
;

Ab jetzt, immer wenn wir Änderungen am Code vornehmen, lassen wir die Funktionstests laufen, um sicher zu sein, dass wir keine Features dabei kaputt gemacht haben:

$ php symfony test:functional frontend productActions

Anwendungsspezifische Browser

Die Funktionstests, die wir geschrieben haben, sind relativ simpel und natürlich müssen wir noch etwas mehr Code schreiben um alle Features der Webseite abzudecken. Und während die Test-Suite wächst, werden wir voraussichtlich einiges an Code kopieren und mehrfach nutzen. So zum Beispiel der Einloggen- und Ausloggen-Prozess. Um zu verhindern den selben Prozess, immer und immer wieder zu wiederholen, ist es eine gute Idee, eine, auf die Anwendung zugeschnittene, Browser-Klasse zu schreiben:

class StoreBrowser extends sfTestBrowser
{
  public function signin() // einloggen
  {
    return $this->
      get('/user/signin')->
      isRedirected()->
      isRequestParameter('module', 'user')->
      isRequestParameter('action', 'signin')->
      followRedirect()->
      isStatusCode(200)->
      isRequestParameter('module', 'product')->
      isRequestParameter('action', 'index')->
      checkResponseElement('body', '!/Einloggen/')->
      checkResponseElement('body', '/Ausloggen/')
    ;
  }
 
  public function signout() // ausloggen
  {
    return $this->
 
      get('/user/signout')->
      isRequestParameter('module', 'user')->
      isRequestParameter('action', 'signout')->
      isRedirected()->
      followRedirect()->
      isStatusCode(200)->
      isRequestParameter('module', 'product')->
      isRequestParameter('action', 'index')->
      checkResponseElement('body', '/Einloggen/')->
      checkResponseElement('body', '!/Ausloggen/')
    ;
  }
}

Hier ist ein simpler Test, der sich nur einloggt und dann wieder ausloggt:

include(dirname(__FILE__).'/../../bootstrap/functional.php');
 
// Datenbank mit fixtures initialisieren
$databaseManager = new sfDatabaseManager($configuration);
$loader = new sfPropelData();
$loader->loadData(sfConfig::get('sf_data_dir').'/fixtures');
 
$browser = new StoreBrowser();
 
$browser->
  signin()->
 
  // tue etwas während eingeloggt
 
  signout()
;

Das ist alles für Heute. Da wir nun von unserer Test-Suite unterstützt werden, kann Vince bequem in Teil 3 mit der Refaktorisierung anfangen.

Im offiziellen Symfony-Blog wird derzeit eine fünfteilige Artikelserie über das Thema Refaktorisierung (Refactoring) veröffentlicht. Da die Inhalte sehr interessant sind, habe ich mich entschieden eine deutsche Version der Artikel zu entwerfen.

Dies ist also Teil 1 von “Refaktorisierung mit Symfony”, eine freie, deutsche Übersetzung und leicht abgewandelte Version des Originalartikels “Call the expert: A refactoring story (Part 1/5)” veröffentlicht im offziellen Symfony-Blog.

Wikipedia über Refaktorisierung:

“Refactoring (deutsch auch Refaktorisierung, Refaktorierung oder schlicht Umgestaltung) bezeichnet in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des beobachtbaren Programm-Verhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken.”

Die Geschichte

Vor einiger Zeit fragte Vince, ein erfahrener PHP-Entwickler, den Symfony-Entwickler Fabien Potencier, ob er einen Blick auf sein erstes Symfony-Projekt, ein Onlineshop, werfen könnte.

Sein Kunde war sehr glücklich, dass die Webseite problemlos lief. Auch Vince war zufrieden, da er die Webseite pünktlich fertigstellte. Aber er war sich nicht so sicher über die Qualität seines Codes.

Also schrieb er Fabien an, um Feedback zu der Qualität seines Codes zu bekommen. Statt ihm nur per E-Mail zu antworten, lud ihn Fabien zu Sensio Labs ein um an einer echten Refactoring-Session teilzunehmen.

Da manche seiner Fehler recht häufig in Projekten passieren, hat sich Fabien entschieden den Ablauf des Refactoring im offiziellen Symfony-Blog wiederzugeben, in der Hoffnung, das andere Symfony-Entwickler ebenso davon lernen können, wie es Vince getan hat.

Heute, in Teil 1, beschreiben wir ein paar Features der Webseite und schauen uns ein paar kurze Codeabschnitte an. Der eigentliche Refacorting-Prozess beginnt dann in Teil 2.

Das Projekt wurde mit Symfony 1.1 entwickelt.

Das Schema

Das Datenbankschema besteht aus zwei Tabellen, einer Produkt-Tabelle (product) und einer Kategorie-Tabelle (category):

# config/schema.yml
propel:
  product:
    title:       { type: varchar(255), required: true }
    image:       varchar(255)
    description: longvarchar
    price:       { type: decimal, required: true }
    is_new:      boolean
    is_in_stock: boolean
    created_at:  timestamp
    category_id: ~
 
  category:
    name: varchar(255)

Die Startseite

Die Startseite der Webseite besteht aus einer Liste aller verfügbaren Produkte (is_in_stock auf true gesetzt).

Alle Features, die wir später refaktorisieren, werden vom Produktmodul (product) gesteuert.

Hier ist die index-Action, welche die Startseite steuert:

// apps/frontend/modules/product/actions/actions.class.php
public function executeIndex()
{
  $criteria = new Criteria();
  $criteria->add(ProductPeer::IS_IN_STOCK, true);
  $criteria->addAscendingOrderByColumn(ProductPeer::PRICE);
  $criteria->setLimit(10);
 
  $this->products = ProductPeer::doSelectJoinCategory($criteria);
 
  $this->getResponse()->setTitle('Alle Produkte');
  $this->getResponse()->addStylesheet('homepage.css');
 
  return sfView::SUCCESS;
}

Und das dazugehörige Template indexSucess.php:

 
<h1>Unsere Produkte</h1>
 
<?php foreach ($products as $product): ?>
  <div>
    <h2>
      <?php echo $product->getTitle() ?>
      <?php if ($product->getIsNew()): ?><span style="margin-left: 10px; color: #e55">NEU!</span><?php endif; ?>
    </h2>
    <div style="margin-bottom: 10px">
      <em>Kategorie</em>: <?php echo $product->getCategory()->getName() ?> -
      <em>Preis</em>: Only $<?php echo $product->getPrice() ?> - 
      <?php if (in_array($product->getId(), array_keys($sf_user->getAttribute('favorites', array())))): ?>
        <a href="<?php echo url_for('product/removeFromFavorites?id='.$product->getId()) ?>"><img src="/images/favorite.png" /></a>
      <?php else: ?>
        <small><?php echo link_to('Zu den Favoriten hinzufügen', 'product/addToFavorites?id='.$product->getId()) ?></small>
      <?php endif; ?>
    </div>
    <div>
      <div style="float: left">
        <img width="100px" src="/images/products/<?php echo $product->getImage() ?>" />
      </div>
      <p>
        <?php echo $product->getDescription() ?>
        <?php if ($sf_user->isAuthenticated()): ?>
          <p style="text-align: right"><a href="<?php echo url_for('product/edit?id='.$product->getId()) ?>">Produkt editieren</a></p>
        <?php endif; ?>
      </p>
      <br style="clear: both" />
    </div>
    <div style="text-align: right">
      <?php echo link_to(image_tag('/images/add_to_cart.png'), 'product/buy?id='.$product->getId()) ?>
    </div>
    <hr />
  </div>
<?php endforeach; ?>

Die Favoriten

Wie du eventuell schon auf dem Screenshot gesehen hast, kann der Benutzer Produkte zu seinen Favoriten hinzufügen. Das Feature ist recht einfach: Man klickt auf den “Zu den Favoriten hinzufügen”-Link um ein Produkt seinen Favoriten hinzuzufügen und man klickt auf das Sternsymbol um es wieder zu entfernen.

Die Favoriten werden von den Methoden executeAddToFacorites() und executeRemoveFromFavorites() des Produktmoduls verarbeitet:

public function executeAddToFavorites()
{
  $product = ProductPeer::retrieveByPk($this->getRequestParameter('id'));
  $this->forward404Unless($product);
 
  $favorites = $this->getUser()->getAttribute('favorites');
  $favorites[$product->getId()] = true;
 
  $this->getUser()->setAttribute('favorites', $favorites);
 
  $this->redirect('product/index');
}
 
public function executeRemoveFromFavorites()
{
  $product = ProductPeer::retrieveByPk($this->getRequestParameter('id'));
  $this->forward404Unless($product);
 
  $favorites = $this->getUser()->getAttribute('favorites');
  unset($favorites[$product->getId()]);
 
  $this->getUser()->setAttribute('favorites', $favorites);
 
  $this->redirect('product/index');
}

Produkte editieren

Als eingeloggter Administrator können die Produktinformationen auch editiert werden.

Diese Seite wird von der edit-Action verarbeitet:

public function executeEdit()
{
  $this->product = ProductPeer::retrieveByPk($this->getRequestParameter('id'));
  if (is_null($this->product))
  {
    $this->forward404();
  }
 
  $this->form = new ProductForm($this->product);
 
  if (sfRequest::POST == $this->getRequest()->getMethod())
  {
    $this->form->bind($this->getRequestParameter('product'), $this->getRequest()->getFiles('product'));
    if ($this->form->isValid())
    {
      // aktuelles produkt holen
      $product = $this->form->getObject();
      $image = $this->form->getValue('image');
      $currentImage = $product->getImage();
 
      if ($image)
      {
        // altes bild entfernen
        if (file_exists($file = sfConfig::get('sf_web_dir').'/images/products/'.$currentImage))
        {
          unlink($file);
        }
      }
 
      // produkt aktualisieren
      $product = $this->form->updateObject();
 
      if ($image)
      {
        // bild speichern
        $filename = sha1($image->getOriginalName()).$image->getExtension($image->getOriginalExtension());
        $image->save(sfConfig::get('sf_web_dir').'/images/products/'.$filename);
 
        $product->setImage($filename);
      }
      else
      {
        $product->setImage($currentImage);
      }
 
      // produkt speichern
      $product->save();
 
      $this->getUser()->setFlash('notice', sprintf('Das Produkt "%s" wurde erfolgreich aktualisiert.', $product->getTitle()));
      $this->redirect('product/index');
    }
  }
}

Und das Template editSuccess.php:

<h1>Editieren "<?php echo $product->getTitle() ?>" <small>#<?php echo $product->getId() ?></small></h1>
 
<p><?php echo link_to('Zurück zur Homepage', '@homepage') ?></p>
 
<form action="<?php echo url_for('product/edit?id='.$product->getId()) ?>" method="POST" enctype="multipart/form-data">
  <table cellspacing="0">
    <?php echo $form ?>
    <tr>
      <td colspan="2" style="text-align: right"><input type="submit" value="Speichern" /></td>
    </tr>
  </table>
</form>

Dies ist alles für Heute. Der eigentliche Refactoring-Prozess beginnt im nächsten Teil. In der Zwischenzeit nimm dir die Zeit den Code zu lesen und überleg dir, was du refaktorisieren würdest, wie und warum.

Bisherige Auswahl:

• New in symfony 1.2: Small things matter
• New in symfony 1.2: Toward a RESTful architecture (Part 1)
• New in symfony 1.2: Customize the Web Debug Toolbar
• Propel 1.3, Doctrine 1.0, and symfony 1.2

Ich wollte die Tage das sfFeed2Plugin benutzen und musste feststellen, dass auf dem einfachen Weg über den “symfony”-Befehl die Installation verweigert wird, weil das Plugin für 1.0 ist. Musste ich mir leider kurzer Hand was eigenes Basteln um die News in einen RSS-Feed zu quetschen.

Weiteres zum RC1 gibt’s im Symfony-Blog: Symfony 1.1.0 RC1 is out.

P.S.: In den folgenden Wochen ist mit einem RC2 zu rechnen.

class myActions extends sfActions
{
  public function setDescription($description)
  {
  	$response = $this->getResponse();
  	$response->addMeta('description', $description);
  }

  public function setKeywords($keywords)
  {
  	$response = $this->getResponse();
  	$response->addMeta('keywords', $keywords);
  }
}

Nun lassen sich in jeder “Action”, die von myActions abgeleitet ist statt direkt von sfActions, die Meta-Tags für Keywords und Beschreibungen bequem dynamisch anpassen, z.B.:

public function executeMyAction()
{
  $this->setDescription('.... beschreibung .... ');
  $this->setKeywords('foo, bar, foobar, ...');
}

Ich warte ja immer noch ganz sehnlich auf Symfony 1.1, das viele Neuerungen mitbringen wird. Zur Zeit migriere ich eine private Bastelei von 1.0.* auf 1.1 (svn) und es ist doch einiges zu beachten. Zwar bringt Symfony 1.1 ein Plugin mit, das die Kompatibilität zu 1.0.* herstellt, aber wenn man das Projekt direkt auf 1.1 ohne Rückwärtskompatibilitäten umstellen möchte, dann gibt’s viel zu beachten und zu entdecken

Aber zurück zu Symfony 1.0.11 und den Neuerungen/Änderungen:

• r6765, r6766: fixed error message in getPresentationFor() (closes #1527)
• r6764: fixed logic error in sfPager class affects haveToPaginate() method (closes #1512)
• r6768, r6769: added mime types caching in sfWebRequest (closes #1811, #1846)
• r6761, r6762: fixed content type charset on non text/* content-type (closes #1811, #1968)
• r6743: doc: fixed typos (closes #2580, #2596, #2518)
• r6740, r6741: fixed sequences bug for postgresql (closes #2584)
• r6987, r6988: fixed caching-Bug of file sfWebresponse.class.php (#2764)
• r6649: fixed value for ‘Content-Type’ HTTP meta header is repeated (closes #1756, #2557, #2402, #2398)
• r6648: fixed call to undefined method sfResponse::sendHttpHeaders (closes #2412)

Symfony Blog: symfony 1.0.11 is out

Eine Lösung bietet der Artikel Dynamically adjusting your page title in symfony. Mit ein wenig Anpassung kann man damit auch mehrere Ebenen unterstützen:

class myActions extends sfActions

{

  public function setPageTitle($titles)

  {

    $response = $this->getResponse();

    if(!is_array($titles)) $titles = array($titles);

    $mainTitle = sfConfig::get('app_title');

    $delimeter = ' '.sfConfig::get('app_delimeter', '»').' ';

    $response->setTitle($mainTitle.$delimeter.implode($delimeter, $titles), false);

  }

}

Jede actions-Klasse, die jetzt von myActions abgeleitet ist, statt von sfActions kann nun einen dynamischen Titel setzen:

class moduleActions extends myActions

{

  public function executeIndex()

  {

    $this->setPageTitle(array(

      'Blogs',

      'Antihype',

      'Seite 5'

    ));

    return sfView::SUCCESS;

  }

}

Der Seitenname und das Trennzeichen werden in der app.yml angegeben:

app:

  title:         wordpress.com

  delimeter:     »

Mit dieser Konfiguration würde das obige Beispiel folgenden Seitentitel setzen:

wordpress.com » Blogs » AntiHype » Seite 5

Für Mehrsprachigkeit bietet Symfony ja schon einiges an Möglichkeiten (The Definitive Guide to symfony – Chapter 13 – I18n And L10n). Mittels der Methode setCulture kann einem Besucher eine “Sprache” zugeordnet werden und mit Hilfe von XLIFF-Dateien können verschiedene Sprachversionen der Webseite angelegt werden. Was also nur noch fehlt ist eine Möglichkeit die “Culture” entsprechend der Subdomain zu setzen.

Den entsprechenden Hinweis bietet dabei das Askeet-Tutorial Tag 18. Ein Filter ermöglicht vor Ausführung des Controllers eigenen Code auszuführen. Dort können wir den Hostnamen auslesen und entsprechend der Subdomain die “Culture” des Besuchers setzen.

In einzelnen Schritten bedeutet dies also:

1. Filter deklarieren in /projekt/apps/frontend/config/filters.yml

languageFilter:

  class: languageFilter

2. Filter Klasse anlegen in /projekt/apps/frontend/lib/languageFilter.php

class languageFilter extends sfFilter

{

  public function execute($filterChain)

  {

     if($this->isFirstCall())

     {

       $hostname = $this->getContext()->getRequest()->getHost();

       if($pos = strpos($hostname, '.'))

       {

          $language = substr($hostname, 0, $pos);

          $this->getContext()->getUser()->setCulture($language);

       }

     }

     $filterChain->execute();

  }

}

Was passiert im Code? Mittels $this->isFirstCall() wird überprüft ob dies der erste Aufruf des Filters ist, denn durch die Nutzung von forward() im Controller wird der Filter sonst jedes mal ausgeführt, dies ist allerdings nicht nötig.

Mittels strpos und substr wird überprüft ob der Hostname einen Punkt “.” enthält und falls ja wird alles vor dem ersten Punkt extrahiert und als “Culture” gesetzt.

Damit die Kette von Filtern nicht unterbrochen wird muss ein Filter immer mit $filterChain->execute(); enden, damit der nächste Filter ausgeführt wird.

Dieser Code soll nur kurz die Möglichkeit skizzieren. Für eine sinnvolle Nutzung fehlen noch ein paar Elemente:

• In den meisten Fällen dürfte nicht jede Subdomain sinnvoll sein und sollte daher auch nicht zugelassen sein. Ein Abgleich mit einer Liste von ‘erlaubten’ Subdomains sollte dabei helfen.
• Man sollte sich überlegen was in Fällen passiert in denen keine Subdomain definiert ist. Möglichkeiten wäre eine Sprachauswahl-Seite oder eine automatische Weiterleitung auf eine Sprachversion.

Nachdem ich inzwischen schon ein wenig Erfahrung mit dem Framework sammeln konnte, möchte ich diese jetzt nutzen um den ein oder anderen Artikel auch symfony zu widmen.

Zunächst bleibt erstmal der Hinweis auf die gute und umfangreiche Dokumentation und den kurzen Überblick bei Wikipedia.