Introduction à Symfony

Explication du sujet

C'est un ensemble de composants PHP. Chaque composant solutionne un problème de développement récurrent comme d’abstraire les messages HTTP, créer des outils ligne de commande, etc. Symfony tente de rendre ces composants flexibles et extensibles.

C'est un ensemble de classes basé sur l'approche OO, en mode MVC. Ces classes offrent des outils pour les développeurs PHP. Il y a un grand nombre de composants présentement qui existent afin de nous faciliter la tâche.

Certains projets l’utilisent déjà : Behat, Doctrine, Propel, PHPUnit, Jackalope,
easybook, Midgard CMS, Zikula, phpBB et bientôt Drupal.

Vous pouvez consulter la page de Quick tour de Symfony qui regroupe les notes suivantes.

Installation

Nécessite Composer (package manager PHP)
PHP 5.3.3 et +

Si vous avez le message suivant :
You are not allowed to access this file. Check app_dev.php for more information.
Il suffit d'enlever le if qui valide l'adresse IP tel qu'indiqué dans le fichier app_dev.php pour le développement.

View

Twig est l'engin de template utilisé par Symfony. Cependant, on pourrait quand même utilisé des templates PHP classique.

• Il permet l'héritage de "templates" ou l'extensibilité ("MasterPage" en .NET)
• Il existe des "tags, filters et fonctions" pour faire quelques manipulations d'affichage (format de date, mettre en majuscules, etc.)
• Les liens vers d'autres pages doivent absolument utiliser la méthode path qui utilise le "Routing". Donc, plus de URL "hardcodé".

Controller

• Permet de générer plus que du HTML. Il est possible avec le même controller de retourner du HTML, XML, json, etc. Avec la spécification de format, on peut utiliser différents templates pour le même controller.
• Redirection doit elle aussi utilisé la méthode qui se sert du Routing, soit generateUrl.
• Pages d'erreur sont gérés automatiquement, createNotFoundException est un raccourci pour la page 404.
• On reçoit la requête automatiquement et la réponse est construite automatiquement aussi.
• La session est toujours accessible, la différence est que ce doit être fait par le "wrapper" de Symfony

Architecture

Les dossiers d'un projet Symfony :

• app/: configuration de l'application; (enregistrer les "bundles" + charger les configs)
• src/: le code PHP du projet;
• vendor/: dépendances "third-party";
• web/: la racine web (ressources (images, css, js) + "front controller")

Tout est un "bundle" dans Symfony. Chaque « bundle » est contenu dans un dossier différent et configurable a l’aide de fichiers YAML, XML ou PHP. On peut hériter d'un "bundle" et redéfinir les controllers, views, etc.

Tous les fichiers de configurations sont lus qu’une seule fois et mis en cache automatiquement ensuite par Symfony. Cette cache est changée quand un fichier est changé en DEV, mais en prod, c’est manuellement que ce doit être fait.

Chaque application vienne avec un mode "command-line" (app/console). Ensuite, c'est au "bundle" d'implémenter une commande si besoin est.

Et Drupal avec ça ?

Dans Drupal8, le but était d’offrir un « framework.Core », mais pourquoi se
concentrer sur cela alors que Symfony l’est déjà. Drupal est un CMS et devrait se concentrer sur le CMS et non sur les éléments de bas niveau. De plus, cela facilitera l’intégration avec d’autres applications.

Présentement, les composants suivants sont pressentis pour être intégrés à Drupal8 :

• ClassLoader: Charger sur demande les classes PHP. Cependant, il faut suivre les conventions pour le nom.
• HttpFoundation: Un des composants les plus important. Remplace toutes les obtentions à partir de HTTP en PHP pour du code plus simple à tester et à utiliser. Normalement ce sont des variables globales, on doit faire pleins de vérifications et cela devient complexe et/ou facile d’y insérer des failles. Représente les messages HTTP selon la spécification.
• HttpKernel: Le composant le plus important.Implémente tout ce qui est dynamique dans la specification HTTP. Gère la conversion d’une requête à une réponse.
• Routing: Associer les requêtes avec quel « controller » qui va gérer la requête. On se crée une collection de "routes" qui sont ensuite analysées lorsque la requête est reçue. Permet aussi de gérer lorsqu’on veut rediriger vers une autre page.
• Event Dispatcher: Semblable au système de "hooks" de Drupal, mais orienté-objet. Le code envoie un événement et le "dispatcher" est averti et chaque "listener" peut réagir sur celui-ci. Il se pourrait que Drupal8 ne l’utilise pas et garde le système de "hooks". Par défaut, il y a beaucoup de "listeners" de disponible et c'est très simple de se créer son propre ExceptionHandler.
• DependencyInjection: Permet de faire un "mock" de tout pour tester le plus modulairement possible. Cependant, il faut faire les associations (il n’y a pas de magie) pour lui dire quel objet instancier lorsqu’on le demande.

Conclusion

Symfony est une approche plus professionnelle, performante et facilement maintenable pour une équipe de développeurs.
Drupal est plus plaisant, moins de code et plus de développement et de déploiement (par contre, parfois quick&dirty).

En pièce jointe, il y a un petit "bundle" qui accède à une base de données à l'aide de Doctrine qui a été utilisé pendant la présentation ainsi que les notes de la présentation.