À vous de jouer !
Présentation du Blog de Léa
Il s'agit ici de compléter l'application que vous avez manipulée pour le QCM de la partie 2 de ce cours (Initiation à Twig et Doctrine ORM). Vous allez compléter cette application pour lui ajouter une interface de gestion des articles avec les fonctionnalités suivantes :
Création et édition d'un article (avec sauvegarde en base de données) ;
Suppression d'un article ;
Visualisation de l'article dans l'interface de gestion.
La page d'accueil de l'interface de gestion sera fournie, ainsi que le code pour vous authentifier (n'hésitez pas à le parcourir pour apprendre).
Voici un exemple de livrable :
Consignes et livrables
Après avoir récupéré l'archive en suivant ce lien, puis l'avoir extraite sur votre machine de développement, lisez les instructions disponibles dans le fichier README pour mettre en place le projet.
Accédez au projet dans le navigateur, et en vous servant des captures d'écran fournies, déboguez et complétez l'application :pirate:.
Quelques conseils
Le projet est fourni avec une suite de tests que vous pouvez lancer à l'aide de la commande suivante :
./vendor/bin/simple-phpunitCette suite de tests montre des erreurs : c'est logique puisque l'application est incomplète ! Le but du projet est de faire en sorte que cette suite de tests passe au vert, c'est à dire que l'ensemble des fonctionnalités prévues soit disponibles.
Procédez par étape : d'abord, vérifiez que Doctrine est bien configuré, puis le code de vos contrôleurs, et enfin les vues en Twig.
Dans le projet d'exemple, les "trous" sont indiqués sous forme de commentaire avec des instructions supplémentaires pour vous aider.
Vérifiez votre travail
Propreté du code
Pour cette partie, il s'agit de voir si le code est très facilement compréhensible par un autre développeur. Un code lisible doit avoir un nommage clair pour chaque composant (classes, méthodes, attributs et variables) en utilisant un standard de nommage (camelCase).
Il est important de séparer chaque partie de l'application en différentes classes et méthodes.
Aussi, nous avons vu qu'il existe des standards propres au projet Symfony que l'on peut valider à l'aide du logiciel PHP-CS-Fixer.
Pour information, après installation de PHP CS Fixer, la commande à utiliser est la suivante :
php ./vendor/bin/php-cs-fixer fix --dry-run --stop-on-violation
Fonctionnalités
Évidemment, les fonctionnalités sont la partie la plus importante du projet. Il se peut que les tests ne fonctionnent pas, mais que l'application fonctionne partiellement. Il faut donc vérifier manuellement que l'affichage, la création, l'édition et la suppression d'un article fonctionnent.
Tests unitaires
Au départ, la suite de tests ne fonctionnera pas car il manquera les fonctionnalités demandées : ce projet peut être une bonne opportunité pour expérimenter l'approche TDD ;)
Bien qu'il n'ait pas été demandé d'écrire de tests supplémentaires, vérifiez que la suite de tests actuelle fonctionne toujours après développement des fonctionnalités demandées. Pour exécuter la suite de tests, vous pouvez utiliser la commande suivante :
./vendor/bin/simple-phpunit --stop-on-error
Plus spécifiquement les tests qui seront en échec au départ concernent la classe BlogController du dossier src/Controller/Admin !
Critères d'évaluation
Pour être sûr que vous avez tout fait correctement, vérifiez votre code selon les critères d'évaluation suivants :
Chaque action est identifiée par une méthode qui lui est propre.
Aucune méthode ne dépasse 20 lignes de code.
Le code respecte les standards de Symfony.
L'architecture du projet initial a été respectée.
La suite de tests fournie doit être lancée sans erreurs.
Les entités doivent être correctement configurées.
Les données de démonstration doivent pouvoir être rechargées sans erreurs.
Les vues sont faites en Twig et ne génèrent aucune erreur.
Les vues ressemblent aux captures d'écran fournies.
