Plonger dans Symfony 2

Les frameworks sont des sujets d'actualité dans l'industrie du Web et ce depuis un certain temps. Symfony est une vaste infrastructure PHP qui suit le paradigme très populaire de MVC. Sa courbe d'apprentissage est probablement un peu plus raide que celle de ses concurrents, comme CodeIgniter. Ne vous inquiétez pas, une fois que cela vous envahira, vous vous sentirez plus puissant que jamais et vous pourrez développer des applications fantastiques..


1. Conditions

Dans cet article, vous devrez utiliser un programme de console. Personnellement, j'aime bien Git Bash, mais tout le monde le fera. Vous devez également avoir installé curl pour pouvoir installer Composer..

Si vous êtes un utilisateur Windows, vous pouvez regrouper tout ce qui précède en installant Git pour Windows, qui est disponible ici: Téléchargements Git.


2. Ce que vous apprendrez

Au cours de cet article, vous en apprendrez plus sur:

  • Le flux d’application Symfony
  • Installation de Symfony 2.1 à l'aide de Composer
  • La structure de fichiers et les bundles Symfony
  • La console
  • Routes et contrôleurs
  • Réponses
  • Brindille

3. Un cycle de vie Symfony

Avant que nous ayons les mains sales et graveleuses, je souhaite prendre un moment pour expliquer le déroulement du cycle de vie de Symfony..


La demande

Comme tout le reste du Web, tout commence par une demande. Ceci est pris en charge par Symfony qui le fera correspondre à nos routes définies (ne vous inquiétez pas, cela sera expliqué plus tard), qui sont ensuite associées à des contrôleurs. Nous disons donc à Symfony quelles URL nous voulons faire correspondre avec certains contrôleurs et leurs fonctions.

Le noyau

C'est là que se passe la magie. Symfony va disséquer l’URL et la faire correspondre à l’une de nos routes. Il va ensuite charger le contrôleur que nous avons assigné à la route.

Le controlle

Le contrôleur est chargé et une action donnée est exécutée en fonction de la route..

La réponse

Comme avec une requête HTTP normale, une requête Symfony doit renvoyer un objet de réponse.
L'objet de réponse peut être formé de différentes manières, par exemple avec des en-têtes..
Une action doit retourner un objet de réponse valide sinon une exception sera levée.

Alors maintenant, vous avez une brève introduction à la mécanique de Symfony - maintenant il est temps de plonger dans.


4. Installation via Composer

Les outils disponibles pour faciliter votre processus sont l’un des avantages du développement Web. L'un d'eux est Composer - un gestionnaire de paquets pour PHP. Cet article n'inclura pas les détails d'utilisation de Composer, mais si cela vous intéresse, voici une excellente introduction: Gestion de paquetage facile avec Composer

Tout d'abord, si Composer n'est pas installé globalement, vous pouvez télécharger une installation locale en exécutant la commande suivante:

 curl -s http://getcomposer.org/installer | php

Vérifiez que l'installation a fonctionné en tapant:

 php composer.phar

Si tout se passe bien, vous devriez voir un menu des commandes disponibles. Sinon, vérifiez que vous avez configuré PHP dans vos variables d'environnement.

Nous allons maintenant passer à l’installation de Symfony. Remplacer votre-dossier avec le nom de dossier que vous voulez pour votre projet. Vous pouvez également remplacer la version à la fin par celle de votre choix. Je recommande de vérifier Packagist: Symfony Framework Standard Edition pour la dernière version stable..

 php composer.phar créer un projet symphony / framework-standard-edition votre-dossier / 2.1.4

Vous devriez maintenant voir les dépendances de téléchargement de Composer dans le dossier. Si votre installation s'est bien passée, allez à votre-projet.local / web / config.php - Ici, Symfony vous informera des besoins en serveurs manquants ou des extensions facultatives susceptibles d’améliorer les performances ou de faciliter votre développement..

Une fois que vous avez activé les extensions requises et facultatives, allez à /web/app_dev.php où vous devriez voir un écran de bienvenue avec des liens pour diverses expériences d’apprentissage. Cela signifie que Symfony a été installé avec succès - félicitations!


5. Introduction à la structure de fichiers et aux bundles Symfony

À première vue, votre dossier racine peut sembler un peu déroutant. Ne vous inquiétez pas, il y a une explication logique derrière la structure. Votre racine devrait être composée de ces quatre dossiers et de certains fichiers. Vous pouvez ignorer les fichiers, car ils ne sont pas importants pour le moment..

 app / src / vendor / web /

Le répertoire des applications

C’est là que se trouve la configuration de haut niveau de votre projet. Par exemple, c’est la maison du AppKernel classe qui charge tout votre code et les bibliothèques tierces dans le framework pour votre utilisation.

le app Le répertoire contient également tous les principaux fichiers de configuration, qui contiennent des informations sur la connexion à la base de données, les modèles de sécurité, le routage, etc..

Votre mise en page HTML de base réside également ici.

Le répertoire Src

le src le répertoire est la maison pour tout votre propre code, qui est groupé en paquets.

Qui ou quoi est un paquet?

Tout le code Symfony est regroupé de manière logique dans ce que l’on appelle les bundles. Par exemple, supposons que votre projet ait un système utilisateur, puis tous vos contrôleurs orientés utilisateur, CSS, JavaScript, entités de base de données, etc., seront contenus dans UserBundle. Ce qui est génial avec ce système, c'est que vous pouvez prendre un paquet (par exemple un paquet de gestion des utilisateurs) et le brancher à n’importe quel projet Symfony..

Vous pouvez même télécharger des ensembles prêts à l'emploi à partir de sites Web tels que des ensembles KNP. Parmi les choix courants, citons les ensembles système utilisateur et les ensembles générateur CRUD d’administration. Au moment de la rédaction de cet article, le site comptait 1779 bundles et 4068 développeurs..

Le répertoire des vendeurs

Ici, nous allons stocker toutes les bibliothèques tierces. C'est déjà plein de librairies, par exemple Symfony, Doctrine, Assetic, etc..

Le répertoire Web

Cela devrait être le répertoire racine de votre domaine car il s'agit du seul répertoire accessible au public de votre projet. C'est la maison de vos contrôleurs frontaux app.php et app_dev.php les fichiers, qui sont les deux points d’accès publics à votre application. Un utilisateur entrera sur votre site via une URL telle que /app.php/products/jeans.

  • app_dev.php est le point d’entrée principal lors du développement de votre application. Lorsque vous l'utilisez comme point d'entrée, Symfony ignore la mise en cache et vous fournit une superbe barre d'outils de développement..
  • app.php est le point d'entrée du mode de production. Ceci est effectivement rendu facultatif par mod_rewrite, donc les URL /app.php/products/jeans et / produits / jeans en fait les deux point au même endroit.

6. Coder avec la console… Attendez, quoi?

La console s’est révélée être un outil brillant dans mon processus de développement et je vous dis donc: Tu ne craindras pas ta console, car tu es le créateur de toutes choses.

Pour moi, l’un des aspects (merveilleusement) étranges du passage à Symfony était l’utilisation intensive de la console..

Plongeons-y tout de suite. Ouvrez votre console et localisez la racine du projet. Entrez cette commande:

 app php / console

Ce sont les commandes à votre disposition. La plupart du temps, vous utiliserez les générateurs, le cache et la gestion des actifs. Vous allez également l'utiliser pour générer des ensembles, des schémas de base de données, des itinéraires de débogage, la suppression du cache, etc..


7. Assez parlé. Je veux coder!

Avec quelques connaissances de base sur la structure et la console, vous êtes maintenant prêt à plonger dans Symfony.!

Aller à app_dev.php. L’écran d’accueil que vous voyez ici est en fait un paquet, comme celui que nous allons créer dans une minute. Aller à src / et supprimer le répertoire Acmé. Si vous actualisez la page, vous verrez une erreur. C'est parce que le AppKernel La classe essaie de charger le paquet que nous venons de supprimer. Chaque fois que vous ajoutez ou supprimez un ensemble, vous devez modifier le AppKernel classe.

Tellement ouvert app / AppKernel.php. Vous verrez un tableau un peu comme ceci:

 $ bundles = array (new Symfony \ Bundle \ FrameworkBundle \ FrameworkBundle (), //… Les autres bundles ici);

C'est là que vous allez initialiser de nouveaux lots. Si vous créez un ensemble via la console, il sera ajouté automatiquement..

Plus bas, vous devriez voir un if-block comme ceci:

 if (in_array ($ this-> getEnvironment (), array ('dev', 'test')))) $ bundles [] = new Acme \ DemoBundle \ AcmeDemoBundle (); //… d'autres offres ici

Il s’agit de bundles de développement, c’est-à-dire qui ne sont chargés que lorsque vous vous trouvez dans l’environnement de développement (app_dev.php). Vous verrez que c'est ici que notre groupe supprimé est initialisé. Retirer le AcmeDemoBundle ligne et enregistrer le fichier.

Si vous actualisez, vous verrez maintenant la page d'exception Symfony. C’est là que toutes les exceptions interceptées vous redirigeront et afficheront plus d’informations. Vous verrez une exception qui ressemble à ceci:

 Impossible d'importer la ressource "@ AcmeDemoBundle / Controller / SecuredController.php"… 

En effet, Symfony recherche des itinéraires définis dans le fichier du contrôleur. SecuredController.php (qui était dans le AcmeDemoBundle supprimé).

Alors, quel est un itinéraire?

Le moment est probablement venu d’expliquer un peu plus les itinéraires. Fondamentalement, une route est un modèle d'URL. Imaginez que vous ayez un blog, avec des articles, dans différentes catégories. Donc, vous voudrez que l'utilisateur entre dans une URL quelque chose comme ceci:

 www.myblog.com/categories/Category1 www.myblog.com/categories/Category2 et ainsi de suite… 

Dans Symfony, vous pouvez définir des modèles d’URL que vous associez à un contrôleur. Imaginez l'exemple précédent. Vous auriez besoin d'une fonction, qui aurait reçu le nom de la catégorie et recherché les articles de blog l'utilisant. Dans une application MVC, et donc dans Symfony, cette fonction est encapsulée dans un contrôleur. Donc, cela ressemblerait en gros à ceci:

 class ControllerExample fonction publique showCategory ($ category_name) // extrait les billets de blog par nom de catégorie et les affiche

Remarque: ceci n'est pas un code Symfony valide, mais un exemple de contrôleur de blog simple..

Il ne vous reste plus qu'à relier l'action du contrôleur et l'URL. Cela se fait par des routes. L'itinéraire dans ce cas ressemblerait à ceci:

 / catégories / nom

Lorsqu'une chaîne est écrite entre accolades, elle est interprétée comme une variable, qui est ensuite transmise à l'action donnée. Dans Symfony, vous pouvez définir des itinéraires en XML, YML ou par annotations. Pour rester simple, nous n'utiliserons que des annotations dans ce tutoriel..

Vous pouvez voir tous les itinéraires définis à l'aide de la commande suivante dans la console:

 app php / routeur de la console: debug

Mais rappelez-vous, nous avons eu une erreur. En effet, Symfony est toujours à la recherche des itinéraires définis dans notre AcmeDemoBundle contrôleur (qui n'existe pas). Alors ouvre-toi app / config / routing_dev.yml et pour le moment, tout ce que vous devez savoir, c’est que tous les itinéraires sont définis ou importés dans routage.yml et routing_dev.yml. Supprimer le _demo, _Bienvenue et _demo_secured clés. Si vous actualisez, vous verrez maintenant Aucun itinéraire trouvé pour "GET /". Ceci est dû au fait qu’aucun itinéraire ne correspond à l’URL actuelle. Faisons-en un qui.

Mais d'abord, un contrôleur

Lorsque vous écrivez des itinéraires sous forme d'annotations, vous les écrivez juste au-dessus de l'action que vous souhaitez exécuter lorsqu'un utilisateur entre l'itinéraire indiqué. Par conséquent, nous avons besoin d’un paquet qui contiendra notre contrôleur et notre action..

Ouvrez votre console et entrez la commande suivante:

 php app / console générer: bundle

Tout d'abord, vous devez entrer l'espace de noms de votre bundle. Le modèle général pour ceci est:

 Vendor / BundleName

Le vendeur est l’auteur du paquet. Ici, vous pouvez indiquer le nom de votre entreprise ou celui que vous préférez. J'aime utiliser mes initiales EP. Utilisez ce que vous voulez, mais soyez bref.

Le nom du paquet doit se terminer par Bundle. Je vais donc entrer dans ce qui suit:

 EP / BlogBundle

Ensuite, vous pouvez choisir le nom que vous voulez utiliser pour identifier le paquet dans votre code.
J'ai l'habitude d'omettre le nom du vendeur, mais dans l'intérêt de ce tutoriel, appuyez simplement sur Entrée..
Il y a plus d'étapes dans le générateur, mais vous voudrez les valeurs par défaut pour ce tutoriel, donc appuyez simplement sur Entrée jusqu'à ce que vous ayez terminé..

Ouvert src / YourVendorName / BlogBundle / dans votre éditeur. Vous verrez qu'une structure de base de paquet a été créée pour vous. Pour le moment, nous allons ignorer les détails et aller directement au répertoire du contrôleur. Ouvrir DefaultController.php dans le contrôleur /.

Cela ressemble beaucoup à l'exemple de base que j'ai écrit précédemment, sauf que le contrôleur est un dérivé de Controller - une classe du bundle de framework Symfony, qui contient les fonctionnalités de base d'un contrôleur..

Si vous regardez l'action, vous remarquerez des annotations qui ressemblent à ceci:

 / ** * @Route ("/ hello / name") * @Template () * /

le @Route une annotation indique à Symfony que nous voulons faire correspondre l'itinéraire / bonjour / nom avec l'action \ EP \ BlogBundle \ Controller \ DefaultController :: indexAction () et qu'il existe une variable appelée prénom dans l'URL. Donc, si quelqu'un entre des URL similaires à celles-ci:

 www.myblog.com/hello/Esben www.myblog.com/hello/Santa www.myblog.com/hello/Jesus

… Ils iront tous au même endroit, car ils seront tous jumelés au / bonjour / nom route.

le @Modèle L'annotation indique à Symfony quelle vue utiliser. Lorsqu'il est laissé vide, Symfony déterminera quelle vue utiliser en fonction du nom du contrôleur et du nom de l'action..

Mais toutes les actions ne doivent pas renvoyer un objet de réponse valide?

L'observateur Padawan aura déjà remarqué qu'il n'y a pas d'objet de réponse renvoyé dans cette action, ce qui, selon moi, était une exigence antérieure dans l'article.

Une réponse est un objet contenant le code que vous souhaitez afficher, les codes de service, les en-têtes, etc. Par exemple, si vous souhaitez afficher une page "Hello World", vous ferez quelque chose comme ceci:

 renvoyer nouvelle réponse ('Hello World!', 200);

Si vous voulez créer une page pour un appel AJAX, procédez comme suit:

 return new Response (json_encode (array ('une_variable' => 'une certaine valeur')), 200, array ('content-type' => 'application / json'));

Si vous voulez rediriger l'utilisateur, vous pouvez le faire avec un RedirectResponse objet.

Remarque: Vous pouvez toujours modifier votre réponse en fonction de vos besoins - codes de statut, en-têtes, etc. Rien n'est interdit.

Normalement, si vous voulez rendre une vue à l'utilisateur, vous retournerez un nouvel objet de réponse comme celui-ci:

 return $ this-> conteneur-> get ('templating') -> renderResponse ('EPBlogBundle: Par défaut: index.html.twig', array ('name' => $ name));

C'est un long raccourci qui renvoie un objet de réponse avec un modèle de rendu comme contenu. Heureusement, la classe de contrôleur de base, à partir de laquelle notre contrôleur s'étend, dispose de nombreuses fonctions de raccourci astucieuses. Nous pouvons utiliser ses rendre() méthode pour nous faire gagner du temps:

 return $ this-> render ('EPBlogBundle: défaut: index.html.twig', array ('name' => $ name));

Ceci est juste un raccourci vers la première méthode que j'ai montrée ci-dessus. Le premier paramètre est la vue à rendre. Tous nos points de vue sont dans notre paquet dans Ressources / vues /. Les vues sont séparées dans des répertoires basés sur le contrôleur responsable de la vue. D'où la convention de nommage Bundle: Controller: Voir.

Votre vue de présentation de base (le modèle principal de votre application) est en app / Ressources / vues /. Comme il ne figure dans aucun répertoire de paquet ni de contrôleur, il est simplement appelé :: base.html.twig. Une vue de votre bundle, qui est placée dans le répertoire racine bundle-views, est appelée Bundle :: View..

 app / Resources / views / base.html.twig // :: base.html.twig src / BlogBundle / Ressources / views / someView.html.twig // EPBlogBundle :: someView.html.twig src / BlogBundle / Resources / views /Default/index.html.twig // EPBlogBundle: Défaut: index.html.twig

Et enfin, le deuxième paramètre de notre rendre() fonction sont les variables que nous voulons accessibles dans notre vue.

Templating Avec Rameau

Twig est un moteur de template créé par Sensiolabs - les créateurs de Symfony. Symfony est fourni avec Twig, bien que son utilisation ne soit pas obligatoire.

Twig présente de nombreuses fonctionnalités intéressantes qui vont au-delà de la portée de cet article, mais n'hésitez pas à les consulter sur le site officiel de Twig.

Si vous ouvrez EPBlogBundle: Par défaut: index.html.twig vous verrez le code qui ressemble à ceci:

 Bonjour name!

Brindille utilise et %% comme balises de début et de fin. Double accolade signifie produire quelque chose, semblable à l’équivalent PHP de . Alors prénom des moyens pour sortir la valeur de notre variable $ name (que nous avons dit à Symfony que nous voulions utiliser lorsque nous avons créé notre objet de réponse).

Pour vous donner un petit échantillon de la génialité de Twig, je vais vous montrer quelques filtres. Un filtre est une fonction que vous pouvez appliquer à une variable. C'est appliqué en utilisant cette syntaxe var | filtre. Voici quelques exemples.

 name | upper // renvoie la variable en UPPERCASE name | length // renvoie la longueur de la variable name | code_URL // renvoie la version codée de l'URL de la variable

Vous pouvez voir une liste complète des balises, filtres et fonctions dans la documentation officielle de Twig. Ce qui rend vraiment Twig génial, c’est qu’il est très facile de créer vos propres filtres et fonctions. Mais vous devrez attendre un autre tutoriel pour plus d'informations sur Twig et son extensibilité..


Conclusion

C'est la fin de notre magnifique voyage - et quelle aventure!

Nous avons non seulement appris la structure de Symfony et de ses bundles, mais également la puissance des routes et de leurs contrôleurs. Saupoudrez ceci avec un peu de brindille et vous aurez découvert Symfony! Je reviendrai bientôt avec des tutoriels plus approfondis sur des sujets plus spécifiques tels que la gestion d'actifs avec Assetic et les modèles avec Twig. Merci d'avoir lu.