ResourceBundle hors de Sylius ?

Liste des blog post dans le HackSylius
Résultat final avec SyliusResourceBundle

Continuons notre folle aventure dans le démantèlement des bundles utilisé pas Sylius, mais dans un projet Symfony indépendant.

Mais avant de continuer où en sommes-nous ? La première première partie de la première étape consistait à mettre en place un nouveau projet Symfony 5.3 et un projet Sylius 1.10. J’y avais également installé le ThemeBundle.
Dans la deuxième partie de la première étape, j’ai installé et utilisé SyliusUiBundle pour obtenir une page ayant la même apparence que l’administration de Sylius.
Dans la deuxième étape – qui n’a pas été de tout repos, j’ai installé et utiliser GridBundle pour afficher la première liste de données du projet.

Qu’allons-nous faire dans cette troisième étape ? La réponse est dans le titre, nous allons installer et utiliser le SyliusResourceBundle pour gérer nos entités Doctrine.

Ce bundle est là pour nous aider à configurer et mettre en place une gestion simple de nos entités.

Comme pour les précédentes étapes tous c’est déroulé sur Twitter. N’hésitez pas à me suivre.

Installation de ResourceBundle

L’installation d’une dépendance dans un projet Symfony ne doit plus avoir de secret pour vous après avoir lu les 3 articles précédents. Détrompez-vous il y a toujours une surprise qui attends.

La commande pour installer le bundle est la suivante : composer require sylius/resource-bundle

Exécution de la commande d’installation du ResourceBundle.

L’installation commence et là c’est le premier problème de l’étape. Je pensai naïvement que les erreur arriveraient plus tard.

Erreur de doublons dans les déclarations des classes de PagerFanta.

Le problème viens d’un doublons dans l’installation de PagerFanta. Lors de la 3eme étape, j’ai du installé la version 2.x du bundle PagerFanta et des librairies liées. Sauf que ResourceBundle requière visiblement une autre version plus spécifique qui n’est pas en conflit avec la version déjà installée.

Pour corriger le problème, je vais désinstaller PagerFanta. La commande pour supprimer les dépendances est : composer remove pagerfanta/pagerfanta pagerfanta/twig babdev/pagerfanta-bundle

Suppression de PagerFanta du projet.

Composer indique que la librairie pagerfanta/pagerfanta n’est pas désinstallé comme demandé. C’est normal car elles est nécessaire pour le ResouseBundle. Il indique même la commande à exécuter pour en connaitre la raison.

En l’exécutant il indique que la librairie est requise par babdev/pagerfanta-bundle. Il faut donc relancer la commande avec ce nouveau nom pour remonter la chaîne des dépendances.

Voici la raison finale

Le problème de dépendance est maintenant résolu, je peux passer à l’étape suivante.

Configurer BlogPost en tant que ressource

Pour transformer une entité Doctrine en Resource Sylius , il faut faire deux choses.

La première, implémenté l’interface Sylius\Component\Resource\Model\ResourceInterface sur la classe PHP de l’entité Doctrine.

L’entité BlogPost implémentant l’interface ResourceInterface de Sylius.

Cette interface nécessite l’implémentation de la fonction getId().

La seconde chose est de déclarer la ressource dans le configuration du ResourceBundle. Le fichier config/packages/sylius_resource.yaml a été ajouté lors de l’installation.

Juste avant de configurer la ressource, il est nécessaire de déclarer le driver à utiliser pour la ressource. Dans le cadre de ce projet, c’est le pilote Doctrine ORM qu’il faut sélectionner.

Contenu du fichier « config/packages/sylius_resource.yaml »

Sous la clé « resource », j’ai ajouté une clé. C’est le nom de la ressource dans le Bundle. Il sera utile plus tard. Il faut bien le choisir.

Grâce à la documentation, j’ai ajouté la seule clé obligatoire, c’est à dire « model » qui est sous « classes ». Les autres clés possible sont automatiquement configuré par le bundle avec des valeurs par défaut. Je peux passer à l’étape suivante.

Configurer le routing

Cette étape est importante. C’est elle qui va rendre notre ressource disponible via le navigateur. Comme il s’agit de la configuration du routage, le fichier à modifier est config/routes.yaml.

La documentation du GridBundle donne la syntaxe pour configurer les routes de la ressource.

Je vais rester minimaliste. Voici à quoi elle ressemble:

Le début du fichier de routage.

La clé « resource » contient la configuration. Ici « alias » à pour valeur « app.blog_post » qui correspond au nom de la ressource déclarée plus haut.

Avant d’aller dans le navigateur pour accéder aux pages, je vais vérifier que Symfony à bien pris en compte ma configuration en exécutant la commande suivante bin/console debug:router

Résultat de la commande « bin/console debug:router »

Le résultat montre un écart entre la route « app_blog_post_bulk_delete » et les autres. Cela est dû à la configuration des routes réalisé lors de l’étape précédente. Cette configuration surcharge celle réalisé par le ResourceBundle mais n’est plus utile, je vais la commenter dans un premier temps.

Second résultat de la commande « bin/console debug:router »

Les routes sont maintenant cohérente.

Il manque un élément à la configuration, la clé « grid » doit être ajouté. La valeur cette clé correspond au nom de la grille configuré pour cette ressource. Je n’ai pas besoin de configuré une grille car elle a été configuré lors de l’utilisation du Gridbundle lors de la précédente étape. Le met la valeur « app_blog_post« 

Configuration du routing avant les tests.

Maintenant, je pense être prêt, je démarre le serveur web grâce à l’exécutable Symfony cli (commande : symfony serve -d).

J’ouvre mon navigateur pour aller sur la page « /home » et là les choses tournent mal.

Oups, rien ne va plus

La page home s’affiche correctement, ouf. Je clique sur le lien « Blog post »…

Page d’accueil

Et j’ai cette erreur qui s’affiche.

Le problème vient du repository Doctrine qui n’est pas tel qu’attendu par le ResourceBundle.

La raison de cette erreur n’est pas lié à une documentation mal rédigée mais au projet. Avant l’utilisation du ResourceBundle, j’ai déclaré un Repository pour l’entité BlogPost.

Encore une fois j’ai deux solution:

  • Soit supprimer le repository que j’ai dans le code.
  • Soit modifier le repository pour qu’il soit conforme.

J’ai choisi la seconde option et je modifie la classe « App\Repository\BlogPostRepository » pour qu’elle étende « Sylius\Bundle\ResourceBundle\Doctrine\ORM\EntityRepository« 

Le repository correctement écrit pour sont utilisation.

J’en avais un peu parlé lors de la configuration de la ressource dans le bundle, il est possible de déclarer d’autre classe pour une ressource. C’est ce que j’ai fais pour le repository.

Configuration de la ressource avec le repository.

J’ai eu une autre erreur lié cette fois au template Twig. Le bundle ne sais pas où chercher les templates. Comme ils ont été réalisé lors de la mise en place du GridBundle, je dois uniquement configurer la clé « template » dans la configuration du routage.

Configuration finale du routing.

Pourquoi cette configuration est-elle dans le routing ? La raison est simple, elle sera automatiquement disponible dans l’objet Request après sont passage dans le routeur de Symfony. Elle sera ainsi aisée à récupérer par le ResourceController.

la clé « _sylius » des attributs de la requête contient les valeurs définie dans le routing.

Mais non, c’est corrigé

Après cette petite précision, je peux maintenant tenter à nouveau le chargement de la page.

Le résultat est le même qu’au début de cette étape.

Résultat final

Conclusion du projet

Que puis-je tirer comme leçon de tout ce projet ? La première est qu’il est important de bien connaitre le fonctionnement des outils utilisés dans un projet.

La deuxième est que le code est plus précis que la documentation. J’ai du aller chercher les templates manquants dans le projet Sylius pour arriver à mes fin.

La troisième est qu’il ne faut pas se décourager. L’apprentissage est parfois long mais ça en vaux la penne.

Ce projet va en rester dans cet état malgré la multitude d’idées que j’ai eue en voyant le potentiel de ces bundles. Pourquoi ? Vous m’avez recommandé un projet qui fait la même chose, mais plus avancé. Ce sera le sujet d’un nouveau thread Twitter. Alors, suivez-moi (@jbnahan69) pour ne rien rater, car je le découvrirais en direct avec vous.

Si vous avez des commentaires, remarques, questions ou suggestions, je suis disponible pour en discuter par le moyen qui vous convient.

Dépôt du code source du projet sur GitHub.