Laravel

L’authentification constitue une tâche fréquente. En effet, il y a souvent des parties d’un site qui ne doivent être accessibles qu’à certains utilisateurs, ne serait-ce que l’administration. La solution proposée par Laravel est d’une grande simplicité parce que tout est déjà préparé comme nous allons le voir dans ce chapitre. Au fil de l’évolution de Laravel ce domaine a connu plusieurs fois des changements. Ainsi avec Laravel 6 est apparue une nouveauté. Précédemment il y avait la commande php artisan make:auth pour générer les vues. Cette commande a disparu au profit d’un package à installer (laravel/ui). Mais les changements ont continué parce que désormais on nous conseille d’utiliser un starter…

Laravel permet de bâtir facilement des API à partir de ressource Eloquent. Voyons cela dans cet article. Les API REST Généralités REST (Representational State Transfer) est un style architectural pour la conception de API (Application Programming Interfaces) basé sur des concepts et des constraints bien définis. Dans le contexte de Laravel, une API REST se caractérise par les points suivants: Organisée autour de ressources : les API REST sont structurées autour de ressources, qui peuvent être des entités de données telles que des utilisateurs, des articles, des commandes, etc. Ces ressources sont accessibles via des URL uniques et bien définies. Sans persistance (sans session) : dans une API REST, chaque…

Lors des deux précédents chapitres on a vu les principales relations que nous offre Eloquent : hasMany et belongsToMany. Je ne vous ai pas parlé de la relation hasOne parce que c’est juste du hasMany limité à un seul enregistrement et est peu utilisé. Dans tous les cas qu’on a vus on considère 2 tables en relation, même lorsqu’une table pivot sert de lien entre les deux. Dans le présent chapitre on va envisager le cas où une table peut être en relation avec plusieurs autres tables, ce qui se nomme du polymorphisme. Un peu de théorie La relation 1:1 ou 1:n On a vu cette relation, en voici une…

Dans le précédent chapitre nous avons vu la relation de type 1:n, la plus simple et la plus répandue. Nous allons maintenant étudier la relation de type n:n, plus délicate à comprendre et à mettre en œuvre. Nous allons voir qu’Eloquent permet de simplifier la gestion de ce type de relation. On va continuer l’application de gestion de films, toujours avec des catégories, mais maintenant on va considérer qu’un film peut appartenir à plusieurs catégories, ce qui change pas mal de choses… Les données La relation n:n Imaginez une relation entre deux tables A et B qui permet de dire : je peux avoir une ligne de la table A…

Pour le moment nous n’avons manipulé qu’une table avec Eloquent. Dans le présent chapitre nous allons utiliser deux tables et les mettre en relation. La relation la plus répandue et la plus simple entre deux tables est celle qui fait correspondre un enregistrement d’une table à plusieurs enregistrements de l’autre table, on parle de relation de un à plusieurs ou encore de relation de type 1:n. Nous allons poursuivre notre gestion de films. Comme nous en avons beaucoup nous éprouvons la nécessité de les classer en catégories : comédie, fantastique, drame, thriller… On va partir du projet dans l’état où on l’a laissé dans le précédent article. Les migrations La…

Dans cet article nous allons terminer de coder la ressource que nous avons commencée dans le précédent. Il nous reste à voir comment créer et modifier un film. Pour vous simplifier la vie voilà le code de démarrage de cet article qui tient donc compte de tout ce qu’on a vu dans le précédent. Créer un film Les routes Pour la création d’un film on va avoir deux routes : pour afficher le formulaire de création pour soumettre le formulaire Le contrôleur Dans le contrôleur ce sont les méthodes create et store qui sont concernées. On va donc les coder : use App\Http\Requests\FilmRequest; ... public function create(): View { return…