Symfony 2

Sommaire :

1.Définition de symfony 2

2.Installation

3.Structure

4.Symfony et les commandes

5.Le fonctionnement : le routeur (les url), les bundles, twig(templates)

6.L’architecture de symfony2

1. Définition de symfony 2

Symfony2 est donc un framework PHP. C'est un des frameworks les plus utilisés dans

le monde, notamment dans les entreprises. La première version de Symfony est sortie

en 2005 et a été crée par une équipe francaise de développeur. Aujourd’hui il bénéficie

d’une grande communauté de développeur mondial ce qui permet une évolution plus

rapide. Ce nouveau symfonnie est maintenant géré avec un système de bundle.

Un Bundle est un ensemble de fichiers et répertoires permettant d'implémenter une ou

des fonctionnalités (si possible réutilisables dans divers projets). Ils sont assez similaires

au plugins dans Symfony 1.x, sauf que tout le code est stocké dans ces derniers: vues,

actions, modèles, config…

2. Installation de symfony 2

Pour installer symfony 2 il y a plusieurs méthodes :

Si vous utilisez déjà Composer, vous pouvez télécharger cette distribution standard

en une seule commande : php composer.phar create­project

symfony/framework­standard­edition Symfony 2.2. Cela va installer la version 2.2 de

Symfony2 dans le répertoire Symfony.

Si vous êtes sous Windows, évitez de télécharger l'archive au format .tgz car des

problèmes ont été rencontrés avec cette archive. (lien de téléchargement officiel :

http://symfony.com/download )

3. Structure de symfony

Ce framework est structuré en 4 dossier : app, src, vendor, web

Le répertoire /app

Ce répertoire contient tout ce qui concerne le site internet sauf son code source c’est à

dire la configuration, le cache, les fichiers logs.

Le répertoire /src

Le répertoire dans lequel se trouve le code source. Dans ce répertoire, le code est

organisé en bundles, des briques de l’application.

Le répertoire /vendor

Ce répertoire contient toutes les bibliothèques externes à l’application. Dans ces

bibliothèques externes nous pouvons y trouver Syphony2, Doctrine, Twig, SwiftMailer,

etc.

Le répertoire /web

Ce répertoire contient tous les fichiers destinés aux visiteurs : images, fichiers CSS et

JavaScript, etc. Il contient également le contrôleur frontal (app.php).C'est le seul

répertoire qui devrait être accessible aux visiteurs.

Le contrôleur frontal

Le contrôleur frontal est le point d'entrée de votre application. C'est le fichier par lequel

passent toutes les pages. Dans Symfony2, le contrôleur frontal se situe dans le

répertoire /web, il s'agit de app.php ou app_dev.php.

4. Symfony sur console

Symfony2 intègre des commandes disponibles non pas via le navigateur, mais via l'invite

de commandes (sous Windows) ou le terminal (sous Linux). Il existe pas mal de

commandes qui vont nous servir assez souvent lors du développement.

Les outils disponibles en ligne de commande ont pour objectif de nous faciliter la vie. On

peut à partir de la console, générer une base de code source pour certains fichiers

récurrents, vider le cache, ajouter des utilisateurs par la suite, etc.

Sous windows il suffit de se placer dans le répertoire de symfony puis de taper :

Ensuite, on peut exécuter toutes les commandes possibles disponibles sous symfony2.

Liste des commandes préconstruites :

$ php app/console list Il existe une commande list qui affiche la liste des options standard et des commandes enregistrées :

$ php app/console Vous pouvez également avoir le même affichage sans exécuter aucune commande

$ php app/console help list

La commande d'aide liste les informations de la commande spécifiées.

$ php app/console help Exécuter help sans spécifier aucune commande listera les options globales :

Lien vers d’autres commandes :

http://symfony.com/fr/doc/current/components/console/usage.html

5. Le fonctionnement : le routeur (les url), les bundles,

twig(templates)

Les routeurs : L'objectif du routeur est de dire à Symfony2 ce qu'il doit faire lorsque que l'on appelle l'URL en utilisant des routes.

Exemple de route (source site du zéro) :

Explication de cette route :

Le "HelloTheWorld" est le nom de la route. Il est assez arbitraire, et vous permet juste de vous y retrouver par la suite. La seule contrainte est qu'il soit unique ;

Le "pattern" correspond à l'URL à laquelle nous souhaitons que notre hello world soit accessible. C'est ce qui permet à la route de dire : « cette URL est pour moi, je prends » ;

Le "defaults" correspond aux paramètres de la routes, dont : Le "_controller", qui correspond à l'action (ici, "index") que l'on veut exécuter

et au contrôleur (ici, "Blog") que l'on va appeler (un contrôleur peut contenir plusieurs actions, c'est à dire plusieurs pages).

Ne vous inquiétez pas, un chapitre complet est dédié au routeur et vous permettra de jouer avec. Pour l'instant ce fichier nous permet juste d'avancer. Mais avant d'aller plus loin, penchons­nous sur la valeur que l'on a donnée à _controller : « SdzBlogBundle:Blog:index ». Cette valeur se découpe en suivant les pointillés les deux­points (« : ») :

« SdzBlogBundle » est le nom de notre bundle, celui dans lequel Symfony2 ira chercher le contrôleur ;

« Blog » est le nom du contrôleur à ouvrir. En terme de fichier, cela correspond à controller/BlogController.php dans le répertoire du bundle. Dans notre cas, nous avons src/Sdz/BlogBundle/controller/BlogController.php comme chemin absolu.

« index » est le nom de la méthode à exécuter au sein du contrôleur.

Les bundles : Chaque bundle dispose de ses propres routes. Un bundle est une brique de votre

application. Ce concept innovant qui consiste à regrouper dans un même endroit, le

bundle, tout ce qui concerne une même fonctionnalité.

La découpe en bundles permet l'échange de bundles entre applications. Cela signifie que

l’on peut développer une fonctionnalité, puis la partager avec d'autres développeurs ou

encore la réutiliser dans un autre projet.

Pour qu'un bundle soit opérationnel il faut :

Son code source, situé dans src/Application/Bundle, et dont le seul fichier

obligatoire est la classe à la racine SdzBlogBundle.php

Enregistrer le bundle dans le noyau pour qu'il soit chargé, en modifiant le fichier

app/AppKernel.php

Enregistrer les routes (si le bundle en contient) dans le Routeur pour qu'elles soient

chargées, en modifiant le fichier app/config/routing.yml

Ces trois points sont bien sûr effectués automatiquement lorsqu'on utilise le générateur.

Mais on peut tout à fait créer un bundle sans l'utiliser, et il faudra alors remplir cette petite

checklist.

Par la suite, tout le code source sera situé dans des bundles. Un moyen très propre de

bien structurer son application.

TWIG (templates) :

C'est un script qui permet d'utiliser des templates, c'est­à­dire des fichiers qui ont pour but d'afficher le contenu de votre page HTML de façon dynamique, mais sans PHP c’est à dire avec leur langage; En effet, chaque moteur a son propre langage.

Exemple de template avec TWIG :

6. L’architecture de symfony2

Symfony2 utilise le modèle MVC.

Contrôleur (ou

ontroller)

son rôle est de générer la réponse à la requête HTTP

demandée par notre visiteur. Il est la couche qui se charge

d'analyser et de traiter la requête de l'utilisateur. Le

contrôleur contient la logique de notre site Internet et va se

contenter « d'utiliser » les autres composants : les modèles

et les vues.

Concrètement un contrôleur va récupérer, par exemple, les

informations sur l'utilisateur courant, vérifier qu'il a le droit de

modifier tel article, récupérer cet article et demander la page

du formulaire d'édition de l'article. C'est tout bête, avec

quelques if(), on s'en sort très bien ;

Modèle (ou son rôle est de gérer vos données et votre contenu.

Model) Reprenons l'exemple de l'article. Lorsque je dis « le

contrôleur récupère l'article », il va en fait faire appel au

modèle « article » et lui dire : « donne­moi l'article portant l'id

5 ». C'est le modèle qui sait comment récupérer cet article,

généralement via une requête au serveur SQL, mais ça

pourrait être depuis un fichier texte ou ce que vous voulez.

Au final, il permet au contrôleur de manipuler les articles,

mais sans savoir comment les articles sont stockés, gérés,

etc. C'est une couche d'abstraction ;

Vue (ou View) son rôle est d'afficher les pages. Reprenons encore

l'exemple de l'article. Ce n'est pas le contrôleur qui affiche le

formulaire, il ne fait qu'appeler la bonne vue. Si nous avons

une vue « formulaire », les balises HTML du formulaire

d'édition de l'article y seront et au final, le contrôleur ne fera

qu'afficher cette vue sans savoir vraiment ce qu'il y a

dedans. En pratique, c'est le designer d'un projet qui

travaille sur les vues. Séparer vues et contrôleurs permet aux

designers et développeurs PHP de travailler ensemble sans

se marcher dessus.