1. Un blog simple en PHP à plat▲
Dans ce chapitre, vous allez construire une application de blog en utilisant seulement du PHP à plat. Pour commencer, créez une page qui affiche les données d'entrée du blog qui ont été enregistrées de façon persistante dans la base de données. L'écrire en PHP à plat est rapide et vous donnera ceci :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
<?php
// index.php
$link = new PDO("mysql:host=localhost;dbname=blog_db", 'myuser', 'mypassword');
$result = $link->query('SELECT id, title FROM post');
?>
<!DOCTYPE html>
<html>
<head>
<title>List of Posts</title>
</head>
<body>
<h1>List of Posts</h1>
<ul>
<?php while ($row = $result->fetch(PDO::FETCH_ASSOC)): ?>
<li>
<a href="/show.php?id=<?= $row['id'] ?>">
<?= $row['title'] ?>
</a>
</li>
<?php endwhile ?>
</ul>
</body>
</html>
<?php
$link = null;
?>
Ceci est rapide à écrire et à exécuter, et votre application grandissant deviendra impossible à maintenir. Il y a plusieurs problèmes qui nécessitent d'être traités.
- Pas de traitement d'erreurs : qu'adviendra-t-il si la connexion à la base de données échoue ?
- Organisation pauvre : si l'application grossit, ce fichier unique deviendra de moins en moins maintenable. Où placer votre code qui va gérer la soumission d'un formulaire ? Comment pouvez-vous valider les données ? Où devrait se trouver le code pour l'envoi d'e-mail ?
- Code difficile à réutiliser : puisque tout est dans un seul fichier, il n'y a aucun moyen de réutiliser une partie de l'application pour les autres « pages » du blog.
Un autre problème non mentionné ici est le fait que la base de données est liée à MySQL. Bien que non couvert ici, Symfony intègre entièrement Doctrine, une bibliothèque dédiée à l'abstraction et au mappage de bases de données.
2. Isoler la présentation▲
Le code peut immédiatement profiter de la séparation entre la logique de l'application et le code qui prépare la « présentation » HTML :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
// index.php
$link = new PDO("mysql:host=localhost;dbname=blog_db", 'myuser', 'mypassword');
$result = $link->query('SELECT id, title FROM post');
$posts = array();
while ($row = $result->fetch(PDO::FETCH_ASSOC)) {
$posts[] = $row;
}
$link = null;
// include the HTML presentation code
require 'templates/list.php';
Le code HTML est maintenant stocké dans un fichier séparé (templates/list.php), lequel est principalement un fichier HTML qui utilise une syntaxe similaire à PHP :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
<!-- templates/list.php -->
<!DOCTYPE html>
<html>
<head>
<title>List of Posts</title>
</head>
<body>
<h1>List of Posts</h1>
<ul>
<?php foreach ($posts as $post): ?>
<li>
<a href="/show.php?id=<?= $post['id'] ?>">
<?= $post['title'] ?>
</a>
</li>
<?php endforeach ?>
</ul>
</body>
</html>
Par convention, le fichier qui contient toute la logique de l'application, index.php, est désigné par « contrôleur ». Le terme contrôleur est un terme que vous entendrez beaucoup, indépendamment du langage ou du Framework que vous utilisez. Il se réfère simplement à la zone de votre code qui traite les entrées utilisateur et prépare les réponses.
Dans l'exemple ci-dessus, le contrôleur prépare les données depuis la base de données et inclut ensuite un template pour présenter ces données. Avec un contrôleur isolé, vous pourriez juste changer le fichier de template pour présenter les entrées du blog dans un autre format (ex. : list.json.php pour le format JSON).
3. Isoler la logique de l'application (Domaine)▲
Jusqu'à maintenant, l'application contient uniquement une page. Mais qu'en sera-t-il si une seconde page est nécessaire pour utiliser la même connexion de base de données, ou encore la même rangée de posts du blog ? Réorganisons le code pour que le comportement principal de celui-ci et des fonctions d'accès aux données de l'application soit isolé dans un nouveau fichier nommé model.php :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
// model.php
function open_database_connection()
{
$link = new PDO("mysql:host=localhost;dbname=blog_db", 'myuser', 'mypassword');
return $link;
}
function close_database_connection(&$link)
{
$link = null;
}
function get_all_posts()
{
$link = open_database_connection();
$result = $link->query('SELECT id, title FROM post');
$posts = array();
while ($row = $result->fetch(PDO::FETCH_ASSOC)) {
$posts[] = $row;
}
close_database_connection($link);
return $posts;
}
Le nom de fichier model.php est utilisé, car la logique et l'accès aux données d'une application sont traditionnellement connus sous le nom de couche « modèle ». Dans une application bien organisée, la majorité du code représentant votre « logique business » devrait résider dans le modèle (en opposition au placement dans le contrôleur). Et contrairement dans cet exemple, seule une portion (ou aucune) du modèle est actuellement concernée par l'accès à la base de données.
Le contrôleur (index.php) est maintenant très simple :
// index.php
require_once 'model.php';
$posts = get_all_posts();
require 'templates/list.php';Maintenant, la seule tâche du contrôleur est de récupérer les données de la couche modèle de l'application (le modèle) et d'appeler un template pour présenter ces données. Voici un exemple vraiment très simple du modèle-vue-contrôleur.
4. Isoler l'agencement▲
À ce point, l'application a été réagencée en trois parties distinctes offrant de multiples avantages et l'opportunité de réutiliser la plupart des éléments sur différentes pages.
La seule partie du code qui ne peut pas être réutilisée est la couche de l'agencement. Réglons cela en créant un nouveau fichier templates/layout.php :
Le template (templates/list.php) peut maintenant être simplifié pour « étendre » templates/layout.php :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
<!-- templates/list.php -->
<?php $title = 'List of Posts' ?>
<?php ob_start() ?>
<h1>List of Posts</h1>
<ul>
<?php foreach ($posts as $post): ?>
<li>
<a href="/show.php?id=<?= $post['id'] ?>">
<?= $post['title'] ?>
</a>
</li>
<?php endforeach ?>
</ul>
<?php $content = ob_get_clean() ?>
<?php include 'layout.php' ?>
Vous avez maintenant une configuration qui vous permettra de réutiliser la disposition. Malheureusement, pour le faire, vous serez obligé d'utiliser quelques fonctions PHP laides (ob_start(), ob_get_clean()) dans le template. Symfony utilise un composant de templating qui permet d'effectuer cela proprement et facilement. Vous allez voir cela en action rapidement.
5. Ajouter au blog la page « afficher »▲
La page « liste » du blog a maintenant été réagencée et le code est donc mieux organisé et réutilisable. Pour le prouver, ajoutez au blog une page « afficher », laquelle affiche un post individuel du blog identifié par un paramètre d'identification (id) dans la requête.
Pour commencer, créez une nouvelle fonction dans le fichier model.php qui récupère un résultat individuel du blog par l'id communiqué :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
// model.php
function get_post_by_id($id)
{
$link = open_database_connection();
$query = 'SELECT created_at, title, body FROM post WHERE id=:id';
$statement = $link->prepare($query);
$statement->bindValue(':id', $id, PDO::PARAM_INT);
$statement->execute();
$row = $statement->fetch(PDO::FETCH_ASSOC);
close_database_connection($link);
return $row;
}
Ensuite, créez un nouveau fichier nommé show.php - le contrôleur pour cette nouvelle page :
2.
3.
4.
5.
6.
// show.php
require_once 'model.php';
$post = get_post_by_id($_GET['id']);
require 'templates/show.php';
Enfin, créez le nouveau fichier de template : templates/show.php, pour interpréter le post individuel du blog :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
<!-- templates/show.php -->
<?php $title = $post['title'] ?>
<?php ob_start() ?>
<h1><?= $post['title'] ?></h1>
<div class="date"><?= $post['created_at'] ?></div>
<div class="body">
<?= $post['body'] ?>
</div>
<?php $content = ob_get_clean() ?>
<?php include 'layout.php' ?>
Créer la seconde page est maintenant très simple et aucun code n'est dupliqué. Cette page introduit également des problèmes persistants qu'un framework pourra résoudre pour vous. Par exemple un id de paramètre requête invalide ou manquant peut déclencher un crash de la page. Ce serait mieux si cela causait un rendu de page 404, mais cela ne peut pas vraiment être fait facilement actuellement. Pire, si vous avez oublié de nettoyer le paramètre id via la fonction intval(), votre base de données entière pourrait être exposée à une attaque par injection SQL.
Un autre problème majeur est que chaque fichier de contrôleur individuel doit inclure le fichier model.php. Qu'en sera-t-il si chaque fichier de contrôleur doit soudainement inclure un fichier additionnel pour effectuer d'autres tâches globales (ex. : renforcer la sécurité) ? À l'heure actuelle, ce code devait être ajouté à chaque fichier de contrôleur. Si vous oubliez d'inclure quelque chose dans un fichier, il faut espérer que ça ne se rapporte pas à la sécurité…
6. Un contrôleur frontal à la rescousse▲
La solution est d'utiliser un contrôleur frontal : un unique fichier PHP à travers lequel toutes les requêtes sont traitées. Avec un contrôleur frontal, les URI pour les applications changent légèrement, mais commencent à être plus flexibles.
Sans contrôleur frontal :
/index.php => page de la liste des posts du blog (index.php exécuté) ;
/show.php => page d'affichage d'un post du blog (show.php exécuté).
Avec index.php comme contrôleur frontal :
/index.php => page de la liste des posts du blog (index.php exécuté) ;
/index.php/show => page d'affichage d'un post du blog (index .php exécuté).
En utilisant les règles de réécriture (rewrite) de la configuration du serveur Web, la partie index.php de l'URI n'est plus nécessaire et vous aurez des URL simples et propres (par exemple: /show ).
Lors de l'utilisation d'un contrôleur frontal, un seul fichier PHP (index.php dans ce cas) traite les requêtes. Pour la page d'affichage de post du blog, /index.php/show, c'est le fichier index.php qui sera exécuté, lequel est maintenant responsable des requêtes de routage interne, basé sur l'URI totale. Comme vous allez le voir, un contrôleur frontal est un outil vraiment puissant.
7. Créer le contrôleur frontal▲
Vous êtes sur le point de passer une grande étape avec votre application. Avec un seul fichier gérant les requêtes, vous pouvez centraliser les choses telles que la gestion de la sécurité, le chargement de configuration, et le routage. Dans cette application, index.php doit maintenant être suffisamment intelligent pour traiter la page de liste (list) des posts du blog ou celle d'affichage de post individuel (show), basé sur l'URI demandée :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
// index.php
// charge et initialise toutes les bibliothèques globales
require_once 'model.php';
require_once 'controllers.php';
// route les requêtes en interne
$uri = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
if ('/index.php' === $uri) {
list_action();
} elseif ('/index.php/show' === $uri && isset($_GET['id'])) {
show_action($_GET['id']);
} else {
header('HTTP/1.1 404 Not Found');
echo '<html><body><h1>Page non trouvée</h1></body></html>';
}
Pour un souci d'organisation, les deux contrôleurs ( index.php et show.php) sont maintenant des fonctions PHP, et chacun a été déplacé dans un autre fichier : controllers.php :
Comme contrôleur frontal, index.php a pris un rôle entièrement nouveau, qui inclut le chargement de bibliothèques de noyau et de routage de l'application, de sorte qu'un contrôleur ou un autre (les fonctions list_action() et show_action()) est appelé. En réalité, le contrôleur frontal commence à ressembler et agir comme le mécanisme de Symfony pour gérer et router les requêtes.
Mais faites attention à ne pas confondre les termes « contrôleur frontal » et « contrôleur ». En temps normal, votre application n'utilisera que seulement le contrôleur frontal pour démarrer votre code. Vous aurez plusieurs fonctions qui serviront de contrôleurs : une pour chaque page.
Un autre avantage d'un contrôleur frontal est la flexibilité des URL. Notez que l'URL de la page d'affichage de post du blog pourrait être changée de /show en /read en modifiant le code à un seul endroit. Auparavant, un fichier entier aurait dû être renommé. Dans Symfony, les URL sont encore plus flexibles.
Maintenant, l'application a évolué depuis un unique fichier PHP vers une structure qui est organisée et permet la réutilisation de code. Vous devriez être plus heureux, mais loin d'être satisfait. Par exemple, le système de « routage » est inconstant, et ne devrait pas reconnaître que la page de liste des posts du blog (index.php) devrait être accessible aussi via « / » (si les règles de rewrite Apache ont été ajoutées). Aussi, plutôt que de développer le blog, beaucoup de ce temps a été passé à travailler sur l'architecture du code (ex. : routage, appel des contrôleurs, templates, etc.). Plus de temps devrait encore être passé pour la soumission des formulaires, la validation des entrées, le logging, et la sécurité. Pourquoi devriez-vous réinventer des solutions à tous ces problèmes routiniers ?
8. Ajouter une touche de Symfony▲
Symfony arrive à la rescousse. Avant d'utiliser Symfony, vous devez le télécharger. Ceci peut être effectué via Composer, qui s'occupe de télécharger la version stable et toutes ses dépendances et fournit un autoloader. Un autoloader est un outil qui permet de démarrer l'utilisation de classes PHP sans inclure explicitement le ou les fichiers les contenant.
Dans votre dossier racine, créez un fichier composer.json avec le contenu suivant :
2.
3.
4.
5.
6.
7.
8.
{
"require": {
"symfony/symfony": "3.1.*"
},
"autoload": {
"files": ["model.php","controllers.php"]
}
}
Ensuite, téléchargez Composer et lancez-le avec la commande suivante, laquelle va télécharger Symfony dans un dossier vendor/ :
$ composer install
En plus du téléchargement de vos dépendances, Composer génère un fichier PHP vendor/autoload.php, qui effectue le chargement automatique de tous les fichiers du framework Symfony aussi bien que les fichiers mentionnés dans la section autoload de votre fichier composer.json.
Le cœur de la philosophie de Symfony est basé sur le principe que le travail principal d'une application est d'interpréter chaque requête et retourner une réponse. À cette fin, Symfony fournit deux classes : une classe Request et une classe Response. Ces classes sont une représentation orientée objet des requêtes et réponses HTTP brutes retournées. Utilisez-les pour améliorer le blog :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
// index.php
require_once 'vendor/autoload.php';
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
$request = Request::createFromGlobals();
$uri = $request->getPathInfo();
if ('/' === $uri) {
$response = list_action();
} elseif ('/show' === $uri && $request->query->has('id')) {
$response = show_action($request->query->get('id'));
} else {
$html = '<html><body><h1>Page Not Found</h1></body></html>';
$response = new Response($html, Response::HTTP_NOT_FOUND);
}
// echo the headers and send the response
$response->send();
Les contrôleurs sont maintenant capables de retourner un objet Response. Pour rendre cela plus facile, vous pouvez ajouter une nouvelle fonction render_template(), laquelle agit un peu plus rapidement que le moteur de Templating Symfony :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
// controllers.php
use Symfony\Component\HttpFoundation\Response;
function list_action()
{
$posts = get_all_posts();
$html = render_template('templates/list.php', array('posts' => $posts));
return new Response($html);
}
function show_action($id)
{
$post = get_post_by_id($id);
$html = render_template('templates/show.php', array('post' => $post));
return new Response($html);
}
// helper function to render templates
function render_template($path, array $args)
{
extract($args);
ob_start();
require $path;
$html = ob_get_clean();
return $html;
}
En apportant une petite partie de Symfony, l'application est plus flexible et fiable. L'objet Request fournit un moyen sûr pour accéder à des informations sur les requêtes HTTP. La méthode getPathInfo() retourne spécialement une URI nettoyée (retournant toujours /show et jamais /index.php/show). De sorte que même si l'utilisateur se rend sur la page /index.php/show, l'application est suffisamment intelligente pour router la requête via show_action().
L'objet Response donne de la flexibilité lors de la construction de la réponse HTTP, autorisant les headers HTTP et le contenu à être ajoutés via une interface orientée objet. Et bien que la réponse de cette application soit simple, cette flexibilité sera coûteuse quand l'application va commencer à grossir.
9. L'application d'exemple dans Symfony▲
Le blog a parcouru un long chemin, mais il contient encore beaucoup de code pour une application aussi simple. Le long du chemin, vous avez fait un système simple de routage et une méthode utilisant ob_start() et ob_clean() pour interpréter les templates. Si pour une quelconque raison, vous voulez construire ce « framework » from scratch, vous pouvez au moins utiliser les composants Routing et Templating de Symfony en standalone, lesquelles règlent toujours ces problèmes.
Plutôt que de resolutionner des problèmes communs, vous pouvez laisser Symfony s'en charger pour vous. Voici la même application exemple, construite maintenant avec Symfony :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
// src/AppBundle/Controller/BlogController.php
namespace AppBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
class BlogController extends Controller
{
public function listAction()
{
$posts = $this->get('doctrine')
->getManager()
->createQuery('SELECT p FROM AcmeBlogBundle:Post p')
->execute();
return $this->render('Blog/list.html.php', array('posts' => $posts));
}
public function showAction($id)
{
$post = $this->get('doctrine')
->getManager()
->getRepository('AppBundle:Post')
->find($id);
if (!$post) {
// provoque l'affichage la la page 404 page not found
throw $this->createNotFoundException();
}
return $this->render('Blog/show.html.php', array('post' => $post));
}
}
Notez que les deux fonctions contrôleurs sont maintenant dans la « classe contrôleur' ». C'est un excellent moyen de regrouper les pages de même contexte. Les fonctions contrôleurs sont souvent aussi désignées par « actions ».
Les deux contrôleurs (ou actions) sont toujours légers. Ils utilisent chacun la bibliothèque doctrine pour récupérer les objets depuis la base de données et les composants de templating pour interpréter un template et retourner un objet Response. Le template list.php est maintenant plus simple :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
<!-- app/Resources/views/Blog/list.html.php -->
<?php $view->extend('layout.html.php') ?>
<?php $view['slots']->set('title', 'List of Posts') ?>
<h1>Liste des Posts</h1>
<ul>
<?php foreach ($posts as $post): ?>
<li>
<a href="<?php echo $view['router']->path(
'blog_show',
array('id' => $post->getId())
) ?>">
<?php echo $post->getTitle() ?>
</a>
</li>
<?php endforeach ?>
</ul>
Le layout est quasiment identique :
Le template show show.php vous est laissé en exercice. Il devrait être facile à mettre à jour en se basant sur ce qui a été fait pour le template list.php.
Quand le moteur Symfony (appelé le noyau) démarre, il a besoin d'une carte pour savoir quels sont les contrôleurs à exécuter en fonction de l'information demandée. Une carte de configuration de routage - app/config/routing.yml - fournit cette information dans un format lisible :
2.
3.
4.
5.
6.
7.
8.
# app/config/routing.yml
blog_list:
path: /blog
defaults: { _controller: AppBundle:Blog:list }
blog_show:
path: /blog/show/{id}
defaults: { _controller: AppBundle:Blog:show }
Maintenant que Symfony gère toutes les tâches banales, le contrôleur frontal web/app.php devient tout simplement inutile. Et puisqu'il ne fait que peu de chose, vous n'aurez plus besoin de le toucher une fois créé :
2.
3.
4.
5.
6.
7.
8.
// web/app.php
require_once __DIR__.'/../app/bootstrap.php';
require_once __DIR__.'/../app/AppKernel.php';
use Symfony\Component\HttpFoundation\Request;
$kernel = new AppKernel('prod', false);
$kernel->handle(Request::createFromGlobals())->send();
Le travail du contrôleur frontal consiste uniquement à initialiser le moteur Symfony (appelé aussi le noyau) et lui passer un objet Request à gérer. Le noyau de Symfony demande au routeur d'inspecter la requête. Le routeur établit la correspondance entre l'URL entrant et la route spécifique, et retourne les informations relatives à la route, y inclus le contrôleur qui sera exécuté. Le bon contrôleur correspondant à la route est exécuté et votre code à l'intérieur du contrôleur crée et retourne l'objet Response associé. Les en-têtes HTTP et le contenu de l'objet Response sont envoyés au client.
C'est quelque chose de magnifique.
10. Meilleurs templates▲
Si vous optez pour l'utiliser, Symfony vient de base avec un moteur de templates appelé Twig qui permet de faire des templates très facilement et de les lire plus simplement. Cela signifie que l'application d'exemple pourrait contenir moins de code. Regardez ! Par exemple, réécrire le template list.html.php dans Twig pourrait ressembler à ceci :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
{# app/Resources/views/blog/list.html.twig #}
{% extends "layout.html.twig" %}
{% block title %}List of Posts{% endblock %}
{% block body %}
<h1>List of Posts</h1>
<ul>
{% for post in posts %}
<li>
<a href="{{ path('blog_show', {'id': post.id}) }}">
{{ post.title }}
</a>
</li>
{% endfor %}
</ul>
{% endblock %}
Et la réécriture du template layout.html.php dans Twig ressemblera à ceci :
2.
3.
4.
5.
6.
7.
8.
9.
10.
{# app/Resources/views/layout.html.twig #}
<!DOCTYPE html>
<html>
<head>
<title>{% block title %}Default title{% endblock %}</title>
</head>
<body>
{% block body %}{% endblock %}
</body>
</html>
Twig est très bien supporté par Symfony. Et bien que les templates PHP soient supportés dans Symfony, les avantages qu'offrent Twig sont nombreux. Pour plus de détails référez-vous au chapitre sur le Templating.
11. Ce qu'offre Symfony▲
Dans les prochains chapitres, vous allez en apprendre plus sur comment chaque partie de Symfony fonctionne, et l'organisation recommandée d'un projet. Pour le moment, jetez un œil sur comment migrer un blog écrit en PHP à plat vers Symfony vous a amélioré la vie.
- Votre application a maintenant du code clair et toujours organisé (à travers Symfony qui ne vous force pas dans ce sens). Ceci favorise la réutilisabilité et permet à des nouveaux développeurs d'être productifs plus rapidement dans votre projet.
- 100 % du code que vous avez écrit est pour votre application. Vous n'avez pas à développer ou maintenir des utilitaires de bas niveau comme l'autoloading, le routage, ou le rendu des contrôleurs.
- Symfony vous donne accès à des outils open source comme Doctrine et le templating, la sécurité, les formulaires, la validation et la translation de composants (pour en nommer quelques-uns).
- L'application bénéficie maintenant d'URL complètement flexibles, merci au composant de routage.
- L'architecture centrée HTTP vous donne accès à de puissants outils tels que le caching HTTP, alimenté par le cache HTTP interne de Symfony ou des outils plus puissants tels que Varnish. Cela sera couvert dans un prochain chapitre à propos du cache.
Et peut-être le meilleur de tout, en utilisant Symfony, vous avez maintenant accès à tout un ensemble d'outils open source de qualité développés par la communauté Symfony. Une bonne sélection de ceux-ci peut être trouvée sur KnpBundles.com.
Notes de la rédaction Developpez.com▲
Nous tenons à remercier Sensiolabs pour la mise à disposition de cette documentation, Christophe Louvet pour la traduction et Claude Leloup pour sa relecture orthographique.
