input

Aporte

Un marco de validación de entrada con un nombre aburrido

Colegio de cambios

Concepto

La validación de entrada es una tarea importante en cualquier aplicación web, pero sigue siendo una tarea extremadamente tediosa. Esto reemplaza las verificaciones entremezcladas con una estructura de datos adecuada que define claramente las entradas requeridas y opcionales.

El diseño se reolverá en torno a la idea del diseño impulsado por la API, donde cada punto final de la API es su propio objeto, sin embargo, no requiere explícitamente este formato

• Es capaz de validar para cualquier objeto que define los requisitos de entrada. Lo que no puede manejar fácilmente es el patrón común de grandes controleLRS que son respetables para muchas URL, ya que cada URL tiene sus propios requisitos de validación. Ciertamente es posible estructurar su código de una manera para que esto funcione, pero eso es probable que se vuelva más complicado que el beneficio que proporciona.

Pasos de manejo de datos

La entrada sin procesar se transforma en datos seguros en dos pasos principales:

• Analizador
• Validación

El análisis es responsable de transformar la cadena de entrada sin procesar en una matriz asociativa. Si su aplicación está estructurada para hacerlo, este paso se puede omitir por completo.

La validación es la parte más útil de la biblioteca: tomar un conjunto definido de parámetros opcionales y requeridos y sus tipos, y comparar los valores de entrada con la especificación. La implementación evita que los datos no válidos se propagan por completo; ¡No es posible crear un objeto SafeInput (que su aplicación usará) a partir de datos no válidos!

Al finalizar este proceso, se devuelve un objeto SafeInput que contiene datos de acuerdo con la especificación definida por la implementación de Objeto ValidationInterface (los valores opcionales faltantes son nulos).

Debido a que esta biblioteca existe para proporcionar datos confiables, le impedirá activamente la segunda adherencia; Por ejemplo, usar isset o empty en la estructura de datos lanzará una excepción. Es la experiencia del autor que la actuación no puede confiar en sus datos validados es un antipatrón y un olor a código; Si insiste en hacerlo, esta no es la herramienta adecuada para usted. Forzar la confianza de esta manera tiende a evitar que la documentación se drene aparte de la realidad.

Ejemplo

Sigue un ejemplo básico:

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 ;
}