input

Saisir

Un cadre de validation d'entrée avec un nom ennuyeux

Changelog

Concept

La validation des entrées est une tâche importante dans toute application Web, mais reste une tâche extrêmement fastidieuse. Cela remplace les vérifications entremêlées par une structure de données appropriée qui définit clairement les entrées requises et facultatives.

La conception se réalise autour de l'idée de conception axée sur l'API, où chaque point de terminaison API est son propre objet, mais ne nécessite pas explicitement ce format

• Il est capable de valider tout objet qui définit les exigences d'entrée. Ce qu'il ne peut pas gérer facilement, c'est le modèle commun de grandes contrôles qui sont respirés pour de nombreuses URL, car chaque URL a ses propres exigences de validation. Il est certainement possible de structurer votre code de manière à que cela fonctionne, mais cela est susceptible de devenir plus compliqué que l'avantage qu'il offre.

Étapes de traitement des données

L'entrée brute est transformée en données sûres en deux étapes principales:

• Analyse
• Validation

L'analyse est responsable de la transformation de la chaîne d'entrée brute en un tableau associatif. Si votre application est structurée pour le faire, cette étape peut être complètement ignorée.

La validation est la partie la plus utile de la bibliothèque - en prenant un ensemble défini de paramètres facultatifs et requis et de leurs types, et en comparant les valeurs d'entrée à la spécification. La mise en œuvre empêche les données non valides de se propager entièrement; Il n'est pas possible de créer un objet SafeInput (que votre application utilisera) à partir de données non valides!

À la fin de ce processus, un objet SafeInput est renvoyé qui contient des données conformément à la spécification définie par l'objet Implémentation ValidationInterface (les valeurs facultatives manquantes sont nuls).

Étant donné que cette bibliothèque existe pour fournir des données fiables, elle vous empêchera activement de les deviner; Par exemple, l'utilisation isset ou empty sur la structure de données lancera une exception. C'est l'expérience de l'auteur que le jeu incapable de faire confiance à vos données validés est une odeur anti-motif et de code; Si vous insistez pour le faire, ce n'est pas le bon outil pour vous. Forcer la confiance comme celle-ci tend à empêcher la documentation de se séparer de la réalité.

Exemple

Un exemple de base suit:

some_controller_file.php

 <?php
// This would be in its own file
use Firehed  Input  Interfaces  ValidationInterface ;

use Firehed  Input  Containers  SafeInput ;
use Firehed  Input  Objects as O ;
class Endpoint
    implements ValidationInterface {

    public function getOptionalInputs () {
        return [
            ' bar ' => new O  Text (),
            ' baz ' => ( new O  Text ())-> setDefaultValue ( ' my baz ' ),
        ];
    }

    public function getRequiredInputs () {
        return [
            ' foo ' => new O  Text (),
        ];
    }

    public function execute ( SafeInput $ i ) {
        // ... do some magic
        // $i['foo'] will be a string
        // $i['bar'] will be a string or null, since it was optional
        // $i['baz'] will be a string or 'my baz', since it was an optional with a default value
    }
}

index.php

 <?php
// This is the core of your Front Controller

use Firehed  Input  Containers  RawInput ;
use Firehed  Input  Parsers  URLEncoded ;

// The endpoint should be detrmined by your router
$ endpoint = new Endpoint ();

// The parser should be determined by the Content-Type header
$ parser = new URLEncoded ();


try {
    $ input = ( new RawInput ( " foo=world " ))
        -> parse ( $ parser )
        -> validate ( $ endpoint );
    $ endpoint -> execute ( $ input );
} catch ( Firehed  Input  Exceptions  InputException $ e ) {
    // The input contained invalid data
} catch ( Exception $ e ) {
    // Do any logging, error responses, etc.
    echo $ e ;
}