Un petit article afin de résumer l’arborescence de Symfony 2. Cela me permettra par la suite de faire la différence entre la nouvelle version actuelle de Symfony, la 3.
Vous avez pu voir comment installer une symfony dans un précédent article. Nous allons ici voir l’architecture des fichiers.
Lorsque vous créez un projet Symfony, il y a 4 dossiers :
– app
– src
– vendor
– web
Le répertoire app contient tous les fichiers de configuration, ainsi que les fichiers cache et logs. C’est d’ailleurs ces dossiers dont il faut vérifier les droits afin que Symfony puisse y écrire.
Le répertoire src contient comme son nom l’indique tous les fichiers sources de votre projet. Que ce soit les controllers, les formulaires, les fichiers de configuration pour votre base de données, les fichiers de css ou les views.
Le répertoire vendor permet de répertorier toutes les bibliothèques externes qui seront utiles à notre projet, comme twig ou encore swiftmailer qui permet d’envoyer des mails facilement. Bien entendu, symfony y est également.
Le répertoire web contient les fichiers qui doivent être disponibles aux internautes : les images, fichiers css et javascript, ainsi que le contrôleur frontal : app.php. A noter qu’il existe également app_dev.php pour différencier les deux environnements de développement (dev et prod). Lors de la configuration de votre fichier virtualhost, il est donc important de bien configurer le chemin de votre application en dev, qui sera donc ~/repertoiredeSymfony/web/app_dev.php
Pour configurer les différents vendor dont vous avez besoin dans votre projet, il suffira de la rajouter dans votre fichier composer.json et de faire ensuite un php app/console update (ou install).
Il faut également garder en tête que Symfony fonctionne avec des bundles. Concrètement lorsque vous créez un bundle (via la ligne de commande) ce dernier va créer des dossiers et un fichier de configuration.
Knpbundles.com est un site qui regroupe des bundles qui peuvent vous aider à aller plus rapidement. Par exemple le premier qui s’appelle FOSUSerBundle permet de gérer des utilisateurs sans devoir tout développer et qui peut s’imbriquer dans votre projet global facilement.
Créer un bundle, se situer dans le dossier du projet :
[pastacode lang= »bash » manual= »php%20app%2Fconsole%20generate%3Abundle » message= » » highlight= » » provider= »manual »/]
La console vous posera alors plusieurs questions. Tout d’abord choisir un namespace, ce dernier doit obligatoirement finir par Bundle. Une confirmation vous ait demandé, puis le chemin d’accès est requis. De base, ce dernier se situe dans le dossier src. Ensuite le format des fichiers de configurations : yml, xml, php ou annotations. Pour ma part je choisis yml. La console demande ensuite si l’on souhaite générer toute la structure du répertoire, ce qui facilite la tâche.
Enfin, nous pouvons également faire en sorte que le bundle soit « autoload » ainsi que mettre à jour le routing pour accéder à ce bundle.
Par exemple si notre bundle s’appelle AcmeBundle, l’arborescence sera :
– Controller
– DependencyInjection
– Resources
– Tests
et un fichier nommé AcmeBundle.php
Ce fichier est créé automatiquement et ne servira qu’à initialiser le bundle dans le fichier de configuration situé dans le dossier app appelé AppKernel.php. Il ne sera pas utilisé par nous-même.
Concrètement, vous allez donc faire votre code entier dans le dossier src et dans le dossier de votre bundle.
Le dossier controller, comme son nom l’indique nous servira à créer nos fichiers controller afin de pouvoir récupérer la requête et de l’afficher. Attention la nomemclature est importante car elle servira à créer nos routes!
Le routing
Un fichier de configuration de routing est déjà disponible dans le dossier app/config/routing.yml.
Si vous l’ouvrez, vous constatez alors qu’une route a été créée en fonction de votre bundle précédemment créé :
[pastacode lang= »php » manual= »acme%3A%0A%20%20%20%20resource%3A%20%22%40AcmeBundle%2FResources%2Fconfig%2Frouting.yml%22%0A%20%20%20%20prefix%3A%20%20%20%2F » message= » » highlight= » » provider= »manual »/]
Il vous suffira alors de configurer votre propre fichier de routing dans le chemin indiqué, donc dans /src/AcmeBundle/Resources/config/routing.yml.
Nous allons voir la route qui a été créée par défaut.
Pour cela nous allons nous placer dans AcmeBundle/Controller et constater qu’il existe déjà un fichier appelé DefautController.php
[pastacode lang= »php » manual= »%3C%3Fphp%0A%0Anamespace%20AcmeBundle%5CController%3B%0A%0Ause%20Symfony%5CBundle%5CFrameworkBundle%5CController%5CController%3B%0A%0Aclass%20DefaultController%20extends%20Controller%0A%7B%0A%20%20%20%20public%20function%20indexAction(%24name)%0A%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20return%20%24this-%3Erender(‘AcmeBundle%3ADefault%3Aindex.html.twig’%2C%20array(‘name’%20%3D%3E%20%24name))%3B%0A%20%20%20%20%7D%0A%7D » message= » » highlight= » » provider= »manual »/]
Dans le routing on retrouvera alors la route correspondante à cette action :
[pastacode lang= »php » manual= »acmehomepage%3A%0A%20%20%20%20path%3A%20%20%20%20%2Fhello%2F%7Bname%7D%0A%20%20%20%20defaults%3A%20%7B%20_controller%3A%20AcmeBundle%3ADefault%3Aindex%20%7D » message= »routing index » highlight= » » provider= »manual »/]
Dans le controller, ici un paramètre est toujours requis, la variable $name.
Le path correspond donc ici au chemin, par exemple blog.com/hello/prenom
Le controller correspondant sera donc l’action ‘index’ du bundle ‘AcmeBundle’ dans le fichier de controller ‘Default’Controller.php, ce qui donne donc ici AcmeBundle:Default:index.
Plutôt simple non?
Si on revient au controller, on constate également l’appel à une view et de la variable ‘name’ donnée en paramètre :
[pastacode lang= »php » manual= »return%20%24this-%3Erender(‘AcmeBundle%3ADefault%3Aindex.html.twig’%2C%20array(‘name’%20%3D%3E%20%24name))%3B » message= » » highlight= » » provider= »manual »/]
Ce fichier se trouve donc dans src/Resources/views/Default/index.html.twig et où on y verra
[pastacode lang= »css » manual= »hello%20%7B%7Bname%7D%7D » message= » » highlight= » » provider= »manual »/]
On constate ainsi l’affichage de la variable donné en paramètre de l’action (et également de la fonction) qui fait que cette variable est donc obligatoire.
On remarque donc que Symfony fonctionne sous le modèle MVC et sous une syntaxe particulière qui permet de bien organiser son projet.
Twig
Twig est le moteur de template utilisé dans symfony 2. Il est assez simple d’utilisation. Par exemple :
[pastacode lang= »markup » manual= »%3C!DOCTYPE%20html%3E%0A%0A%3Chead%3E%0A%09%3Ctitle%3EBienvenue%20!%20%3C%2Ftitle%3E%0A%3C%2Fhead%3E%0A%0A%3Cbody%3E%0A%20%20%20%20%7B%25%20for%20item%20in%20menu%20%25%7D%0A%20%20%20%20%20%20%20%20%7B%7Bitem.nom%7D%7D%0A%20%20%20%20%7B%25%20endfor%20%25%7D%0A%3C%2Fbody%3E » message= » » highlight= » » provider= »manual »/]
A noter que les fichiers et images que vous auriez besoin se trouve dans Resources/public/css ou /public/images ou public/js.
La base de données
schema.xml est un fichier qui se situera dans Resources/config de votre bundle. Il permet de configurer la base de données de votre application simplement.
La connexion à votre base de données se configure elle dans le fichier app/config/parameters.yml
[pastacode lang= »php » manual= »parameters%3A%0A%20%20%20%20database_driver%3A%20%20%20pgsql%0A%20%20%20%20database_host%3A%20%20%20%20%20127.0.0.1%0A%20%20%20%20database_port%3A%20%20%20%20%20~%0A%20%20%20%20database_name%3A%20%20%20%20%20%0A%20%20%20%20database_user%3A%20%20%20%20%20%0A%20%20%20%20database_password%3A%20″ message= » » highlight= » » provider= »manual »/]
Mais revenons à notre fichier schema.xml.
Pour définir une table :
[pastacode lang= »php » manual= »%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%3F%3E%0A%0A%3Cdatabase%20name%3D%22default%22%20namespace%3D%22AcmeBundle%5CModel%22%20defaultIdMethod%3D%22native%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%0A%20%20xsi%3AnoNamespaceSchemaLocation%3D%22http%3A%2F%2Fxsd.propelorm.org%2F1.6%2Fdatabase.xsd%22%3E%0A%20%20%20%20%20%20%0A%20%20%20%20%3Ctable%20name%3D%22article%22%3E%0A%20%20%20%20%20%20%20%20%3Ccolumn%20name%3D%22nom%22%20type%3D%22varchar%22%20required%3D%22true%22%20size%3D%2216%22%20%2F%3E%0A%20%20%20%20%20%20%20%20%3Ccolumn%20name%3D%22titre%22%20type%3D%22varchar%22%20required%3D%22false%22%20size%3D%22255%22%20%2F%3E%0A%20%20%20%20%20%20%20%20%3Cunique%3E%0A%20%20%20%20%09%20%20%20%20%3Cunique-column%20name%3D%22nom%22%20%2F%3E%0A%20%20%20%20%09%3C%2Funique%3E%20%20%0A%20%20%20%20%20%20%20%20%3Cbehavior%20name%3D%22auto_add_pk%22%2F%3E%0A%20%20%20%20%3C%2Ftable%3E » message= » » highlight= » » provider= »manual »/]
Ici on crée simplement une table ‘article’ avec deux champs : nom et titre. Le nom doit être unique et on rajoute le ‘comportement’
<behavior name="auto_add_pk"/>qui permet d’avoir un id qui incrémente automatiquement.
Lorsque vous avez terminé de faire votre schéma complet, il suffira alors de faire les commandes suivantes pour créer la base de données (si vous avez mis les bons accès dans le fichier de connexion à la base qui doit déjà exister ) :
php app/console propel:build php app/console propel:sql:build php app/console propel:model:build php app/console propel:sql:insert
Cela va alors créer les fichiers de classes (models, qui répertorie les différentes variables, mais aussi les query avec les différentes requêtes de récupération par exemple) que l’on va pouvoir surcharger afin de rajouter nos propres méthodes si besoin.
Il existe d’autres fichiers de configuration comme services.yml ou encore validation.yml dont nous parlerons dans un futur article.
Mais nous avons déjà vu beaucoup pour le moment et j’espère que cet article vous a permis de voir globalement comment était construit symfony2 🙂