The symfony Cookbook

Wanneer een fout optreed, of het nou een pagina is die niet gevonden wordt, een internal server error, of een andere uitzondering, symfony zal een foutmeldingspagina weergeven. De inhoud van de pagina is afhankelijk van de omgeving en het formaat van de request.

Laten we een voorbeeld nemen om het makkelijk te maken om uit te leggen. Je hebt een applicatie met een API module die HTML, XML of JSON representatie teruggeeft van een Article model.

Here is de routing configuratie die het laat werken:

// apps/frontend/config/routing.yml
api_article:
  url:   /api/article/:id.:sf_format
  param: { module: api, action: article }
  requirements:
    sf_format: (?:html|xml|json)

En de bijbehorende module:

class apiActions extends sfActions
{
  public function executeArticle($request)
  {
    $this->article = ArticlePeer::retrieveByPK($request->getParameter('id'));
 
    $this->forward404Unless($this->article);
  }
 
  // ...
}

Wanneer je een niet bestaande id meegeeft in de request, zal de actie worden doorgestuurd naar de 404 pagina. Als je het HTML formaat gebruikt (http://localhost/frontend_dev.php/api/article/1.html) in de ontwikkelomgeving, dan zal je een foutmelding krijgen die er zo uitziet:

In de productie omgeving (http://localhost/frontend_dev.php/api/article/1.html), zal de pagina voor veiligheidsredenen er erg anders uit zien:

Laten we eens kijken hoe het werkt als we het formaat naar XML zetten in de ontwikkelomgeving (http://localhost/frontend_dev.php/api/article/1.xml):

En nu in de productieomgeving (http://localhost/api/article/1.xml):

Zoals je zelf kan zien is de foutmelding die nu terug wordt gestuurd door symfony in het opgevraagde formaat, XML.

Dit voorbeeld zal demonstreren hoe je de foutmelding kan aanpassen voor een 404 pagina, maar hetzelfde geld voor elke andere niet afgevangen exception.

Je kan zelfs van ieder formaat de output aanpassen door templates aan de project directory (config/error/) of applicatie directory (apps/frontend/config/error) toe te voegen.

Bijvoorbeeld, om de output voor XML foutmeldingen aan te passen, maak een config/error/error.xml.php bestand aan. Symfony is slim genoeg om de aangepaste template te gebruiken wanneer die bestaan in plaats van de standaard:

<?xml version="1.0" encoding="<?php echo sfConfig::get('sf_charset', 'UTF-8') ?>"?>
<error>
   <code><?php echo $code ?></code>
   <message><?php echo $text ?></message>
</error>

Wanneer je een eigen foutmeldingstemplate maakt, heb je de beschikking over de volgende variabelen:

• $code: De response status code
• $text: De response status text
• $name: De classnaam van de exception
• $message: Het bericht van de exception
• $traces: Een array met de volledige PHP stack trace
• $format: Het opgevraagde formaat

Het is ook mogelijk om de output van de ontwikkelomgeving aan te passen, zelfs al is dit minder interessant, door het aanmaken van een config/error/exception.xml.php bestand.

De standaard templates staan in de lib/exception/data/ directory van symfony en zijn een goed startpunt voor aangepaste templates.

Wanneer je je eigen formaat maakt, zal je de foutmeldingstemplates voor dit formaat zelf moeten maken (config/error/error.FORMAAT_NAAM.php en config/error/exception.FORMAAT_NAAM.php).

Om deze taak makkelijker te maken, kan je bestaande error templates includen. Bijvoorbeeld, als je formaat lijkt op XML, kan je de standaard XML foutmeldingstemplates includen:

<?php include sfException::getTemplatePathForError('xml', true) ?>

Formaat ondersteuning is nog een voorbeeld van symfony 1.2 die HTTP zo veel mogelijk omarmt.