Dans un premier temps, qu’est-ce que ce fameux Symfony2 ?
Il s’agit de ce que l’on appelle un framework, ensemble d’outils permettant aux développeurs de réaliser un travail correct, rapidement et, surtout, facile à maintenir par la suite. De par son fonctionnement, il sépare efficacement tous les travaux nécessaires à la création d’un site web complexe (design, traduction, fonctionnement du site, etc…).
Je vous invite d’ailleurs à faire un tour sur le site officiel de Symfony2 pour un maximum d’informations et d’aides à l’apprentissage.
Comment tout cela fonctionne-t-il ?
Chaque élément du site est découpé en modules, appelés Bundles. Chaque Bundle contient les vues (pour l’affichage pur), les controllers (chargé de toute la partie logique) et les entités (toute les données de la base de données sous forme d’objets php). On y trouve également des fichiers de configuration, de traduction et d’autres utilitaires bien pratiques.
Cette architecture est utilisé par le framework lui-même pour séparer ses éléments de fonctionnement. Au moins, il respecte sa logique jusqu’au bout 
.
Tout est fait pour fonctionner au plus bas niveau possible, c’est à dire depuis la requête http jusqu’au rendu de la page dans le navigateur.
Les routes
Un élément primordial de Symfony2 est ce que l’on appelle les routes. Ce sont en fait ni plus ni moins que les définitions des URLs liés aux contrôleurs.
Chaque route définie un modèle d’URL et le relie à un contrôleur permettant de générer et afficher la page.
Quelques exemple de routes seraient :
index:
pattern: /
defaults: { _controller: DreeckanReaderBundle:Reader:index }
chap:
pattern: /chapitre/{num}/{name}
defaults: { _controller: DreeckanReaderBundle:Reader:lireChap, page: 1 }
requirements:
num: \d+
Ainsi ces deux routes appelle toutes deux le contrôleur ReaderController du bundle DreeckanReaderBundle et l’action indexAction ou LireChapAction (je reviendrai sur ces points un peu plus loin). Les paramètres comme {num} sont variables et leur format est éventuellement défini dans une section requirements. On peut également définir une valeur par défaut à chaque variable que l’on souhaite passer au contrôleur. Ici, je veux lui dire que, par défaut, la lecture d’un chapitre commencera à la page 1 (logique non ? 
). En bref, ces routes permettent de définir les URLs de notre site de manière propre et très simple (une pensée aux fichiers .htaccess interminables et compliqués).
Les controllers
La partie logique du site. Les contrôleurs se chargent de récolter les informations nécessaires et les transmettent à la vue. Ils sont décomposés en actions comme suit :
<?php
namespace Dreeckan\ReaderBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
class ReaderController extends Controller
{
public function indexAction()
{
return $this->render('DreeckanReaderBundle:Default:index.html.twig');
}
public function lireChapAction($name, $num = 0, $page = 1)
{
$em = $this->getDoctrine()->getEntityManager();
$chap = $em->getRepository('DreeckanReaderBundle:Chapitre')
->findOneByNumAndName($num, $name);
$liste = $em->getRepository('DreeckanReaderBundle:Paragraphe')
->findListForChapAndPage($chap, $page);
$pages = $em->getRepository('DreeckanReaderBundle:Paragraphe')
->findListPages($chap);
return $this->render(
'DreeckanReaderBundle:Default:lireChap.html.twig',
array('chap' =>
$chap, "paraList" => $liste,
"page" => $page,
"pagesList" => $pages));
}
}
Voilà un exemple pour les routes précédentes. Je n’entre pas dans le détail volontairement, mais notez que chaque action récupère des données en base et les transmet à la vue. La méthode render trouve la vue demandée et la « compile », la transforme en un fichier PhP classique pour l’affichage.
Les vues
De base, Symfony2 est livré avec un moteur de template appelé Twig, permettant, via l’utilisation d’un code spécifique et plutôt simple à apprendre/comprendre. Le système vient droit du moteur de template utilisé dans le projet Django (d’ailleurs, pour ceux qui codent en Python, le web n’a jamais été aussi agréable qu’avec ce formidable framework ).
Le design est aisé à créer et gérer à partir de là. De plus, les vues peuvent être héritées. Autrement dit, on peut définir les éléments principaux (des blocs) dans un fichier et les réutiliser immédiatement dans les autres. Ainsi, on définit toujours un fichier base.html.twig contenant les bases de notre design html, un layout.html.twig héritant de la base pour les spécificités liées à notre bundle. Il n’y a alors plus qu’à hériter de ce layout pour que toutes nos vues aient la même base. Simple à utiliser et efficace.
Bref, en quoi est-ce si intéressant ?
Ce qui est réellement intéressant avec ce framework est simplement qu’il permet de tout faire, en relativement peu de temps. De plus, la communauté, en bonne partie issue de la première mouture, est très active et nombreuse. De nombreux Bundles existent déjà, pour diverses tâches, permettant de réduire le code à écrire à un minimum (vous trouverez par exemple de quoi gérer les menus de votre site, une zone d’administration créée en un clin d’oeil et beaucoup d’autres choses). Pour y jeter un oeil, je vous donne rendez-vous sur le site knpbundles.com regroupant une liste non officielle de bundles.
Et il n’a donc aucun défaut ?
Eh bien si. Et le plus important d’entre eux est le temps d’apprentissage nécessaire pour faire fonctionner un site avec Symfony2. Il regroupe tellement de notions (comme le fonctionnement de l’ORM Doctrine) qu’il faut un certain temps pour tout assimiler.
Le démarrage d’un projet nécessite également pas mal de patience, de configurations diverses mais étrangement peu de code.
Sans compter l’installation des bundles parfois hautement frustrante (soucis de documentation ?), surtout quand des erreurs non prévues se présentent.
Quelques liens utiles pour apprendre et/ou se renseigner
Not logged in