Validation

Niang\Core\Validation\Validator : 29 règles, vérifiées une à une contre Validator::applyRule() — pas contre une liste retapée de mémoire.

Valider depuis un contrôleur

Controller::validate() encapsule Validator::make(...)->validate() :

public function store(Request $request): Response
{
    $data = $this->validate($request, [
        'name' => 'required|string|min:2',
        'email' => 'required|email',
        'message' => 'required|string|min:10',
    ]);

    // $data ne contient que les champs déclarés dans les règles.
}

Les règles d'un champ s'écrivent en chaîne séparée par |, ou en tableau (['required', 'string', 'min:2']) — les deux formes sont équivalentes.

FormRequest : valider par injection

Une classe qui étend Niang\Core\Validation\FormRequest et déclare rules() se valide toute seule dès qu'elle est type-hintée dans un contrôleur — le Container la construit à partir de la requête courante, vérifie authorize() puis valide rules() avant même d'entrer dans la méthode (voir injection par réflexion) :

namespace App\Requests;

use Niang\Core\Validation\FormRequest;

class ContactRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => 'required|string|min:2',
            'email' => 'required|email',
            'message' => 'required|string|min:10',
        ];
    }
}

public function store(ContactRequest $request): Response
{
    $data = $request->validated(); // déjà validé, garanti au moment où on arrive ici
}

authorize() retourne true par défaut ; la surcharger et retourner false lève une AuthorizationException (403) avant même la validation — utile pour une FormRequest qui doit vérifier une permission en plus de la forme des données.

Ce qui se passe quand ça échoue

Une règle qui échoue lève une ValidationException, interceptée une seule fois par Handler::render() (voir cycle de vie d'une requête) — jamais à gérer manuellement dans le contrôleur :

• Si la requête attend du JSON (Accept: application/json) : réponse 422 avec {"message": "...", "errors": {...}}.
• Sinon : redirection vers le Referer, avec les erreurs et la saisie précédente flashées en session — récupérables avec errors('champ') et old('champ') dans la vue.

<input type="email" name="email" value="<?= e(old('email')) ?>">
<?= component('components/field-errors', ['field' => 'email']) ?>

Une seule erreur est retenue par champ (la première règle qui échoue), pour rester lisible.

Toutes les règles

nullable n'est pas dans ce tableau : ce n'est pas une règle mais un modificateur (géré par runRules(), avant la boucle) — placé avant les autres, il fait sauter toutes les règles suivantes si le champ est vide, plutôt que de les faire échouer.

Messages et attributs personnalisés

Validator::make($data, [
    'email' => 'required|email',
], [
    'email.required' => 'Une adresse email est nécessaire pour vous recontacter.',
], [
    'email' => 'Adresse email',
])->validate();

Le 3ᵉ argument (messages) accepte une clé 'champ.règle' (prioritaire) ou juste 'règle' (s'applique à tous les champs). Le 4ᵉ (attributes) remplace le nom du champ dans les messages par défaut, ex. « Le champ Adresse email est requis. » plutôt que « Le champ email est requis. ».

Les messages par défaut viennent de lang/<langue>/validation.php, livré en français et en anglais (APP_LOCALE) : modifiez-y un message pour tout le projet, ou donnez un libellé à un champ dans sa section attributes — voir Langues.

Valider un tableau (règles items.*)

Une clé contenant .* applique ses règles à chaque élément d'un tableau :

Validator::make($data, [
    'items' => 'required|array',
    'items.*.name' => 'required|string',
    'items.*.quantity' => 'required|integer|min:1',
])->validate();

Chaque erreur est indexée par position : items.0.name, items.1.quantity, etc. — récupérables individuellement avec errors('items.0.name').