{"language":"application/x-httpd-php","content":"<?php\n\nuse Illuminate\\Support\\Facades\\Route;\n\nuse App\\Http\\Controllers\\UsersController;\n\n/*\n|--------------------------------------------------------------------------\n| Web Routes\n|--------------------------------------------------------------------------\n|\n| Here is where you can register web routes for your application. These\n| routes are loaded by the RouteServiceProvider within a group which\n| contains the \"web\" middleware group. Now create something great!\n|\n*/\n\nRoute::get('/', function () {\n return view('welcome');\n});\n\nRoute::get('/dashboard', function () {\n return view('dashboard');\n})->middleware(['auth'])->name('dashboard');\n\nRoute::get('/users', [UsersController::class, 'index'])->middleware(['auth', 'admin'])->name('users');\n\nrequire __DIR__.'/auth.php';","filename":"web.php"}
Parfait, j'ai le même. Par contre, ne devrions-nous pas appliquer le middleware admin sur Dashboard ?Si, tu as tout à fait raison ! Je te laisse faire.
Continuons d'écrire nos routes pour la gestion des utilisateurs... Tout d'abord, listons les actions du CRUD :
- Lister les users
- Voir un utilisateur en particulier (voir le profil)
- Modifier un utilisateur (modifier le profil)
- Ajouter un utilisateur (s'inscrire)
- Supprimer un utilisateur
Parmi ces actions, seulement quelques-unes vont devoir être intégrées au panneau d'administration. Lesquelles ?
Lister les utilisateurs, supprimer un utilisateur, modifier un utilisateur ? On pourrait oui ! Cependant, pour gagner du temps, la modification d'un utilisateur va être la modification de profil : ce sera la même route aussi bien pour l'utilisateur que pour les administrateurs.
En résumé, nous avons donc besoin des routes suivantes (je précise les types de requête également) :
- GET : lister les utilisateurs
- DELETE : supprimer un utilisateur
Mais attends, je ne connais que les requêtes de type GET et POST moi ! Pas de soucis ! En réalité, il en existe beaucoup : GET, POST, PUT, PATCH, DELETE.
- GET : récupérer des informations
- POST : envoyer des informations
- PUT, PATCH : modifier des informations
- DELETE : supprimer des informations
Laravel nous simplifie la vie pour gérer tous les types de requêtes. Pour dire qu'une route est de type TYPE, il nous suffit d'écrire :
Route::TYPE('route', callback)...;
Et c'est aussi simple que ça.
Alors commençons !
{"language":"application/x-httpd-php","content":"<?php\n\nuse Illuminate\\Support\\Facades\\Route;\n\nuse App\\Http\\Controllers\\UsersController;\n\n/*\n|--------------------------------------------------------------------------\n| Web Routes\n|--------------------------------------------------------------------------\n|\n| Here is where you can register web routes for your application. These\n| routes are loaded by the RouteServiceProvider within a group which\n| contains the \"web\" middleware group. Now create something great!\n|\n*/\n\nRoute::get('/', function () {\n return view('welcome');\n});\n\nRoute::get('/dashboard', function () { return view('dashboard');} )->middleware(['auth'])->name('dashboard');\n\nRoute::get('/users', [UsersController::class, 'index'])->middleware(['auth', 'admin'])->name('users');\nRoute::delete('/users/{id}', [UsersController::class, 'destroy'])->middleware(['auth', 'admin'])->name('users.destroy');\n\nrequire __DIR__.'/auth.php';\n","filename":"web.php"}
C'est quoi le {id} que tu as mis dans la route ? En fait, c'est très pratique. Les "mots" que l'on met entre accolades dans une route correspondent aux données qui peuvent changer dans la route. Ce sont les paramètres de la route.
Sans réécriture d'URL (https://httpd.apache.org/docs/2.4/fr/rewrite/intro.html), notre URL pour supprimer un utilisateur aurait ressemblé à index.php?action=users.destroy&id=1. Comme tu le vois, les informations sont directement écrites dans l'URL et l'utilisateur curieux (ou mal intentionné) peut facilement les modifier. Et ce n'est pas très beau à lire... Maintenant, avec la réécriture d'URL, nous faisons une requête de type delete en utilisant l'URL suivante : users/1.
C'est nettement plus beau !
Il faut savoir que dans notre cas, à la place de {id}, on pourrait mettre tout et n'importe quoi.
Notre route va accepter toutes les requêtes qui ont la même forme, comme par exemple : users/1, users/1233, users/bonjour"...
Heureusement, Laravel nous permet de vérifier ces paramètres de route avec des regex (expressions régulières, les trucs qui ressemblent à ^[0-9]{2,}[aA-zZ]?$). Les regex vont, par exemple, te permettre de vérifier que l'id de l'utilisateur qui est donné ne contient que des chiffres. Mais ce cours étant une introduction, on en restera là !
Tu comprends ?
Je comprends merci !Bon, et bien je te laisse faire toutes les routes liées aux utilisateurs. Pour voir leur profil, le modifier etc... La correction est juste après.
Pour t'aider, n'oublie pas de te demander quels sont les middlewares à appliquer et si la route a des attributs ! N'oublie pas non plus que la route pour créer un utilisateur (l'inscription donc) est déjà gérée par le fichier auth.php
La correction :
{"language":"application/x-httpd-php","content":"<?php\n\nuse Illuminate\\Support\\Facades\\Route;\n\nuse App\\Http\\Controllers\\UsersController;\n\n/*\n|--------------------------------------------------------------------------\n| Web Routes\n|--------------------------------------------------------------------------\n|\n| Here is where you can register web routes for your application. These\n| routes are loaded by the RouteServiceProvider within a group which\n| contains the \"web\" middleware group. Now create something great!\n|\n*/\n\nRoute::get('/', function () {\n return view('welcome');\n});\n\nRoute::get('/dashboard', function () { return view('dashboard');} )->middleware(['auth'])->name('dashboard');\n\nRoute::get('/users', [UsersController::class, 'index'])->middleware(['auth', 'admin'])->name('users');\nRoute::get('/users/profile/{user}', [UsersController::class, 'show'])->name('users.show');\nRoute::get('/users/{user}', [UsersController::class, 'edit'])->middleware(['auth'])->name('users.edit');\nRoute::put('/users/{user}', [UsersController::class, 'update'])->middleware(['auth'])->name('users.update');\nRoute::delete('/users/{user}', [UsersController::class, 'destroy'])->middleware(['auth', 'admin'])->name('users.destroy');\n\n\nrequire __DIR__.'/auth.php';","filename":"web.php"}
J'avais fait presque pareil, mais pourquoi tu as mis tout le temps la même URL alors qu'on fait pas la même chose ? Par exemple, users/{user} pour edit, update... ? Je peux mettre la même URL pour plusieurs routes car le type de la route (get, put...) lui n'est pas le même ! Laravel redirigera donc vers la bonne méthode du contrôleur même si l'URL est la même ;). J'aurais pu changer, bien évidemment, mais en général c'est comme ça que nous faisons.
D'accord. Et pourquoi avoir changé users/{id} en users/{user} ? Ahah, c'est une question de simplicité d'utilisation par la suite. Laravel propose ce qu'on appelle de l'implicit binding. Pour t'expliquer rapidement, au lieu de passer dans nos routes l'ID de l'utilisateur, on va passer l'utilisateur entier. Et dans notre contrôleur, on n'aura pas besoin d'appeler une méthode d'un modèle qui récupèrerait l'utilisateur associé à l'ID passé en paramètre de la route. J'imagine que c'est encore un peu flou, mais j'en reparlerai au moment de la création des contrôleurs, tu verras tout te paraitra plus simple et compréhensible.
Vivement la réalisation des contrôleurs alors !On y est presque. En réalité, il ne nous reste plus que les routes liées aux posts et celles liées aux commentaires.
Réfléchissons... Que pouvons-nous faire avec les posts et les commentaires ? Absolument toutes les actions du CRUD :
- Voir un post
- Lister tous les posts
- Modifier un post (afficher le formulaire d'édition + traitement du formulaire)
- Création d'un post (afficher le formulaire de création + traitement du formulaire
- Suppression d'un post
Et encore une fois, Laravel nous simplifie la vie en nous mettant à disposition une autre méthode de la classe Route : resource.
Cette méthode va créer chacune des routes du CRUD... Voici les routes qui seront créées quand on utilise cette méthode sur les posts par exemple :
Mais comment tu fais pour afficher les routes ? J'utilise artisan ! La commande suivante va afficher toutes les routes de notre application.
{"language":"shell","content":"php artisan route:list","filename":""}
Bon, alors avant d'utiliser clairement cette méthode dans nos routes, créons déjà nos 2 contrôleurs. Vu qu'on va utiliser toutes les méthodes de CRUD, on peut préciser au framework de créer le contrôleur avec la déclaration de toutes les méthodes qui correspondent à celles appelées par Route::resource(). On peut même préciser le modèle lié au contrôleur pour qu'il préremplisse les paramètres des méthodes !
EDIT : Il y a une petite erreur dans l'image ci-dessus après relecture. Il faut lire à la seconde commande --resource --model=Post et non pas --resource --model=Comment
C'est super pratique ! Oui, tu peux aller jeter un oeil aux 2 contrôleurs nouvellement créés pour avoir une idée de ce qui a été généré.
Et maintenant l'utilisation des ressources :
{"language":"application/x-httpd-php","content":"<?php\n\nuse Illuminate\\Support\\Facades\\Route;\n\nuse App\\Http\\Controllers\\{CommentsController, PostsController, UsersController};\n\n/*\n|--------------------------------------------------------------------------\n| Web Routes\n|--------------------------------------------------------------------------\n|\n| Here is where you can register web routes for your application. These\n| routes are loaded by the RouteServiceProvider within a group which\n| contains the \"web\" middleware group. Now create something great!\n|\n*/\n\nRoute::get('/', function () {\n return view('welcome');\n});\n\nRoute::get('/dashboard', function () { return view('dashboard');} )->middleware(['auth'])->name('dashboard');\n\nRoute::get('/users', [UsersController::class, 'index'])->middleware(['auth', 'admin'])->name('users');\nRoute::get('/users/profile/{user}', [UsersController::class, 'show'])->name('users.show');\nRoute::get('/users/{user}', [UsersController::class, 'edit'])->middleware(['auth'])->name('users.edit');\nRoute::put('/users/{user}', [UsersController::class, 'update'])->middleware(['auth'])->name('users.update');\nRoute::delete('/users/{user}', [UsersController::class, 'destroy'])->middleware(['auth', 'admin'])->name('users.destroy');\n\nRoute::resource('posts', PostsController::class);\n\nRoute::resource('comments', CommentsController::class);\n\n\nrequire __DIR__.'/auth.php';","filename":"web.php"}
C'est super ! Par contre, dans la gestion des commentaires, il faut parfois être administrateur ? Par exemple pour modifier un commentaire ou en supprimer un ? Ou bien être connecté pour créer un post par exemple. Comment fait-on pour attribuer des middlewares ? Hé bien... On ne peut pas. On peut attribuer un middleware sur toutes les routes d'une ressource, mais pas sur quelques routes d'une ressource. Mais ne t'inquiète pas... Il y a toujours une solution : on peut assigner des middlewares à une route directement dans le constructeur des contrôleurs. Pratique non ?
Allez, on a presque fini cette partie. Il ne nous reste plus que 1 route à créer : le signalement d'un commentaire.
{"language":"application/x-httpd-php","content":"<?php\n\n// Toutes les routes créées précédemment\nRoute::get('comments/{comment}/report', [CommentsController::class, 'report'])->name('comments.report');\n\nrequire __DIR__.'/auth.php';","filename":"web.php"}
Et voilà, on a fini. Félicitations ! Dans la partie suivante on va commencer à toucher à nos contrôleurs en gérant les utilisateurs dans un premier temps.
D'ailleurs, on aurait pu utiliser une ressource pour nos utilisateurs aussi non ? Pas exactement... Comme on l'a vu, il y a déjà des routes créées par auth.php pour l'inscription par exemple, qui crée un utilisateur. Utiliser une ressource aurait recréé une route pour faire ça, pas très pratique. Après, il est vrai qu'on peut "exclure" des routes d'une ressource, et donc dire : je veux une ressource sans la route qui correspond à la création d'un utilisateur. Mais bon, au moins comme ça tu as vu toutes les façons de faire !
Bilan de ce qu'on a vu dans cette partie :
J'ai terminé cette partie - Les paramètres de route
- L'implicit binding
- La création de contrôleurs avec les méthodes de CRUD déjà déclarées
- Les routes de type ressource