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