Routage des modules

En enregistrant des routes, vous indiquez à NexoPOS comment il peut amener l’utilisateur vers vos routes. Le système de routes utilise le routage Laravel. Ici, nous allons simplement aborder la spécificité nécessaire pour comprendre comment les routes fonctionnent pour les modules.

Type de fichiers de route

Chaque module est livré avec 2 fichiers dans le dossier « Routes » qui sont utilisés pour le routage :

• api.php, qui est censé être utilisé uniquement pour les appels d’API. C’est ici que vous définirez vos points de terminaison d’API.

• web.php, ce qui signifie pour toutes les routes susceptibles d’être accessibles par accès direct (GET) ou par toute autre méthode régulière. Toute route qui mène à une interface utilisateur doit être enregistrée dans un fichier web.php.

Vous trouverez davantage de détails ici.

Différence entre les routes publiques et privées (tableau de bord)

Les routes publiques sont probablement disponibles pour le public. Ces routes n’utilisent généralement pas le préfixe « dashboard » et, le plus souvent, ne nécessitent pas d’autorisations pour être accessibles.

Les routes privées sont des routes qui utilisent « dashboard » comme préfixe. Ces routes servent de routes administratives et permettent de concevoir toutes les routes qui mènent vers des interfaces de tableau de bord.

Déclaration de l’itinéraire

Ici, nous allons enregistrer une route qui nous amène vers une page du tableau de bord avec un slug final « foobar ».

<?php
use App\Modules\FooBar\Controllers\FooBarController;

Route::get( '/dashboard/foobar', [ FooBarController::class, 'index' ]);

Notez qu’ici, nous chargeons un contrôleur qui est censé être enregistré dans le dossier « Http/Controllers » avec le nom de fichier FooBarController.php.

Si vous souhaitez créer un contrôleur pour votre module, vous pouvez toujours utiliser la commande :

php artisan modules:controller {module_namespace} {controller_class_name} 

Pour créer un FooBarController en tant que contrôleur, nous utiliserons la commande suivante :

php artisan modules:controller FooBar FooBarController

Protéger les routes avec des autorisations

Comme vous pouvez protéger des menus avec des autorisations, vous pouvez également protéger des routes à l’aide d’autorisations. Ici, nous allons définir l’autorisation sur un middleware comme ceci.

<?php
use App\Modules\FooBar\Controllers\FooBarController;
use App\MiddleWare\NsRestrictMiddleware;

Route::get( '/dashboard/foobar', [ FooBarController::class, 'index' ])
  ->middleware( 
      NsRestrictMiddleware::arguments([ 'can.fly' ])
  );

Ici, le nom du middleware à utiliser est « NsRestrictMiddleware », qui accepte en paramètre l’autorisation (ou un tableau d’autorisations) que nous devrons exiger pour autoriser l’accès à la route. Dans notre exemple, nous avons utilisé « can.fly » comme autorisation.

Demande d’authentification pour certaines routes

Si vous souhaitez protéger certaines routes avec une authentification, vous devrez attacher un middleware à ces routes. Voici un exemple :

<?php

use App\Http\Middleware\Authenticate;
use Illuminate\Routing\Middleware\SubstituteBindings;
use Illuminate\Support\Facades\Route;
use Modules\MyModule\Http\Controllers\MyModuleController;

Route::prefix( 'dashboard' )->group( function() {
    Route::middleware([
        SubstituteBindings::class,
        Authenticate::class, // <= will be accessible only if the user is authenticated.
    ])->group( function() {
        Route::get( '/my-module', [ MyModuleController::class, 'settingsPage' ]);
    });
});

Nous utilisons ici le middleware « Authenticate » pour protéger les routes définies dans le groupe. Notez que « SubstituteBindings » est également nécessaire pour que la liaison des modèles fonctionne pour les modules.