Les registres

Un registre laisse un package ajouter un élément à une liste que le cœur assemble — sans que le cœur connaisse cet élément. C'est la mécanique des menus, des routes, des étapes de checkout, des options et des hooks.

Le problème

Un package « promotions » veut une entrée dans le menu du back-office et ses propres routes d'administration. Mais le cœur ne doit jamais référencer « promotions ». Comment ajouter à une liste possédée par le cœur, de l'extérieur ?

Le principe

Le cœur expose un registre (un singleton). Au démarrage, chaque package y dépose sa contribution. Le cœur lit la liste agrégée au moment voulu (rendu du menu, montage des routes…).

Tout se passe dans le boot() du provider.

Exemple : une entrée de menu

use Slab\Framework\Core\BackMenu\Contracts\BackMenuRegistry;

$this->app->make(BackMenuRegistry::class)->add(
    'catalog.promotions', __('Promotions'),
    route: 'back.promotions.index', icon: 'local_offer', parent: 'catalog', priority: 40,
);

Exemple : des routes

use Slab\Framework\Core\Routing\Contracts\RouteContributionRegistrar;
use Illuminate\Support\Facades\Route;

$this->app->make(RouteContributionRegistrar::class)->back(function () {
    Route::resource('promotions', PromotionsController::class)->except('show', 'destroy');
});

Les routes contribuées héritent du groupe back-office (préfixe admin/, noms back.*, middlewares auth + CanAccessBackoffice) et sont montées dans le bon ordre vis-à-vis des routes attrape-tout du front. Le pendant front est ->front(...).

Les registres de Slab

Registre	Vous y ajoutez…	Détail
BackMenuRegistry	une entrée de menu BO	priorité réordonnable via config/back_menu.php
RouteContributionRegistrar	des routes back() / front()	ordre garanti
CheckoutStepRegistry	une étape de tunnel	priorité via config/checkout.php
CheckoutOptionRegistry	un fournisseur d'options (livraison, paiement…)	voir ci-dessous
ViewHookRegistry	un onglet / une section dans une vue	voir hooks & slots
DatatableExtensionRegistry	une colonne / action à une datatable existante	voir ci-dessous
PriceModifierRegistry, TotalsModifierRegistry	un maillon de pipeline	priorités

Cas particulier : les options de checkout

Une feature qui ajoute un choix au tunnel (un transporteur, un mode de paiement) n'expose que de la donnée via un CheckoutOptionProvider — jamais de HTML :

use Slab\Framework\Core\Checkout\Contracts\CheckoutOptionRegistry;

$this->app->make(CheckoutOptionRegistry::class)->register(ShippingOptionProvider::class);

Le provider décrit une exigence (shipping, payment…) et renvoie une liste d'options structurées (id, libellé, prix, méta). Le frontend les rend génériquement : ajouter un transporteur le fait apparaître au checkout, sans toucher au front. Détail : Commande & checkout.

Étendre une datatable existante

Les listings du back-office sont des datatables identifiées par un id (products, taxes, users…). Le DatatableExtensionRegistry laisse un package ou votre application ajouter une colonne, une action ou une option à une datatable existante, sans la forker :

use Slab\Framework\Core\View\Contracts\DatatableExtensionRegistry;
use Stafe\LaravelDatatable\Core\Datatable;

$this->app->make(DatatableExtensionRegistry::class)->extend('products', function (Datatable $datatable) {
    $datatable->columns()->column('supplier')->label(__('Fournisseur'));
});

La contribution reçoit la Datatable après sa construction et la mute via l'API publique du paquet datatable (colonnes, actions, options). Les ids sont ceux passés à ->id(...) dans les datatables du cœur.

À retenir

• On ajoute à une liste, on ne remplace pas le cœur.
• Tout se fait au boot(), par add() / register().
• L'ordre se règle par priorité (souvent réordonnable en config).