Développez votre site web avec le framework Symfony

Tout le monde se secoue ! 

J’ai commencé (lundi 14 juillet 2014 à 02h24) la rédaction d’un tutoriel au doux nom de « Développez votre site web avec le framework symfony2 » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Pour une première publication, je vais « simplement » adapter à Symfony 5, je verrai si j’introduis d’autres informations quand il faudra réadapter pour la version 6 en novembre.

Je suis déjà repassé à grands coups sur les parties I à III ainsi que les deux premiers chapitres de la partie IV pour ce qui est du fond (apparemment j’ai oublié la partie sur les traductions qui avait déjà été remodelée). J’aurais envie qu’on me fasse des remarques sur la forme, notamment la cohérence des sujets dans les phrases : j’ai tendance à être impersonnel et aurais envie de le modifier en ce sens à terme, le tutoriel a été rédigé à la première personne. Dans certains cas ça peut coexister, dans d’autres cela vous paraîtra flagrant que ce n’est pas le cas : merci de me le signaler. 

Il y aura des renommages (on ne peut décemment pas conserver « Symfony2 » dans les titres), mais je les ferai plus tard (des histoires de synchronisation après édition hors-ligne). Je crois cependant avoir traqué la plupart des occurrences dans l’entier du tutoriel.

Bonjour Ymox,

Ça serait cool d’avoir un cours sur Symfony 5 ! Cependant, j’ai peur que modifier un contenu écrit pour SF2 soit contre-productif. Il y a tellement de choses qui ont changé… Tant sur le framework en lui-même (j’ai parcouru un peu le début, il est fait mention d’une route en Yaml, or désormais Symfony préconise les annotations) que sur la création de nouveaux composants (Messenger, Workflow, Mailer, String, etc.) ou bundles (MakerBundle, API Platform, etc.) ou l’évolution de la partie front (bye bye Assetic, bonjour Webpack).

Selon moi la première chose à faire, avant de revoir le contenu, est de revoir le plan. Quand je vois le chapitre concernant les ParamConverters dans la dernière partie du cours (et je te dis ça alors que c’est moi à l’époque qui ai validé le plan avec Winzou…), clairement ça ne va pas. Je pense que ce n’est pas un dépoussiérage dont a besoin ce cours, c’est une réécriture presque complète, depuis zéro; en reprenant pourquoi pas des morceaux déjà écrits (globalement l’explication sur le routeur est toujours bonne).

Dans tous les cas, vaste chantier. Je veux bien filer un coup de main, mais selon moi faire des retours maintenant n’a pas de sens car la MAJ n’est pas assez avancée.

Je suis dispo si tu veux en discuter plus en profondeur.

Alors je n’ai aucun doute sur le fait qu’il y a des parties qui vont disparaître ou qui demandent plus que de simples adaptations — voir notamment la partie sur les services que j’ai déjà repris, du fait qu’il est désormais recommandé de réellement les injecter grâce à l’autowiring et d’oublier un peu $this->get('…'). A noter que tout ce que tu mentionnes est dans la partie sur laquelle je n’ai pas encore fait beaucoup, notamment parce que je sais pertinemment qu’il y a "un peu plus de travail"… 

Le fait que Symfony préconise l’un ou l’autre format pour les routes (dès le départ cela a été les annotations, comme pour les mappings), la traduction (qui a toujours été le XLIFF malgré le fait que l’extraction se faisait par défaut en YAML jusqu’à récemment) ou même la configuration¹ n’empêche pas le tutoriel d’être utilisé, et cela permet de mettre à jour le strict minimum pour que les débutants puissent s’en sortir s’ils n’ont (comme très souvent) pas fait attention à la version à installer (d’ailleurs, il faut que je la précise dans la commande). D’ailleurs, je ne suis pas très chaud de suivre la voie officielle pour l’installation avec le binaire Symfony et utiliser le serveur pur PHP. D’une part, les dépendances s’installent ensuite avec Composer, et d’autre part, on nous serine avec le fait que notre environnement de développement doit être le plus proche possible de celui de développement, et on nous fait utiliser un serveur que personne n’utilise pour publier ? Certes, dans le monde professionnel on a plusieurs environnement avant la publication, mais pour les amateurs, on leur dit de prévoir une instance supplémentaire juste parce que comme ça ils suivent les recommandations de Symfony sur leur machine ?

Sinon, j’avoue que je ne me rendais pas vraiment compte de tout ce que ces recommandations impliquaient comme retouches avant de reprendre les points généraux il y a un mois et demi, et pour le coup, je préférerais adapter ce qui change beaucoup et supprimer ce qui peut l’être (ça viendra une fois que j’aurai plus ces soucis de synchronisation) que tout refaire de A à Z, autant garder cela pour une publication suivante sinon la version 6, sans quoi on peut effectivement oublier avoir quelque chose pour la version 5 même si la fin de vie est prévue pour novembre 2024 — ce qui laisse de la marge, certes.

Edit

Si tu as des changements concrets à proposer pour la structure des trois premières parties, c’est très volontiers qu’on en discute ici. 

Avant même de parler structure, il faut parler contenu général.

Ce tutoriel a été écrit pour Symfony 2.8, il y a plusieurs années (dépôt légal mars 2013 pour le livre). Depuis, le web a énormément évolué. Le fil rouge du blog par exemple ne me semble plus en adéquation avec ces évolutions. On pourrait imaginer un tutoriel sous forme de repo git pour le code, avec des branches correspondant aux parties / chapitres, avec pourquoi pas du Docker intégré, etc. Bref, profiter de tout ce qu’on a aujourd’hui à disposition et qui était plus difficile à l’époque.

Étendre le tutoriel à autre chose que simplement Symfony (Docker, Webpack et JS, composer, git, etc.) serait à mon sens une plus-value, car il n’apprendrait pas uniquement aux lecteurs comment développer avec Symfony, mais comment développer une application de manière générale. Cela ajoute du travail, mais à mon sens c’est nécessaire pour capter la plus grande audience possible.

C’est la question qu’il faut se poser avant tout chose : que veux-tu pour ce tutoriel et jusqu’où es-tu prêt à aller ?

Comme dit dans le titre de ce sujet, je souhaite effectuer un dépoussiérage du tutoriel. Ce que j’entends par là, c’est :

1. de mettre à jour les parties qui posent problème pour ceux qui suivent le tutoriel actuel sans faire attention à la version pour laquelle il est fait, et qui installent ainsi la dernière en date sans savoir que ça a changé ;
2. de supprimer ce qui n’a plus lieu d’être (composants dépréciés ou supprimés) ;
3. d’expliquer dans une certaine mesure les différences entre les versions de Symfony au niveau de la réalisation des points abordés.
   Cela sert en partie d’historique, mais aussi de points pour attirer l’attention sur la version pour laquelle le tutoriel serait prévu sans avoir à remettre à chaque section un bloc pour la rappeler, et fournit la possibilité aux personnes qui arriveraient depuis un autre tutoriel moins à jour de savoir quoi adapter pour pouvoir utiliser la dernière version. Détail que je trouve intéressant : ce cheminement peut aussi être effectué dans l’autre sens.
4. de présenter les nouveautés lors de montées de version, notamment ce qui remplace les éléments du point 2.

En ce qui me concerne, je me méfie de ce que ce tutoriel Symfony devienne une formation développeur web générale, au même titre que le tutoriel WampServer a failli devenir un tutoriel à propos des serveurs web sur les trois types d’OS et Composer dans le lot.

Pour ce qui est de Webpack Encore, comme c’est (pour autant que je sache) un outil "purement" Symfony et que ça remplace assetic, je pense que je vais en parler, mais dans un second temps (ça entrerait dans le point 4 de la liste — je vois néanmoins déjà venir les soucis d’installations de yarn sur les différents environnements…).

Composer et Docker ne sont en revanche pas des outils propres à Symfony pour moi : Composer est pour PHP en général et sera probablement traité dans le tutoriel y relatif. Certes, il faudra mentionner les raccourcis introduits avec Flex, mais c’est justement parce qu’il y a des choix propres à Symfony derrière.

Quant à Docker, c’est un des environnements possibles pour Symfony sans lui être exclusif. On choisit où on construit sa villa, le fait que certains terrains sont plus pratiques que d’autres selon l’entreprise mandatée est un critère qui leur est propre.

Par rapport à un dépôt git, j’y réfléchis. C’est sûr que c’est pratique pour ceux qui souhaitent jouer avec un code tout prêt, et en soi ce n’est pas trop de travail vu que je me force à faire le code en même temps que je rédige.

Je comprends bien la plus-value que tu souhaites voir être amenée, mais, aussi restrictif que cela puisse paraître, j’aimerais faire un tutoriel Symfony, et ne pas verser dans « on peut utiliser du "pas Symfony" avec Symfony, alors montrons comment faire ».

Pour terminer, à propos du fil rouge, il y a un point que j’avais pas pris en compte et je ne sais pas trop s’il faut s’en formaliser : dans la demande que j’ai faite à winzou, j’avais précisé que je souhaitais conserver le fil rouge du blog.

J’aimerais quand même te dire sincèrement merci, parce que tes questions me permettent au moins (désolé de la formulation initiale, c’était pas adéquat) de formaliser ce que je souhaite faire. 

Enorme travail. Bon courage ! Et top !

Est-ce que tu veux un coup de main pour un chapitre ?

@Nek : honnêtement, si tu connais justement Webpack Encore, c’est quelque chose que je n’ai jamais manipulé 

On a cependant le temps, je pensais que je pourrais pousser quelques mises à jour avec la sortie de ZestWriter 2, mais malheureusement, l’application ne fonctionne pas chez moi. Qui plus est, comme annoncé dans mon précédent message, je n’en fais pas la priorité pour une première re-publication.

Et d’autre part, comme annoncé dans le premier message, si quelqu’un est d’accord de faire une passe de relecture avant que ce soit envoyé en validation, c’est très volontiers.

Noté je vais essayer de rédiger quelque chose, on en parle en MP quand j’ai quelque chose de tangible.

Sinon pour les feedbacks j’ai regardé pour twig il me semble que certains trucs ne sont plus d’actu sur l’usage dans les contrôleurs. J’ai noté aussi qu’on n’est plus obligé de préfixer par <?php pour avoir la coloration syntaxique. Et enfin une coloration syntaxique twig serait appréciable sur les bouts de code !

La coloration syntaxique a sauté ? Je n’avais pas fait attention, je n’ai probablement pas changé en pensant que hl.js reconnaîtrait html+django et que django tout seul ne colorerait que le Twig et pas le HTML autour. Le pire, c’est que j’ai peut-être changé et que c’est pas encore en ligne… Mais je vais vérifier, c’est simple à modifier.

« certains trucs », mais encore ? 

Pour être repassé vite fait dessus je crois qu’en fait j’ai fumé. xD J’vais faire une repasse complète comme ça je vais pouvoir m’imprégner du style d’écriture pour faire quelque chose de cohérent pour webpack.

Pour ce qui est de la coloration tu peux mettre juste twig !

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

J’ai pris le temps de (re-)relire toute une partie du contenu il me semble ne pas avoir loupé grand chose jusqu’au chapitre sur les services poussés) et de corriger certains points, comme la coloration syntaxique de Twig.

Edit

Mmm, je n’avais pas fait attention, le sous-titre est ce que je croyais être une simple description… Ce ne sera évidemment pas ça pour la publication 

Hello Ymox

Donc dans la partie "Sécurité et gestion des utilisateurs", pour la création du bundle, c’est à partir de "php bin/console generate:bundle" que ça bloque avec Symfony 5 (lien). Penses-tu que je pourrai m’en sortir en étudiant cette page de la doc :

https://symfony.com/doc/current/bundles#creating-a-bundle

Ensuite, toujours concernant les soucis de compatibilité avec Symfony 5, plus bas dans le cours on voit qu’il faut utiliser le service security.context qui permet de récupérer les informations sur l’utilisateur courant. Or apparemment ce service a été déconseillé dans la 2.6 et divisé en deux nouveaux services : security.authorization_checker et security.token_storage. J’imagine que la suite du cours pourrais fonctionner avec security.token_storage non ?

Ce cours est toujours d’actualité ? Si oui je vais aller sérieusement le relire.

La partie utilisateur n’est pas encore à jour tout du moins dans la version beta, mais ayant des soucis d’utilisation de ZestWriter depuis la dernière version, je n’ai pour l’instant pas pu re-synchroniser mes modifications même en brouillon.

Il n’y a cependant pas besoin de créer un bundle à mon avis. Et par rapport à security.context, effectivement security.token_storage devrait faire l’affaire.

Ok sinon il y a ce tuto en anglais :

https://auth0.com/blog/creating-your-first-symfony-app-and-adding-authentication/ qui fonctionne avec Symfony 5.

Du coup tu vas tout envoyer d’un bloc? (vu que le tuto est déjà en ligne ça fait sens remarque)

Sinon pour ce qui est de l’authentication classique je ne sais pas s’il faut privilégier une approche comme le tuto que tu as linké @Xysmath87 ou une approche "à l’ancienne" en utilisant directement le form_login dispo dans Symfony.

Mon avis c’est qu’il vaut mieux partir sur le form_login car c’est plus simple et présenter quand même les authenticators avec un exemple d’authentication via api key simple. Mais c’est @Ymox qui choisi: c’est son cours !

J’aimerais bien envoyer ce que j’ai en local en une fois (ça fait beaucoup de fichiers modifiés, si je dois faire les modifications à la main, je vais non seulement en oublier, mais en plus ça fait autant de versions que de fichiers à modifier), ne serait-ce que pour mettre en beta. Après, au vu du nombre improbable des retours… 

Apparemment pour l’instant le plus gros des modifications que je voudrais apporter se trouve en local uniquement, mais je n’ai même pas de quoi regarder précisément ce qui a changé. Probablement que je ferai un repo git pour le tutoriel, c’est encore ce que je vois de plus pratique, le souci restant le problème de synchro "version locale" <-> ZdS.

Sinon, je pense partir sur une authentification simple par formulaire, c’est le cas le plus simple pour commencer à mon avis. Avoir si il faut à nouveau couvrir toutes les options dès le départ ou s’il est possible de conserver certains liens vers la documentation, voire au pire faire des appendices.

A part ça, je n’ai pas vraiment repris de temps de rédaction depuis le début de la pandémie. J’ai eu la chance de pouvoir continuer à travailler, et même de travailler plus que d’habitude… sans parler des à-côtés.

@Xysmath87 : comment avais-tu accès à cette version du tutoriel en beta sans avoir de compte, vu que celui-ci est tout neuf ? J’ai vérifié, seuls les membres y ont normalement accès…

Je présume qu’il a lu la version pas à jour en effet.

Avec un ancien compte que j’ai supprimé. Le compte que j’utilise actuellement, je l’ai créé hier :).

Sinon le Tuto que j’ai donné n’est pas à jour avec la version 5.3 de Symfony, car il utilise l’authentificateur Symfony Guard qui est déprécié depuis Symfony 5.3 en faveur d’un nouveau système basé sur l’authentification) : https://symfony.com/doc/current/security.html#guard-authenticators. Ce n’est pas forcément grave car apparemment on peut encore utiliser Guard mais il y a d’autres petits problèmes qui provoquent des erreurs et je n’ai pas les compétences pour les résoudre. Je vais chercher un autre tuto sur l’authentification et s’il fonctionne je donnerai le lien si ça peut aider.

Bonsoir Ymox, je vais passer aux parties IV 4/Les services, utilisation poussée et 5/Le gestionnaire d’évènements de Symfony. J’aimerais savoir si elles sont à jour avec Symfony 5 ou s’il vaut mieux voir d’autres ressources pour le moment ?

Je me souviens clairement avoir fait une grosse repasse sur celle-ci, la théorie devrait tenir un peu plus la route.

Par contre, j’apprécierais d’avoir des retours, notamment comme expliqué dans le message du début