Vraiment sympa pour l'apprentissage des formulaires ! Dans le cas d'un crud, il est possible de gagner un peu de temps en faisant "php bin/console make:crud", qui va créer directement les actions du crud dans le controller associer et ajouter les templates twig également ainsi que votre EntityType ! Il restera donc plus qu'à ajouter votre logique !
Dans une autre formation, j'avais appris qu'on pouvait mettre en place des écouteurs d'évènements dans les entitées pour un pre-submit. donc.. J'ai jamais chercher plus loin que ca ! ^^ Sauf que ca me parait beaucoup plus logique que ce genre d'évènement se place dans un formulaire ;) merci a toi pour t'es vidéos =)
Moi pour supprimer je fais une route avec /id/delete directement. Je ne comprends pas pourquoi tu as gardé le même nom du path? Et pour les dates des fois je les set depuis le constructeur de l'objet entity est ce que c'est une bonne pratique ? Merci
Salut comme il le dit dans la vidéo si tu crées une route directement comment tu sais si on fait cliquer sur un lien à un utilisateur pour delete sa recette. Moi j'utilisai une CSRF Protection je ne sais pas si c'est équivalent à cette méthode. Pour les dates oui, tu peux faire comme tu dis et faire des set sur l'édit et le create mais comme ce sont des actions qui se font à chaque changement dans un formulaire ça peu être plus propre de les gérer avec les événements dans le Type comme indiquer.
@@Aclantis.13 ah oui merci pr l'explication mais je pensais que symfony gère le csrf si je me trompe pas. En tout cas ça fait du bien de revoir symfony avec des nouvelles astuces de grafikart.
Tu peux faire une route différente (mais par contre je ne la met jamais en GET pour la sécurité) Pour le constructeur c'est faisable mais tu te retrouvera quand même à ajouter une logique pour le updatedAt. Tu peux aussi ajouter les dates via les évènements de doctrine.
personnellement pour le controleur remove lorsque je clique sur le bouton supprimer, même après avoir apporter les modifications dans le fichier framework.ymal le fichier je suis quand même rediriger vers la page edition de la recette que j'ai choisi, auriez-vous un tips ou une idée de ce que je dois aller vérifier ?
Bonjour, ça arrive peut être un petit peu tard mais pour vérifier quelle route correspondent à quel chemin : " php bin/console debug:router " La partie Name renverra la méthode et la partie Path l'url correspondante. Bon courage.
D'abord, merci pour la formation ! J'ai l'impression d'avoir tout bien fait comme toi concernant la création du premier formulaire, seulement mon bouton "Save" résulte dans la création d'une requête AJAX plutôt qu'une soumission classique. Alors, ça n'est pas obligatoirement problématique, mais j'aimerais comprendre comment j'obtiens ce résultat différent ? Saurais-tu m'aider ? Merci beaucoup !
Merci beaucoup pour la qualité des explications que tu nous fournis ! C'est vraiment top ! Dans cette vidéo tu expliques comment gérer le slug et les champs createdAt et updatedAt de manière semi-automatique. Que penses-tu de DoctrineExtensions qui fournit quelques extensions vraiment pas mal comme Timestampable et Sluggable à mettre au niveau de l'entité. Ca me parait plus simple mais c'était peut-être pas l'objet de ta vidéo ? Je suis quand même curieux d'avoir ton avis sur ces extensions ! Merci à toi :)
Hello, excellente formation :-) De mon côté, je reçois l'erreur "Form data cannot be changed during "form.post_submit", you should use "form.pre_submit" or "form.submit" instead." lors de l'exec de la fonction attachTimestamps(). Je ne l'ai pas si j'utilise FormEvents::SUBMIT, mais est-ce aussi bien ?
Si tu as copié la fonction autoSlug, il y a des chances pour que tu n'es pas enlevé la ligne "$event->getData($data)" qui ne sert à rien dans le cas de la fonction attachTimestamps()
Je suis tombé sur cette erreur à un moment donné. Controller "App\Controller\RecipeController::create" requires the "$recipe" argument that could not be resolved. Cannot autowire argument $recipe of "App\Controller\RecipeController::create()": it needs an instance of "App\Entity\Recipe" but this type has been excluded in "config/services.yaml". Solution : - Soit dans config/services.yaml on retire `-'../src/Entity'` : App\: resource: '../src/' exclude: - '../src/Entity/' - Soit dans le controller RecipeController::create on retire `Recipe $recipe` des dépendances injectées en argument de la méthode. J'ai choisi la seconde solution mais j'aurais besoin de comprendre pourquoi cette erreur est survenu (Si quelque à l’explication, je lui remercie d'avance).
Super ta série sur Symfony 7. Je voulais savoir si on pouvait utiliser Symfony que pour une application back-end ? (API) Et si il y a moyen d'avoir juste les "composants" utile à la création d'une API, car par exemple avoir TWIG ou les formulaires ça me sera pas utile pour une API.
pour les createdAt j'ai toujours pris l'habitude de mettre la valeur par defaut en new dateTime dans l'entité et virer le setter, et pour les updatedAt au setter de forcer un new dateTime dans l'entité (en gros, set coté entité plutot que coté controller !). j'aimerai bien avoir ton avis sur cette pratique :-D Sinon merci pour la tuto,comme d'hab elle est au top. au plaisir de te revoir sur mtp ;-)
Merci beaucoup pour cette qualité de vidéo Concernant les écouteurs d'évènement dans la classe de formulaire, j'aimerais avoir ton avis sur un fait. Perso, que de passer par l'objet Event, je suis pour l'utilisation des objets PreSubmitEvent et PostSubmitEvent pour les méthodes de Callback des évènement FormEvents::PRE_SUBMIT et FormEvents::POST_SUBMIT. C'est un peu la même chose (me diras-tu) car de toute façon les classes PreSubmitEvent et PostSubmitEvent héritent toutes de l'objet Event. Cependant, l'utilisation de event#setData() est interdit dans l'évènement FormEvents::POST_SUBMIT, elle doit lever une BadMethodCallException. Donc, faisant le choix de ne pas implémenter le bon objet peut produire des comportements inattendus. Qu'en penses-tu ?
@@grafikart non pas du tout. J'ai cru un instant que tu utilisais l'objet Event générique pour la gestion des évènements pre_submit et post_submit. Je viens de regarder la vidéo de nous et c'est correct. Désolé si je t'ai embêté
Merci pour la vidéo ! je ne connaissais pas cette technique pour prepersist ! Cependant, si on se retrouve avec plusieurs entités, on va devoir le faire a chaque formulaire. ( Personnellement je préfère faire une classe et de l'etendre sur chaque entité concernée.
ICI PAR EXEMPLE J'AI UNE REMARQUE OU JE PEUX DIRE UNE REPROCHE SI VOUS LE VOULIEZ BIEN: LE FAIT D'AVOIR DIRECTEMENT COMMENCER A CREER UN FORMULAIRE de modification AU DETRIMENT D'UN FORMULAIRE DE CREATION D'ARTICLE , NEST PAS FORCEMENT LA BONNE METHODE POUR DEBUTER A ASSIMILER LA NOTION SUR LES FORMULAIRES
Salut, merci 🎉🎉, mais dommage que tu ne donnes pas le code source pour chaque épisode, un lien github par exemple, comme ça on est pas obligé de suivre depuis le début
Justement avec sa façon de présenter, tu peux adapter son explication à n'importe quel projet. Le but, je pense, c'est qu'on puisse venir sur un sujet pour de façon indépendante et que chaque personne puisse créer sa propre idée, ce qui très important quand on veut apprendre.
Les sources sont réservées aux membres premiums (payant) et sont disponible sur le site (en dessous de la vidéo). C'est pour cela qu'elles ne sont pas sur github.
@bolovy6093 Après c'est un peux le but. Ça sert à quoi qu'il s'embête à faire des formation si c'est pour au final télécharger bettement le truc sans essayer d'apprendre et de comprendre en pratiquant
Vraiment sympa pour l'apprentissage des formulaires ! Dans le cas d'un crud, il est possible de gagner un peu de temps en faisant "php bin/console make:crud", qui va créer directement les actions du crud dans le controller associer et ajouter les templates twig également ainsi que votre EntityType ! Il restera donc plus qu'à ajouter votre logique !
Dans une autre formation, j'avais appris qu'on pouvait mettre en place des écouteurs d'évènements dans les entitées pour un pre-submit. donc.. J'ai jamais chercher plus loin que ca ! ^^ Sauf que ca me parait beaucoup plus logique que ce genre d'évènement se place dans un formulaire ;)
merci a toi pour t'es vidéos =)
Moi pour supprimer je fais une route avec /id/delete directement.
Je ne comprends pas pourquoi tu as gardé le même nom du path?
Et pour les dates des fois je les set depuis le constructeur de l'objet entity est ce que c'est une bonne pratique ?
Merci
Salut comme il le dit dans la vidéo si tu crées une route directement comment tu sais si on fait cliquer sur un lien à un utilisateur pour delete sa recette. Moi j'utilisai une CSRF Protection je ne sais pas si c'est équivalent à cette méthode.
Pour les dates oui, tu peux faire comme tu dis et faire des set sur l'édit et le create mais comme ce sont des actions qui se font à chaque changement dans un formulaire ça peu être plus propre de les gérer avec les événements dans le Type comme indiquer.
@@Aclantis.13 ah oui merci pr l'explication mais je pensais que symfony gère le csrf si je me trompe pas.
En tout cas ça fait du bien de revoir symfony avec des nouvelles astuces de grafikart.
Tu peux faire une route différente (mais par contre je ne la met jamais en GET pour la sécurité)
Pour le constructeur c'est faisable mais tu te retrouvera quand même à ajouter une logique pour le updatedAt.
Tu peux aussi ajouter les dates via les évènements de doctrine.
personnellement pour le controleur remove lorsque je clique sur le bouton supprimer, même après avoir apporter les modifications dans le fichier framework.ymal le fichier je suis quand même rediriger vers la page edition de la recette que j'ai choisi, auriez-vous un tips ou une idée de ce que je dois aller vérifier ?
Bonjour, ça arrive peut être un petit peu tard mais pour vérifier quelle route correspondent à quel chemin : " php bin/console debug:router "
La partie Name renverra la méthode et la partie Path l'url correspondante. Bon courage.
D'abord, merci pour la formation !
J'ai l'impression d'avoir tout bien fait comme toi concernant la création du premier formulaire, seulement mon bouton "Save" résulte dans la création d'une requête AJAX plutôt qu'une soumission classique. Alors, ça n'est pas obligatoirement problématique, mais j'aimerais comprendre comment j'obtiens ce résultat différent ?
Saurais-tu m'aider ?
Merci beaucoup !
Merci beaucoup pour la qualité des explications que tu nous fournis ! C'est vraiment top !
Dans cette vidéo tu expliques comment gérer le slug et les champs createdAt et updatedAt de manière semi-automatique.
Que penses-tu de DoctrineExtensions qui fournit quelques extensions vraiment pas mal comme Timestampable et Sluggable à mettre au niveau de l'entité. Ca me parait plus simple mais c'était peut-être pas l'objet de ta vidéo ? Je suis quand même curieux d'avoir ton avis sur ces extensions ! Merci à toi :)
Hello, excellente formation :-) De mon côté, je reçois l'erreur "Form data cannot be changed during "form.post_submit", you should use "form.pre_submit" or "form.submit" instead." lors de l'exec de la fonction attachTimestamps(). Je ne l'ai pas si j'utilise FormEvents::SUBMIT, mais est-ce aussi bien ?
j'ai la même chose ! une idée du problème ?!
Si tu as copié la fonction autoSlug, il y a des chances pour que tu n'es pas enlevé la ligne "$event->getData($data)" qui ne sert à rien dans le cas de la fonction attachTimestamps()
vraiment mille fois merci grace a toi je commence a comprendre
Hello, tu peut utiliser les paramètres nommé pour les options pour éviter d’avoir à typé en text field à chaque fois 👌
Effectivement, pas toujours le réflexe de les utiliser ^^
Je suis tombé sur cette erreur à un moment donné.
Controller "App\Controller\RecipeController::create" requires the "$recipe" argument that could not be resolved. Cannot autowire argument $recipe of "App\Controller\RecipeController::create()": it needs an instance of "App\Entity\Recipe" but this type has been excluded in "config/services.yaml".
Solution :
- Soit dans config/services.yaml on retire `-'../src/Entity'` :
App\:
resource: '../src/'
exclude:
- '../src/Entity/'
- Soit dans le controller RecipeController::create on retire `Recipe $recipe` des dépendances injectées en argument de la méthode.
J'ai choisi la seconde solution mais j'aurais besoin de comprendre pourquoi cette erreur est survenu (Si quelque à l’explication, je lui remercie d'avance).
Pour sécuriser le lien. de suppression c'est plus simple de mettre un token CSRF, ça sert à ça ^^
Super ta série sur Symfony 7.
Je voulais savoir si on pouvait utiliser Symfony que pour une application back-end ? (API)
Et si il y a moyen d'avoir juste les "composants" utile à la création d'une API, car par exemple avoir TWIG ou les formulaires ça me sera pas utile pour une API.
Oui à l'étape d'installation il suffit de ne pas faire "composer require webapp", et de n'installer à la place que les composants dont tu as besoin.
pour les createdAt j'ai toujours pris l'habitude de mettre la valeur par defaut en new dateTime dans l'entité et virer le setter, et pour les updatedAt au setter de forcer un new dateTime dans l'entité (en gros, set coté entité plutot que coté controller !). j'aimerai bien avoir ton avis sur cette pratique :-D
Sinon merci pour la tuto,comme d'hab elle est au top. au plaisir de te revoir sur mtp ;-)
Merci beaucoup pour cette qualité de vidéo
Concernant les écouteurs d'évènement dans la classe de formulaire, j'aimerais avoir ton avis sur un fait.
Perso, que de passer par l'objet Event, je suis pour l'utilisation des objets PreSubmitEvent et PostSubmitEvent pour les méthodes de Callback des évènement FormEvents::PRE_SUBMIT et FormEvents::POST_SUBMIT.
C'est un peu la même chose (me diras-tu) car de toute façon les classes PreSubmitEvent et PostSubmitEvent héritent toutes de l'objet Event. Cependant, l'utilisation de event#setData() est interdit dans l'évènement FormEvents::POST_SUBMIT, elle doit lever une BadMethodCallException.
Donc, faisant le choix de ne pas implémenter le bon objet peut produire des comportements inattendus.
Qu'en penses-tu ?
Mieux vaut avoir l'objet le plus précis possible. J'ai fait une erreur dans la vidéo ?
@@grafikart non pas du tout. J'ai cru un instant que tu utilisais l'objet Event générique pour la gestion des évènements pre_submit et post_submit.
Je viens de regarder la vidéo de nous et c'est correct. Désolé si je t'ai embêté
Merci pour la vidéo ! je ne connaissais pas cette technique pour prepersist ! Cependant, si on se retrouve avec plusieurs entités, on va devoir le faire a chaque formulaire. ( Personnellement je préfère faire une classe et de l'etendre sur chaque entité concernée.
Dans un prochain chapitre (TP Category) on séparera ce code pour le rendre réutilisable.
ICI PAR EXEMPLE J'AI UNE REMARQUE OU JE PEUX DIRE UNE REPROCHE SI VOUS LE VOULIEZ BIEN: LE FAIT D'AVOIR DIRECTEMENT COMMENCER A CREER UN FORMULAIRE de modification AU DETRIMENT D'UN FORMULAIRE DE CREATION D'ARTICLE , NEST PAS FORCEMENT LA BONNE METHODE POUR DEBUTER A ASSIMILER LA NOTION SUR LES FORMULAIRES
trop bien
Salut, merci 🎉🎉, mais dommage que tu ne donnes pas le code source pour chaque épisode, un lien github par exemple, comme ça on est pas obligé de suivre depuis le début
Justement avec sa façon de présenter, tu peux adapter son explication à n'importe quel projet. Le but, je pense, c'est qu'on puisse venir sur un sujet pour de façon indépendante et que chaque personne puisse créer sa propre idée, ce qui très important quand on veut apprendre.
Les sources sont réservées aux membres premiums (payant) et sont disponible sur le site (en dessous de la vidéo). C'est pour cela qu'elles ne sont pas sur github.
@@grafikart dommage, ca veut dire qu’on doit coder avec toi pour etre a jour pour next episode
@bolovy6093 Après c'est un peux le but. Ça sert à quoi qu'il s'embête à faire des formation si c'est pour au final télécharger bettement le truc sans essayer d'apprendre et de comprendre en pratiquant
@@bolovy6093 ou prendre un compte premium, cela permet de continuer a produire les contenus