Laravel 7

Laravel Boilerplate

J’avais déjà écrit un article sur Laravel Boilerplate mais comme il date un peu en voici une version rafraichie.

Lorsqu’on utilise fréquemment Laravel on est amené à effectuer des tâches répétitives et à utiliser une certain nombre de classes et fonctionnalités à travers différents projets. On pourrait ainsi imaginer une trame de base comportant tout ce qu’on utilise habituellement. C’est en gros ce qui est réalisé par Laravel Boilerplate. Voyons un peu ce qui se cache dans cette librairie qui a obtenu quand même actuellement plus de 4700 stars sur Github !

Installation

On dispose d’un site plutôt bien fait :

Il y a une page de démarrage rapide pour Laravel 7 (Quick Start).

Comme c’est juste un Laravel amélioré l’installation est assez classique. On va commencer par récupérer le dépôt, il y a un bouton pour ça :

On copie tout ça sur un serveur en gardant le nom laravel-boilerplate-master pour l’exemple.

On trouve un fichier .env.example plutôt bien garni par rapport à celui de base de Laravel, il faut le renommer en .env.

Ensuite il n’y a plus qu’à lancer l’installation :

composer install

Ça dure un moment parce qu’il y a pas mal de package prévus…

Il faut ensuite générer une clé pour le cryptage parce qu’elle est vide dans le dépôt (ça évite d’avoir de multiples sites sur le web avec la même clé de cryptage) :

php artisan key:generate

Ensuite on crée une base de données qu’on appelle par exemple boilerplate et on renseigne .env :

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=boilerplate
DB_USERNAME=root
DB_PASSWORD=

On peut alors lancer les migrations et la population :

php artisan migrate --seed

On se retrouve avec 13 tables :

Avec 2 utilisateurs par défaut :

Pour le frontend on a le choix entre npm et yarn. Personnellement j’utilise npm, donc il faut installer :

npm install

Là aussi on a le temps d’aller boire un café…

On peut alors générer les fichiers pour le développement :

npm run dev

On trouve aussi de nombreux tests qu’on peut lancer théoriquement avec phpunit. Personnellement j’ai dû appeler l’application dans son dossier mais tous les tests passent :

État des lieux

Tous semble correct alors je lance :

Une page d’accueil sommaire avec une barre de navigation, un accès au login et à l’enregistrement. On peut accéder à l’administration avec :

Username: admin@admin.com

Password: secret

On tombe sur cette page :

Apparemment on a par défaut une authentification à 2 facteurs (A2F) pour accéder à l’administration. Pour rappel c’est une méthode qui oblige, en plus d’entrer un identifiant et un mot de passe, de préciser un code transmis par une autre méthode, habituellement par SMS. On peut changer ce comportement avec cette variable dans le fichier .env :

ADMIN_REQUIRES_2FA=false

Maintenant quand on se connecte on arrive directement sur cette page :

Le template d’administration est CoreUI dans sa version gratuite, c’est à dire pratiquement sans plugins. Personnellement je préfère AdminLTE.

On dispose de nombreuses langue, alors on change pour le français.

On trouve une gestion des utilisateurs :

On peut remarquer une petite lacune dans la traduction ici.

Une gestion des rôles :

Une visualisation des logs :

Pour en apprendre plus il faut plonger dans la documentation ou fouiller un peu le code…

DDD ?

Pour la réalisation de projets volumineux la question de l’organisation du code est cruciale. Le DDD (Domain-Driven Design) est est une collection de principes. En gros on divise le code en modèles de domaine, c’est une histoire de conception. Avec Laravel essentiellement on applique la POO qui est déjà une façon d’organiser le code. Alors quid du DDD ? Dans le cadre de boilerplate ce n’est en fait qu’une façon de diviser le code en modules fonctionnels. On a une première division :

L’authentification est elle-même divisée en plusieurs modules :

Et ainsi de suite :

Est-ce que cette approche est plus intéressante du découpage classique de Laravel ? En tout cas c’est l’organisation proposée par Boilerplate. Rien ne nous empêche de remettre tout dans l’ordre habituel mais pourquoi ne pas tenter l’expérience ?

Les contrôleurs

On trouve des contrôleurs rangés dans leur dossiers et sous-dossiers :

On ne trouve pas grand chose dans ces contrôleurs, essentiellement une méthode pour ouvrir une vue. Mais évidemment la plupart des contrôleurs se trouvent dans leurs domaines :

Les middlewares

On trouve ces middlewares :

On remarque l’ajout de LocaleMiddleware pour la gestion des locales. Mais ce ne n’est pas le seul middleware ajouté et on trouve les autres dans les domaines :

Les modèles

Les modèles se trouvent aussi dans les domaines :

On trouve de nombreux traits. Ils servent pour gérer les attributs, les relations, les scopes et les méthodes spécifiques. Ça fait au final pas mal de fichiers. Par exemple pour le modèle User on trouve une rafale de traits :

class User extends Authenticatable implements MustVerifyEmail, TwoFactorAuthenticatable
{
    use HasRoles,
        Impersonate,
        MustVerifyEmailTrait,
        Notifiable,
        SoftDeletes,
        TwoFactorAuthentication,
        UserAttribute,
        UserMethod,
        UserRelationship,
        UserScope;

C’est un choix architectural…

Les routes

Là aussi on trouve de nombreux fichiers :

Pour comprendre l’organisation il faut regarder le code dans routes/web.php :

/*
 * Frontend Routes
 */
Route::group(['as' => 'frontend.'], function () {
    includeRouteFiles(__DIR__.'/frontend/');
});

L’espace de nom est analogue au chemin des dossiers. Ici on va dans le dossier frontend. Dans ce dossier dans le fichier auth.php on trouve par exemple :

Route::group(['as' => 'auth.'], function () {

Les providers

On trouve ces providers :

On a donc l’ajout de :

  • ComposerServiceProvider pour ajouter des composeurs de vues,
  • EventServiceProvider pour l’écoute des événements,
  • HelperServiceProvider pour les helpers,
  • LocaleServiceProvider pour les locales,
  • ObserverServiceProvider pour l’observation des modèles.

Livewire et AlpineJS

Les tableaux de l’administration sont générés avec le package laravel-livewire-tables. J’avoue que je ne le connaissais pas et il a l’air sympathique. Il est basé sur Livewire qui fonctionne avec AlpineJS qui se présente lui-même comme le Tailwind de JavaScript. Si on veut utiliser Boilerplate on a donc intérêt à se familiariser avec tout ça !

Par exemple pour la création d’un utilisateur on a ce formulaire :

Pour le champ du type d’utilisateur on a ce code :

<div x-data="{userType : '{{ $model::TYPE_USER }}'}">

On a une directive x-data d’AlpineJS. On retrouve userType ici dans le formulaire :

<select name="type" class="form-control" required x-on:change="userType = $event.target.value">

On a là une autre directive, cette fois x-on avec l’écoute de l’événement change. Du coup quand on change le type d’utilisateur on affiche ou on masque d’autres champs de saisie :

Ca vous donne une idée du principe de fonctionnement d’AlpineJS qui est essentiellement déclaratif. C’est un peu entre JQuery et Vue.js. Pour une bonne présentation en français c’est ici.

Pour ce qui concerne la création des tables avec Liveware on trouve le code ici :

Au niveau de la syntaxe c’est assez proche de Laravel Datatables. On définit des données et des colonnes.

Conclusion

Ce boilerplate est bien structuré et codé, c’est une bonne base de départ pour un projet à condition d’accepter l’organisation imposée. Il peut faire gagner du temps au niveau de la constitution du backend. Il est équipé d’une batterie complète de tests. Je regrette juste le choix de CoreUI. D’autre part il y a des choix architecturaux et logiciels qui peuvent être gênants ou nécessiter un temps d’apprentissage non négligeable. je m’interroge vraiment concernant Liveware et sa pertinence, les avis sont partagés à son sujet, il faudra que je l’utilise vraiment un jour pour me faire une opinion.

Print Friendly, PDF & Email

Leave a Reply