Installation et paramétrage

POO3 : Application web TD1 1) Introduction 2) Installation de Symfony 3) Configuration d’apache 4) Création d’un bundle 5) Les premiers templates 6) Créer la page d’accueil et la page de contact 7) Définir les modèles et les actions sur ces modèles 1) Introduction Vous devrez développer au cours des TD une application web relativement simple comprenant au minimum : -­‐Une page statique (la page « à propos ») -­‐Un objet (autre que les utilisateurs) stocké en base de donnée -­‐La possibilité de s’authentifier sur le site -­‐Au moins deux rôles d’utilisateurs (un rôle utilisateur et un rôle administrateur) Vous devrez de plus : -­‐Utiliser (correctement) le framework symfony -­‐Écrire des tests pour les fonctionnalités développées -­‐Utiliser les aides apportées par le framework (pour la création d’url par exemple) Je vous propose de développer un blog à l’aide du framework Symfony. Un blog est une application simple qui comprend l’ensemble des contraintes exposées ci-­‐
dessus. Les exemples des TDs seront basés sur la construction d’un blog. Les informations fournies dans les TDs sur les chemins d’accès aux fichiers de configuration et autres supposeront aussi que vous travaillez sous Linux. Vous êtes libre de développer un autre type d’application si vous le souhaitez. Si tel est le cas, venez me voir et exposez moi votre projet afin que nous en fixions ensemble les limites pour que cela soit réalisable au cours des séances de TD. Dans cette première séance nous allons d’abord installer Symfony et vérifier que l’ensemble des dépendances nécessaires est installé. Nous verrons ensuite comment configurer apache pour qu’il serve notre installation Symfony. Puis nous créerons notre application Symfony ainsi que ses premières pages. 2) Installation de Symfony Nous travaillerons avec la dernière version du framework Symfony2. Ce framework est disponible via Composer, un logiciel permettant de gérer des dépendances en PHP, et utilise ce dernier pour gérer les dépendances do vos projets Symfony à d’autres bibliothèques PHP. Symfony peut donc être installé par l’intermédiaire de Composer. On peut aussi installer Symfony en le téléchargement simplement sur le site officiel. Installation via composer : Téléchargez Composer : http://getcomposer.org/ Le fichier composer.phar est une archive exécutable PHP. Pour l’utiliser, il suffit de faire : $ :>php composer.phar <commande> [options]
Pour commencer un nouveau projet Symfony il suffit de faire : $ :>php composer.phar create-project symfony/frameworkstandard-edition path/to/install 2.2.0
Cela téléchargera Symfony 2.2.0 sur votre machine dans le dossier path/to/install. A vous de changer ce chemin pour mettre le projet dans le dossier de votre choix, ce dossier doit être vide pour que composer effectue l’installation. Vous devriez avoir une arborescence de fichier ressemblant à celle ci-­‐dessous qui a été créé : Installation via téléchargement sur le site de Symfony Rendez vous sur la page : http://symfony.com/download Sélectionnez Symfony Standard 2.2.0 et cliquez sur « download now ». Désarchivez le fichier où vous souhaitez mettre votre application Symfony. Vous devriez avoir la même arborescence de fichier que celle présentée au dessus. Vérification de la compatibilité du système Il convient ensuite de vérifier que vous avez tout ce qui est nécessaire pour exécuter Symfony sur votre machine. Pour ce faire, exécutez le script check.php qui se trouve dans le dossier app/ de votre installation symfony : $ :>php ./app/check.php
Le résultat du script devrait donner quelque chose ressemblant à ce que vous pouvez voir ci-­‐dessus. Réglez au minimum tous les problèmes critiques et, si possibles, les WARNING. L’installation d’un accélérateur PHP n’est dans tous les cas pas nécessaire pour notre utilisation. La plupart des modifications sont à faire dans la configuration de php, c’est-­‐à-­‐
dire le fichier php.ini. 3) Configuration d’apache Afin d’accéder à notre application depuis un navigateur, nous allons utiliser un serveur web. Ce dernier sera chargé d’exécuter notre application php et de retourner les résultats générés au navigateur. Nous utiliserons Apache2 comme navigateur web. Ce dernier présente plusieurs fichiers de configuration : /etc/apache2/apache2.conf
/etc/apache2/mods-available/*.conf
/etc/apache2/sites-available/*
Le premier est le fichier de configuration principal, il contient quelques configurations générales. Le dossier mods-­‐available contient l’ensemble des modules disponibles. Pour chaque module un fichier .conf permet de configurer des options spécifiques au module. L’activation d’un module se fait via la commande : sudo a2enmod nomDuMod
La désactivation d’un module se fait via la commande : sudo a2dismod nomDuMod
Le dossier sites-­‐available contient des configurations d’hôtes virtuels (Virtual Host) pour chaque site accessible sur la machine. Cela permet d’avoir plusieurs sites internet hébergés sur la même machine mais associés à différents noms de domaines ou différentes IP. L’usage veut que l’on crée un fichier de configuration par site. Ce n’est pas une obligation vis à vis d’apache mais cela permet d’activer séparément chaque site et de conserver une certaine clarté dans la configuration. L’activation d’un site se fait via la commande : sudo a2ensite nomDuSite
La désactivation d’un site se fait via la commande : sudo a2dissite nomDuSite
Pour qu’un changement de configuration soit pris en compte, il faut redémarrer le service apache via la commande : sudo service apache2 restart
Voyons maintenant comment de quoi est constitué la configuration d’un hôte virtuel afin d’en créer un pour notre application Symfony. Le fichier ci-­‐dessus est un fichier présentant un VirtualHost simple. Les lignes commençant par # sont des commentaires. Votre définition de VitualHost, que vous mettrez dans le dossier/etc/apache2/sites-­‐available/ devra ressembler à celle ci-­‐dessus (aux chemins près). Une fois votre fichier créé, il vous suffit de l’ajouter aux sites actifs (via la commande a2ensite) et de redémarrer Apache (comme montré précédemment). Votre site devrait maintenant être accessible. Pour le voir, si vous n’avez pas utilisé la directive ServerName, il vous suffit de vous rendre à l’adresse http://127.0.0.1/config.php. Sinon, il vous faudra ajouter une entrée à votre fichier hosts (voir “La directive ServerName“ plus bas). Vous pourrez ensuite y accéder via l’adresse http://localhost.symfony/config.php si je reprends l’exemple ci-­‐dessus. Remplacez localhost/symfony par le nom que vous avez mis pour le ServerName. Attention toutefois, Apache est exécuté sous le nom d’utilisateur et le groupe www-­‐data. Ce dernier doit pouvoir accéder au dossier web et lire les fichiers qu’il contient. De même, il doit pouvoir écrire dans les fichiers de log de Symfony et accéder aux fichiers de cache. Le plus simple est donc de donner (via la commande chown) l’ensemble de votre dossier Symfony à l’utilisateur www-­‐
data pour avoir le moins de problèmes possible. Si vous laissez les fichiers dans votre groupe d’utilisateur par ailleurs et que vous mettez les droits d’écriture et de lecture au groupe, vous devriez pouvoir développer sans soucis. Je vais tout de même vous détailler la fonction de chacune des directives. La directive <VirtualHost> <VirtualHost> et </VirtualHost> délimitent la définition de cet hôte. La syntaxe utilisée est la suivante : <VirtualHost adresse[:port] [adresse[:port]]>
L’argument nécessaire adresse correspond à l’adresse IP sur laquelle sont adressées les requêtes associées à l’hôte virtuel. Il peut être défini à une adresse particulière ou à * pour signifier que le VirtualHost écoute sur toutes les adresses. Le port (optionnel) permet de préciser un port spécifique en plus de l’adresse. Le port standard de communication pour le protocole http est le port 80. Pour mieux comprendre à quoi correspond cette adresse, il faut retracer le chemin parcouru par une requête. Lorsque vous entrez une adresse web dans votre navigateur, celui-­‐ci commence par effectuer une recherche DNS pour savoir à quelle adresse IP il peut joindre le serveur qui saura répondre à cette requête. Une fois cette adresse obtenu, il contact le serveur situé à cette adresse IP avec votre requête. Apache (en supposant que le serveur contacté utilise Apache) va alors regarder si un hôte virtuel peut être contacté sur cette IP, et, s’il en trouve un, va regarder la configuration de l’hôte pour savoir que faire exactement. Par exemple dans l’illustration ci-­‐dessous, Apache ne s’intéressera pas au premier VirtualHost car l’IP n’est pas celle demandée. Il regardera en revanche plus en détail le second car l’IP correspond. 173.194.66.139 www.google.com DNS www.google.com 173.194.66.139 Apache <VirtualHost 173.194.66.100 :80> … </VirtualHost> <VirtualHost 173.194.66.139 :80> … </VirtualHost> Client Réponse Cette configuration contient ensuite un certain nombre de directives qui peuvent ou non être des balises et permettent de configurer les propriétés du VirtualHost. La directive ServerAdmin Syntaxe : ServerAdmin adresse_de_contact
Cette directive permet de dire à Apache quelle adresse de contact mettre lorsqu’il envoie un message d’erreur suite à une requête sur cet hôte. C’est le plus souvent une adresse mail mais cela peut aussi être une URL pointant vers un autre serveur vous appartenant et permettant de laisser un message. Cela permet d’avoir des retours des utilisateurs lorsqu’ils rencontrent des problèmes d’accès au serveur. La directive ServerName Syntaxe : ServerName mon.domaine.com
Permet de définir, en plus de l’IP, le nom du serveur. Permet d’avoir plusieurs sites hébergés sur la même IP du moment qu’ils ont des noms différents. L’hôte virtuel ne sera desservi que si la requête est adressée à la bonne IP et au bon nom. Si vous mettez un nom à votre serveur il faudra ajouter une entrée au fichier /etc/hosts du type : 127.0.0.1 mon.domaine.com
Vous pourrez alors accéder à votre site dans votre navigateur via l’adresse mon.domaine.com. La directive DocumentRoot Syntaxe : DocumentRoot /chemin/absolu/vers/la/racine
Définit où se trouve la racine du site web associé à cet hôte dans l’arborescence de fichier du serveur. Pour notre application Symfony, le chemin doit pointer sur le dossier web de notre installation Symfony. La directive <Directory> Syntaxe : <Directory “/mon/repertoire“> … </Directory>
Cette directive permet de définir des propriétés spéciales que ne s’appliqueront qu’au répertoire spécifié. Toutes les Directives spécifiées entre les deux balises ne s’appliqueront qu’à ce répertoire. La directive Options Syntaxe : Options option1 option2 …
Permet d’ajouter des options dans la gestion du dossier. Se référer à la documentation d’Apache pour plus d’informations. La directive AllowOverride Syntaxe : AllowOverride Value
Autorise l’utilisation d’un fichier .htaccess pour spécifier des règles particulières pour certains dossiers. Les règles que l’on peut redéfinir sont spécifiées par “Value“, qui peut prendre les valeurs spéciales All et None ou une liste de règles. Voir la documentation d’Apache pour plus de détails. Nous mettons ici All car nous spécifierons quelques règles spéciales dans notre dossier web à l’aide d’un fichier .htaccess. La directive Order et les directives Allow et Deny Syntaxe : Order Allow, Deny (ou Deny, Allow)
Allow from all (ou une liste de domaines ou d’IP)
Deny from all (ou une liste de domaines ou d’IP)
Ces directives permettent de déterminer qui a accès au contenu du dossier. Order définit dans quel ordre sont évaluer les autorisations, sachant que la dernière règle l’emporte. C’est-­‐à-­‐dire que si une requête match à la fois une règle de Allow et une règle de Deny, c’est le dernier élément définit dans Order qui l’emporte (dans le fichier exemple, c’est Deny donc la requête est rejeté). De même si une requête ne match aucune règle, c’est le dernier élément qui l’emporte. Les directives Allow et Deny permettent de définir l’ensemble des provenances autorisées (Allow) et refusées (Deny). Le mot clé all désigne l’ensemble des requêtes, s’il n’est pas utilisé, il est possible de mettre une liste d’hôte ou d’IP pour lesquels l’accès est autorisé ou refusé. Ceci peut-­‐être pratique pour autoriser l’accès à un intranet seulement à partir de certaines IP par exemple. Pour notre application nous autorisons tout le monde à accéder au dossier web puisque c’est la que se font toutes les requêtes pour accéder à notre application Symfony. Vérification du bon fonctionnement Chargez la page http://127.0.0.1/config.php ou http://localhost.symfony/config.php suivant que vous ayez utilisé une directive ServerName ou non. Vous devriez voir une page vous souhaitant la bienvenue et vous disant si votre installation permet une bonne exécution de Symfony ou non. S’il y a des problèmes critiques il faut y remédier, certains warning peuvent être ignorer (notamment l’utilisation d’un accélérateur PHP qui n’est pas nécessaire). Si ce n’est pas le cas : criez au secours (ou tentez de résoudre le problème). Si tout c’est bien passé : Félicitation, vous avez une installation de Symfony fonctionnelle. 4) Création d’un bundle Maintenant que le travail de configuration long et fatigant est terminé, nous allons pouvoir créer notre bundle. Ce dernier contiendra tout ce qui est nécessaire à notre application (contrôleurs, vues, images, css, configurations spécifiques, etc.). Pour cela, rien de plus simple. Placez-­‐vous à la racine de votre installation Symfony (répertoire parent du répertoire app) et entrez la commande : $ :> php app/console generate:bundle --namespace=Blogger/BlogBundle -format=yml
Vous pouvez définir le namespace que vous voulez, la seul obligation étant qu’il finisse par “Bundle“. Essayez de mettre un nom correspondant à votre application. Des questions vous serons posées, les réponses par défaut devraient suffire, il vous faudra donc simplement appuyer sur Entrée. Vous voilà avec un nouveau dossier dans src/ contenant votre nouveau bundle qui a été au passage enregistré dans le noyau (kernel) de l’application. Il sera donc automatiquement chargé par Symfony et sera donc accessible. Le bundle est fournis par défaut avec un petit contrôleur poli qui sait dire bonjour. Vous pouvez le tester en vous rendant à l’adresse : http://symfony.localhost/hello/prenom. Évidemment il faudra remplacer symfony.localhost par ce qui est nécessaire selon votre configuration. La page affichée devrait vous dire bonjour. 5) Les premiers templates Les templates sont rangés en fonction de leur portée à différents endroits. • app/resources/views contient des templates globaux qui peuvent être utilisés par l’ensemble des bundle de l’installation. • Src/myBundle/resources/views peut contenir des templates utilisable pour l’ensemble d’un bundle • Src/myBundle/resources/views/myController/myAction.html.twig correspond au template qui sera utilisé pour l’affichage du résultat de l’action « myAction » du contrôleur « myController » Cette séparation permet de créer des templates contenant la structure principale des pages de façon globale. Puis d’hériter de ces templates pour créer des vues particulières. Nous ne créerons pas de template global à l’installation. Nous allons en revanche créer un template de base pour notre bundle, blogBase.html.twig, qui pourra s’appuyé sur le template global fourni par symfony : app/resources/views/base.html.twig. Notre template sera stocké dans src/blogger/blogbundle/resources/views/. blogBase.html.twig va définir la forme globale de la page, avec l’en-­‐tête, le menu etc. Un exemple de template très basique est donné ci-­‐dessous, à vous ensuite de lui appliquer une feuille de style et de le modifier pour refléter ce que vous voulez faire.
Ce template hérite du template global base.thml.twig. Il redéfinit un certain nombre de block afin d’effectuer les modifications nécessaires pour personnaliser l’apparence globale des pages de notre blog. Dans le langage de twig, la « balise » {% %} signifie que l’expression à l’intérieur est une expression de contrôle pour twig, la définition d’un block, un if ou une boucle. En revanche, la balise {{ }} signifie que twig doit évaluer l’expression écrite à l’intérieur et écrire le résultat à la place de la balise dans la page. Dans ce template, un appel à la fonction asset() est fait. Cette fontion permet de récupérer l’adresse d’un asset (image, feuille de style script javascript etc.) en fonction de la configuration de Symfony. Ceci permet de pouvoir copier un bundle d’un emplacement à un autre sans avoir à changer l’ensemble des liens. Mais cela demande aussi une certaine discipline quant au stockage des assets. En effet, pour que tout fonctionne bien, toute vos images, feuilles de style et autre scripts devront être stockés dans le dossier src/Blogger/BlogBundle/resources/public/. Vous pouvez, et c’est fortement conseillé, créer des sous dossiers dans le dossier public. Des dossiers img, js, css par exemple. L’installation des assets se fait ensuite via la commande : $ :>php app/console asset :install Cette commande va copier l’ensemble du contenu du dossier public de tous les bundles dans des dossiers du type ‘web/bundles/nomdubundle. La fonction asset permet alors d’y faire référence en donnant un chemin de la forme : bundle/nomdubundle/chemin/depuis/public/wander.css 6) Créer les pages d’accueil et de contact Pour créer ces pages il nous faudra : • Créer des actions correspondant à ces pages dans le contrôleur que nous avons à disposition • Créer des routes permettant d’accéder à ces actions • Créer les templates (les vus) correspondantes 1) Création des actions Les actions des contrôleurs dans Symfony ne sont ni plus ni moins que des fonctions dont le nom se termine par Action. Celles-­‐ci peuvent prendre autant de paramètres que nécessaire, ceux-­‐ci seront remplis automatiquement à partir des informations fournis dans l’url via la configuration de routing (nous verrons ça juste après avoir défini nos actions). Ouvrez le contrôleur DefaultController de votre bundle. Celui-­‐ci devrait contenir une méthode appellée indexAction prenant pour paramètre une variable $name. Cette méthode va nous servir pour afficher notre page d’accueil. Pour se faire nous allons supprimer l’argument $name de la méthode. Nous allons aussi transformer l’appel à render pour qu’il ressemble à ceci : Return $this->render(‘BloggerBlogBundle:Default:index.html.twig');
Créez en même temps une méthode contact ne prenant pas de paramètre et rendant le template BloggerBlogBundle :Default :contact.html.twig. La notation BloggerBlogBundle :Default :contact.html.twig signifie en fait : Mon template se trouve dans le bundle BloggerBlogBundle, dans le dossier Default, et il s’appelle contact.html.twig. Il est d’usage que le nom de dossier corresponde au contrôleur auquel est associé la vue. Nos actions sont maintenant prêtes. Il est temps de créer des routes permettant d’y accéder. 2) Créer les routes La configuration des routes pour notre bundle se fait dans le fichier src/Blogger/BlogBundle/Resources/config/routing.yml. Ce fichier doit déjà contenir une route permettant d’accéder à l’action index : blogger_blog_homepage:
pattern: /hello/{name}
defaults: { _controller:
BloggerBlogBundle:Default:index }
La première ligne est le nom de la règle de routage. Il doit être unique dans l’ensemble de l’installation, c’est pourquoi il commence souvent par le nom du bundle. Il n’a pas d’intérêt particulier pour nous. La ligne pattern définit la forme des url qui sera traitées par cette règle. Ici, toutes les urls de la forme /hello/ suivies de n’importe quoi (ne comportant pas de « / »). Enfin defaults permet de dire quelle action appeler pour appliquer cette règle. Nous allons redéfinir cette règle en mettant simplement « / » pour le pattern. Ainsi, lorsqu’un utilisateur arrivera sur notre site, il sera diriger directement vers la page d’accueil (l’action index du contrôleur Default). Vous remarquerez au passage qu’il n’est pas nécessaire de mettre le nom complet de la classe contrôleur ni de l’action. Seul la partie précédant Controller ou Action est nécessaire. Vous pouvez créez une deuxième règle permettant d’accéder à la page de contact via l’url /contact par vous-­‐même. 3) Les templates Vous allez maintenant devoir créer les templates correspondant à ces actions. Le premier, index.html.twig, existe déjà mais ne contient rien d’intéressant. À vous de le faire héritez de votre template de bundle et d’y afficher des informations pertinentes. La description du sujet du blog par exemple, en attendant d’avoir des choses plus intéressantes à montrer. Vous devrez aussi créer le template contact.html.twig dans le même dossier. A vous de lui faire afficher les informations nécessaires pour vous contacter (adresse mail, réseaux sociaux, …). Effectuez la commande d’installation des assets présentée précédemment si avez utilisé des images, css etc. puis essayez d’accéder aux adresses : http://localhost.symfony/ et http://localhost.symfony/contact pour voir vos nouvelles pages si tout va bien. 7) Création des modèle et définitions des actions Si vous avez terminé tout ce qui précède, il est temps de vous demander quels objets va contenir votre application (pour un site de e-­‐shopping ce serait des produits, des utilisateurs, des avis sur les produits, etc.), les liens entre les objets et les actions possibles sur ces objets. Venez me voir lorsque vous aurez fini pour que l’on en discute.