Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Support de révision Symfony2 UP WEB 2013 ESPRIT 27/11/2013 2 - Introduction : D

Support de révision Symfony2 UP WEB 2013 ESPRIT 27/11/2013 2 - Introduction : Dans ce support, nous proposons une révision de la formation Symfony2 avec l’environnement de travail suivant : Netbeans pour PHP + Wamp. - Problématique : Gestion de plus en plus délicate des gros projets en entreprise en particulier au niveau de la collaboration, la gestion du contenu, la maintenabilité et l’extensibilité.  Solutions : les framework et CMS - Framework (Fram+work => cadre de travail)  Avantages : meilleur organisation du code souvent grâce au modèle MVC, facilite le travail en groupe (facilite l’intégration d’un nouveau membre de l’équipe), facilite le référencement (avec l’url rewriting), meilleur sécurité des applications, réutilisation de modules déjà prêts, indépendant de l’SGBD => malgré que son apprentissage n’est pas toujours évident, il assure une meilleure productivité et ça fini par rapporter sur le long terme!! - CMS (Content management System, système de gestion de contenu, on travailler avec, avec un min de connaissance en info) contrairement à un framework (un cadre de travail pour des vrais développeurs). - Définition Symfony : Framework français développé chez sensioLabs en 2005 suite à la demande de Fabien Potencier son PDG.  Mise en place de l’environnement 1- Installer jdk7 à partir du site web d’oracle 2- Installer Netbeans à partir de son site officiel : www.netbeans.org (choisissez la version pr HTML5 & PHP) 3- Renseigner la variable d’environnement php dans le path comme le montre les étapes suivantes : 3  Ensuite aller à ordinateur => bouton droit propriété 4  Création du projet sur netbeans : 1- Aller sur tools => Options 5  Renseigner PHP5 Interpreter  Pointer sur le fichier .zip de symfony (la version finalement complète est 2.3.7) 2- Aller sur File 6 Donner le nom du projet et préciser plutôt la version PHP 5.3 pour la compatibilité ! 7 8 Attendre quelques secondes et c’est fait !!  9 Après la création de votre projet ! La première chose à faire c’est de vérifier la configuration PHP. http://localhost/Nom_Projet/web/config.php  Sous mac ou linux php –v  Liste des répertoires : App : tout ce qui concerne le site sauf le code source, séparer le code source qui fait la logique du reste. Fichier de Config, cache, logs Src : le code source  … Vender : toutes les bibliothèques externes de notre répertoire swift, doctrine, twig (c’est quoi une bibliothèque ? boite noir qu’on sait utiliser mais pas forcement ce qu’il y a dedans ! exp : swiftMail : permet l’envoie des emails) Web : tt ce qui est fichier destinés pr les visiteurs  css JS … là où on trouve notre controleur frontal, le point d’entré de notre appli  Contrôleur frontale Le contrôleur frontal (front controller, en anglais) est le point d'entrée de votre application. C'est le fichier par lequel passent toutes vos pages. Vous devez surement connaître le principe d'index.php et des pseudo-frames (avec des URL du type index.php?page=blog) ; eh bien, cet index.php est un 10 contrôleur frontal. Dans Symfony2, le contrôleur frontal se situe dans le répertoire /web, il s'agit de app.php ou app_dev.php. Pourquoi y a-t-il deux contrôleurs frontaux ? Normalement, c'est un fichier unique qui gère toutes les pages, non ?  travaillons maintenant avec Symfony2, et son objectif est de nous faciliter le développement. C'est pourquoi Symfony2 propose un contrôleur frontal pour nos visiteurs, app.php, et un contrôleur frontal lorsque nous développons, app_dev.php. Ces deux contrôleurs frontaux, fournis par Symfony2 et prêts à l'emploi, définissent en fait deux environnements de travail. Deux environnements de travail ?  L'objectif est de répondre au mieux suivant la personne qui visite le site : Un développeur a besoin d'informations sur la page afin de l'aider à développer. En cas d'erreur, il veut tous les détails pour pouvoir déboguer facilement. Il n'a pas besoin de rapidité. Un visiteur normal n'a pas besoin d'informations particulières sur la page. En cas d'erreur, l'origine de celle-ci ne l'intéresse pas du tout, il veut juste retourner d'où il vient. Par contre, il veut que le site soit le plus rapide possible à charger. Vous voyez la différence ?  À chacun ses besoins, et Symfony2 compte bien tous les remplir. C'est pourquoi il offre plusieurs environnements de travail : - L'environnement de développement, appelé « dev », accessible en utilisant le contrôleur frontal app_dev.php. C'est l'environnement que l'on utilisera toujours pour développer. - L'environnement de production, appelé « prod », accessible en utilisant le contrôleur frontal app.php. 11 12  Then ok ok ^^ and finally click on the button Run :D http://localhost/testSymfony/web/config.php 13  Création d’un Bundle : 14 Préciser le namespace, ensuite le nom du bundle ensuite yes, yml, yes, yes et c’est fait  15  Ce qui se passe lors de la création d’un bundle 1] Création de son code source, situé dans src/Application/Bundle, et dont le seul fichier obligatoire est la classe à la racine NomApplicationNomBundle.php (il y a rien de spécial dedans, mais n’y touchez pas !  ) 2] Téléchargement du bundle au noyau de symfony dans le fichier AppKernel.php sous le répertoire app à la ligne 19 pour un tout premier comme suit :  Cette classe permet donc uniquement de définir quels bundles charger pour l'application. 16 3] Création du routeur :  Le rôle du Routeur est de déterminer quel contrôleur exécuter (plus précisément quelle Action du contrôleur) en fonction de l'URL appelée. Pour cela, il utilise les routes. 4] Pour chaque Action, il faut qu’on lui crée son URL (sa route) dans le fichier routing.yml situé dans le répertoire de notre bundle sous Ressources/config ! C’est au niveau du fichier indiquer dans « resource : » là où on trouve les routes=URL ! Pour chaque Action du contrôleur, on associe une page.html.twig. Pour chaque Action, on a l’URL qui lui correspond (voir figure d’après) et donc sa route, autrement dit son URL ! 17  Je propose ce schéma pour mieux expliquer tout cela ! I. Affichage d’un message (response) affichage d’une page (render)  Au niveau du contrôleur : Rappel du rôle du contrôleur : - Il « utilise » tous les autres composants (base de données, formulaires, templates, etc.) pour générer la réponse suite à notre requête ; - C'est ici que résidera toute la logique de notre site. Un contrôleur du framework Symfony peut rendre : - Soit une Page via le .html.twig correspondant à l’Action en question - Soit un simple massage via la classe Response (à importer si besoin de l’utiliser), pour le message pas besoin d’un fichier .html.twig, il suffit de lui préciser son URL au niveau du fichier routing.yml de notre bundle situé sous le répertoire config sous Resources. 18  Au niveau de la route : Maintenant, il faut aller au fichier routing.yml, pour voir comment indiquer l’URL de chaque Action (voir figure d’après) : ce qu’on renseigne dans « pattern : » c’est ce qu’on va mettre dans notre URL : 19  Au niveau du fichier .html.twig Savez-vous ce qu'est un moteur de 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. Comment ? Avec leur langage à eux. Chaque moteur a son propre langage. Dans un premier, testons notre page index.html.twig avec ce simple code Ensuite ajoutons les balises html En remarque l’ajout de la toolbar sur notre page Par rapport au code : on remarque que le moteur de template twig renseigne ses variables entre {{ variable }} Hello {{ name }} <!DOCTYPE html> <html> <head> <title>Bienvenue </title> </head> <body> <h1>Hello {{ name }}</h1> </body> </html> 20 Expliquer que la variable name est la variable rendu par notre controleur. Repartir sur un autre exemple plus poussé : Au niveau du contrôleur : Au niveau du fichier .html.twig  On remarque que twig insert son propre code entre des {% code ici %} Pour conclure et à titre de révision pratique, vous pouvez reprendre la création d’un bundle sur l’invite de commande. Et pour une révision théorique reprendre la présentation power point en pièces jointes. class DefaultController extends Controller { public function indexAction() { $Message="3aslema"; $T= array("Ameni","Wassim","Patron","Amine","Oussema","Haithem"); return $this->render('EspritEtudiantBundle:Default:index.html.twig', array("Msg" => $Message, "Enseignants" => $T)); } } <!DOCTYPE html> <html> <head> <title>Bienvenue </title> </head> <body> <center><h1> {{ Msg }} </h1><center> <table border="1"> {% for Enseignant in Enseignants %} <tr> <td>{{ Enseignant }}</td> </tr> {% endfor %} </table> < /body> </head> 21 Maintenant, on propose la création d’un tout nouveau projet qu’on appelle Tp et : - La génération d’un bundle EspritBundle sous l’application MyApp, - La configuration de la connexion avec BDD via le fichier parameters.yml - La génération d’une entité Classe ayant comme attributs : nom (string), module (string), nbEtudiant (integer) et annee (date), - La génération de la BDD tp (un choix de garder le même nom du projet mais rien ne nous y oblige), - La génération de la table Classe dans uploads/Management/ support-de-revision-symfony.pdf