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

• http://blog.wordpress-deutschland.org/2008/10/24/wordpress-263-sicherheitsrelease.html

• The phpMyAdmin Project

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.

Meine IDE der Wahl für PHP ist weiterhin:

• Eclipse PDT (PHP Development Tools) als Basis
• Subclipse-Erweiterung zur Integration von SVN-Unterstützung
• Symfoclipse-Erweiterung für einen brauchbaren YAML-Editor und Symfony-Kommandos direkt aus Eclipse

Weitere Infos:

• Golem.de: Zend Studio nun auf Basis von Eclipse

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