Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Symfony 2 : Un framework php - part I

Par Jacques Adrien HENRI Publié le 09/06/2016 à 21:50:31 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

Ces deux articles vont vous introduire Symfony 2, un outil fexible et extrêmement puissant.

Symfony 2 est un framework php. Si vous ne savez pas ce qu'est un framework, je vous invite à vous renseigner sur le sujet. Par exemple sur le wikipédia prévu à cet effet : https://fr.wikipedia.org/wiki/Framework

Pour résumer, un framework est un outil qui accélére grandement le processus de création d'une application et qui vous permet de suivre les bonnes pratiques afin de "bien" développer. Ce n'est pas indispensable, mais c'est grandement recommandé. Un framework fournit notamment :

  • Une architecture modulaire (suivant généralement le pattern MVC) et organisée qui permet une maintenance plus performante.

  • Une base gérant le processus minimum. Pour les applications web, il s'agit du système de routing qui détecte la requête, l'appel au controller, la gestion des données et la génération des vues pour l'utilisateur final. Pour les applications de bureau, ça peut être le système de fenêtre et de menu etc...

  • Des modules et bibliothèques pour ne pas "réinventer la roue" et pouvoir appliquer rapidement les fonctionnalités que l'on retrouve souvent d'une application à l'autre.

  • Une flexibilité afin de ne pas rester bloqué par le framework. Un framework doit permettre de régler rapidement les problèmes génériques en laissant la possibilité d'implémenter ses propres solutions plus spécifiques.

  • Une évolutivité permettant de toujours être à jour et de disposer des dernières nouveautés facilement.

  • Un gage de qualité par les experts qui l'on mit en place.

  • Une communauté fournissant déjà des milliers de modules et de l'aide en cas de soucis. Plus la communauté est grande, plus c'est intéressant.

Symfony comprend tous ces points et bien plus encore. Il est le framework php le plus répandu aujourd'hui.

Prérequis :

Attention toutefois, cet article présente une vieille version de Symfony 2. Les concepts et la majorité des fonctionnalités restent les mêmes mais vous pourriez avoir quelques différences. Cela ne devrait pas pour autant vous empêcher d'utiliser la dernière version de Symfony à la fin de cette série.

Architecture

Commençons avec l'architecture de Symfony. Normallement, si tout c'est bien passé pendant le téléchargement, vous devriez obtenir quelque chose comme ça :

Symfony est écrit en php. Il nous faut donc un serveur web et php d'installé dessus. Vous pouvez par exemple utiliser Wamp / Mamp / Xamp si vous le souhaitez. La majorité des gens étant sur Windows, je ferai de même en utilisant Wamp.

Placer donc tout ce contenu dans un dossier de votre choix nommé pour cet article symfony-example. Placer ensuite ce nouveau dossier dans le dossier www de Wamp (ou équivalent). Démarrer ensuite Wamp et utiliser votre navigateur web pour vous rendre à l'adresse : http://localhost/symfony-example/web/app_dev.php

Bien entendu, symfony-example doit être remplacé par le nom que vous avez choisi pour votre dossier ;)

Vous obtenez normallement le résultat suivant :

"Congratulations! You have successfully installed a new Symfony application" ;)

Maintenant que votre projet est fonctionnel, nous allons voir plus en détails comment fonctionne Symfony et quelle est son architecture.

Comme vous pouvez le constater, pour visualiser le message de bienvenu dans votre navigateur, vous avez été dans le dossier /web/ et dans le fichier app_dev.php. Mais pourquoi ? En fait, Symfony coupe l'architecture afin d'avoir un dossier exclusivement réservé aux visiteurs (le dossier /web/), le côté client de l'application. C'est la partie qui est en quelque sorte accessible car renvoyée au navigateur. Tous les autres fichiers restent côté serveur. De plus, pour vous rendre la vie plus facile, Symfony à 2 points d'entrée qui séparent 2 environnements différents. Généralement, dans une application classique en php vous avez un fichier d'entrée appelé index.php, n'est-ce pas ? C'est le point par lequel on rentre dans l'application, le premier qui est lu, qui reçoit la requête. Dans Symfony, c'est la même chose à la différence qu'il y a 2 fichiers : app.php et app_dev.php qui correspondent respectivement à l'index.php pour un environnement de production et à l'index.php pour un environnement de développement. Cette configuration amène de nombreux avantages. Sans rentrer dans les détails, sachez que vous avez une gestion plus optimisée du cache en version de production et que vous obtenez une grande quantité d'informations en environnement de développement (pratique pour le débug).

(Vous pouvez essayer de vous rendre à l'adresse : http://localhost/symfony-example/web/app.php, vous verrez une "belle" erreur 404. C'est parce qu'aucune route n'a été définie en environnement de production (app.php). Nous verrons comment gérer les routes un peu plus tard).

Attaquons maintenant le coeur de l'architecture. Nous allons voir à quoi servent les différents dossiers et fichiers. Vous pouvez vous référer à la première image de cette partie pour rappel. Voici la liste avec explication :

  • app : Ce dossier contient les fichiers de configuration principaux. Par exemple, vous pouvez configurer la sécurité, les routes, la connexion de votre base de données (bdd), les bibliothèques externes et bien plus encore. Le format par défaut des fichiers de configuration avec Symfony est le yml. Ce dossier contient également les dossiers /cache et /logs qui sont utilisés, comme leur nom l'indique, pour mettre en cache le site (permet de jouer sur le rechargement de l'affichage d'une manière plus optimisée notamment en production) et pour écrire les logs (ce qui arrive lors de l'exécution de l'application dont notamment les bugs).

  • bin : Ce dossier n'est pas le plus utilisé et nous n'en parlerons pas plus en détails. Sachez juste qu'il permet d'automatiser en appelant des scripts via ligne de commandes.

  • src : Contient la majorité des fichiers que vous écrirez. Votre logique (controller), vos données et votre rendu (view) seront gérés et écris ici.

  • vendor : Tous les modules externes à votre application sont présents ici. Si vous ouvrez le dossier, vous verrez un dossier /symfony à l'intérieur. C'est le code principal du framework symfony qui est lui même un module externe ! Le framework a été pensé pour une flexibilité maximum. Vous pouvez également retrouver le module /doctrine qui correspond à l'ORM (aide à gérer la connection entre l'application et la bdd), le dossier /twig qui est le moteur de template aidant les développeurs à générer les vues de manière plus "procédurale" grâce à des instructions et expressions directement incluses dans le HTML. Nous avons également /swiftmailer qui gère l'envoi d'emails. /composer, lui, permet la gestion des dépendances entre les différents modules dans votre projet. Toutes ces bibliothèques contiennent du code, des fonctions qui vous aident à implémenter de nombreuses fonctionnalités dans votre projet. La grande force, c'est que tout ceci est indépendant, les modules ne dépendent pas les uns des autres ! Vous pouvez choisir de les utiliser ou non dans votre projet Symfony ou même dans vos projets personnels après un minimum de configuration. Tout ça est gérer très facilement par composer. Cela signifie que si une bibliothèque A a besoin d'une bibliothèque B pour fonctionner, composer ira installer (comme par magie) la bibliothèque B. Vous pouvez ainsi ajouter de nombreux modules créés par la communauté, ou même créer les vôtres et les partager.

  • web : C'est le dossier publique auquel vos utilisateurs auront accès. C'est ici notamment que vous pourrez retrouver les dossiers comme /img, /css ou /js par exemple. Vous mettrez donc vos images, vos fichiers css et javascript et tout ce dont vos utilisateurs auront besoin comme ressources. C'est également dans ce dossier que vous trouverez les points d'entrée de votre application (app.php et app_dev.php). Ces points d'entrée sont aussi appelés front controller.

Configuration

Maintenant, parlons de la configuration.

Si vous avez bien suivi la partie précédente, vous devriez savoir exactement de quel dossier nous allons parler. Ouvrez le dossier /app, vous verrez ceci :

Ce dossier contient la configuration de votre application (les routes, la connexion à la bdd, la sécurité etc...).

Comme vous pouvez le voir, nous avons les dossiers /cache et /logs (comme vu précédemment). Vous pouvez voir un .htaccess qui restreint l'accès uniquement au côté serveur. Vous avez aussi d'autres fichiers que nous verrons pas dans le détail. Vous pouvez toujours les ouvrir pour en apprendre plus. Ce qui est important à connaître, c'est le fichier AppKernel.php et les dossiers /config et /Resources. Le fichier est utilisé pour inclure et charger les modules externes dans le projet. En l'ouvrant, vous constaterez les modules chargés et comprendrez mieux comment ça marche. /Resources contient un dossier /views qui contient le layout principal, c'est à dire le template par défaut de l'application, le fichier HTML de base dans lequel sera inclus les vues de chaque page. C'est la base de votre rendu. En ouvrant le layout, vous verrez du code HTML et du code... Twig ! En effet, comme expliqué, Twig est le moteur de template par défaut de Symfony (mais vous pouvez le remplacer) qui vous aide à gérer les vues. Twig permet notamment de définir des blocks de rendu qui peuvent être insérés par la suite dans des vues enfants qui hériteront du layout parent. Voici un exemple de block :

{% block body %}{% endblock %}
{% block javascripts %}{% endblock %}

Ces blocks seront définis une nouvelle fois dans des vues enfants. L'objectif est bien entendu d'avoir un layout global pour de nombreuses vues (voir toutes les vues généralement).

/config est un dossier très important qui contient les configurations de notre application. En l'ouvrant vous obtenez :

Tout d'abord, tout ce qui se termine par _dev concerne uniquement l'environnement de développement et _prod uniquement l'environnement de production tandis que lorsque ce n'est pas renseigné, c'est pour les deux.

config.yml spécifie la configuration des différents modules de l'application (les modules du /vendor inclus dans l'AppKernel.php). En l'ouvrant, vous pouvez voir les différentes configurations par défaut comme par exemple celle de Doctrine, l'ORM natif de Symfony. En l'occurence, il s'agit de gérer les informations relatives à la bdd : %database_host%, %database_port%, %database_name% etc... Ces valeurs, entourées des caractères % nous indiquent que ce sont des variables. Elles sont définies dans le fichier de config parameters.yml. Ouvrez-le également pour voir les valeurs. database_name contient la valeur symfony. Cela veut dire que la base de données créée aura le nom symfony dans le système de gestion de base de données (SGBD, comme MySQL par exemple).

Comment le lien entre ces fichiers ce fait ?

Au début du fichier config.yml, il y a un paramètre imports qui inclut les fichiers security.yml et parameter.yml.

Le fichier security.yml, comme son nom le suggère, permet de gérer la sécurité. Ce sujet assez sensible est très bien traité dans la documentation ici : http://symfony.com/doc/current/book/security.html

Pour résumer ce lien, vous avez deux parties dans le processus de sécurité : Authentification & Autorisation. La première partie (authentification) ce fait par le provider (fournit les utilisateurs) tandis que la deuxième partie ce fait par l'access control (autorise les utilisateurs).

La partie routing permet de définir rapidement et simplement par quelles urls (chemin) l'utilisateur va accéder aux ressources. Ce fichier, routing.yml, va lier des urls avec les bonnes actions associées dans vos controllers (les actions correspondent aux méthodes et les controllers aux classes si on parle de programmation orienté objet POO). Le fichier ne contient rien au début de votre projet, c'est pourquoi si l'on souhaite afficher quelque chose en production on obtient une erreur 404, aucune route n'est définie ! Si maintenant on ouvre le fichier routing_dev.yml en revanche, on pourra voir qu'il y a deux autres fichiers inclus : routing.yml que l'on vient de voir et Acme/DemoBundle/Ressources/config/routing.yml qui est le routing de démonstration. Cela permet d'avoir le même routing qu'en production tout en ajoutant des routes pour le développement. En allant ouvrir le deuxième chemin, la route _welcome est alors présente. On comprend donc mieux pourquoi on a une page qui s'affiche en développement et une erreur en production ;)

L'url / indique le chemin root, c'est à dire l'index, le chemin correspondant à la page d'accueil. Ce qui suit indique que l'action index du controller Welcome dans le bundle DemoBundle du projet Acme sera liée au chemin. Si vous ne comprenez pas tout ne vous inquiétez pas, nous allons voir tout ça un peu plus en détails plus tard.

L'article n'étant qu'une initiation, il est recommandé de lire la documentation pour obtenir plus d'informations sur les différentes notions abordées.

Organisation de projet

Comment organiser votre projet avec Symfony ? Nous allons répondre à cette question dans cette partie.

Tout est bundle

Le bundle est le coeur de Symfony (et d'autres framework). Un bundle représente un bout de code de plusieurs fichiers organisés correspondant à une fonctionnalité. On utilise les bundles pour grouper des fonctionnalités qui devraient être ensemble. Conventionnellement, on représente les bundles de cette manière : NamebundleBundle. Par exemple : UserBundle est un dossier qui représente le bundle utilisateur. Un bundle contient sa propre configuration, ses propres fichiers php (controller, model), ses propres vues (fichiers twig), ses propres formulaires... tout ceci sous la bannière d'une fonctionnalité spécifique.

(Sachez maintenant que les bibliothèques se trouvant dans le dossier /vendor sont en fait des bundles).

Exemple de bundle

  • User (Utilisateur)

  • Video (Vidéo)

  • Post (Article)

  • Comment (Commentaire)

  • Calendar (Calendrier)

  • Category (Catégorie)

  • Page

  • Common (Commun)

Ce qui est intéressant avec Symfony, c'est que vous n'êtes pas bridé. Vous êtes encouragé à respecter les conventions (par exemple de nommage pour les bundle) mais pas obligé.

Maintenant, si vous ouvrez les dossiers /src et /Acme vous verrez le bundle par défaut de Symfony qui est DemoBundle.

(A noter que dans un projet réel vous supprimerez ce bundle pour créer ensuite les vôtres).

Vous pouvez naviguer dans les différents dossiers et fichiers pour en apprendre plus. Les dossiers Form (formulaire), Command... sont assez explicites, ils ne seront donc pas détaillés. En regardant de plus près, on peut s'apercevoir qu'un bundle respecte le pattern très connu qu'est le pattern Model / View / Controller (MVC).

Pour résumer rapidement :

  • Model n'est pas implémenté ici car l'exemple n'utilise tout simplement pas de base de données. Mais lorsque l'on met en place des Models, un dossier Entity est créé. Il contient les classes définissant une structure pour la bdd. Ce que l'on appel communément le Mapping. Après avoir créé la classe (une ligne en ligne de commandes) et configuré ses fichiers (config.yml et parameter.yml) on peut travailler directement avec les Models dans les Controllers.

  • View représente la partie affichée, les vues. Les fichiers sont des fichiers twig.html présents dans le dossier /Resources. Ils utilisent le moteur de template (twig par défaut).

  • Controller est la partie logique de l'application. Les controllers se trouvent dans le dossier /Controller. Chaque controller est une classe ou chaque méthode va représenter une action (créer, modifier, supprimer...). Par exemple : createAction() / showAction() / editAction(). Ces actions sont liées au système de routing, qui en fonction de l'url va appeler la bonne action du bon controller.

Déclarer un bundle

La console (prompt) permet de gérer énormément de chose avec Symfony de manière automatique (Créer les models, les controllers, les bundle etc...). Nous allons voir comment créer un bundle en ligne de commande.

La première chose à faire est d'ouvrir un invite de commande à la racine de notre projet (dans l'exemple : /symfony-example). Sous windows Maj + clicque droit et Ouvrir ligne de commande. Sous Mac OS avec spotlight en tapant cmd + espace et console vous devriez vous en sortir.

Une fois à la racine de votre projet dans votre console (naviguer avec la commande cd au besoin), recopier cette commande :

php app/console generate:bundle 

Un script va se lancer vous demandant les informations de votre bundle. Une fois ces informations remplies, Symfony s'occupera de créer les fichiers php et les dossiers aux bons endroits automatiquement :)

Dans notre projet (que nous appelerons Sup), imaginons que nous voulions créer des articles. Il nous faut donc un bundle Article.

Voici ce qu'il faut rentrer étape par étape :

  • Bundle namespace : Sup/ArticleBundle

  • Bundle name : *Appuyer sur entrer, le nom par défaut est mis entre [] et correspond à ce que l'on veut*

  • Target directory : *Appuyer également sur entrer*

  • Configuration format : yml

  • Ensuite, appuyer sur entrer pour tous les autres choix

Et voila ! Votre bundle est créé comme vous pouvez le constater dans votre projet. Symfony a créé un dossier /Sup avec le bundle ArticleBundle et le MVC basique correspondant.

(De plus Symfony a déjà ajouté le bundle dans l'AppKernel.php et une route dans app/config/routing.yml pour nous)

Maintenant, comme le veut la tradition, on va afficher "Hello, World!" dans notre premier programme Symfony. Pour ce faire, il faut :

  • Aller dans Acme/DemoBundle/Ressources/config/routing.yml et supprimer la route _welcome qui ne sert à rien.

  • Aller dans Sup/ArticleBundle/Ressources/config/routing.yml et changer la route par :

sup_article_homepage:
  pattern: /
  defaults: { _controller: SupArticleBundle:Defaut:index }

Attention lorsque vous copiez des fichiers yml, il faut que l'indentation soit bonne pour ne pas avoir d'erreurs.

  • Aller dans Sup/ArticleBundle/Ressources/view/Default/index.html.twig et supprimer {{ name }}

  • Enfin aller dans Sup/ArticleBundle/Contoller/DefaultController.php et remplacer l'index par :

public function indexAction()
{
  return $this->render('SupArticleBundle:Default:index.html.twig');
} 

Retourner à la racine de votre application dans votre navigateur et paf... Hello, World! :)

Bibliographie

La documentation Symfony : http://symfony.com/doc/current/book/index.html

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels