input

Entrada

Uma estrutura de validação de entrada com um nome chato

Changelog

Conceito

A validação de entrada é uma tarefa importante em qualquer aplicativo da Web, mas continua sendo uma tarefa extremamente tediosa. Isso substitui verificações misturadas por uma estrutura de dados adequada que define claramente as entradas necessárias e opcionais.

O design se reflete em torno da idéia de design orientado pela API, onde cada endpoint da API é seu próprio objeto, no entanto, não exige explicitamente esse formato

• É capaz de validar para qualquer objeto que defina os requisitos de entrada. O que ele não pode lidar facilmente é o padrão comum de grandes controles que são responsáveis ​​para muitos URLs, pois cada URL possui seus próprios requisitos de validação. Certamente é possível estruturar seu código de forma a tornar isso funcionar, mas isso pode se tornar mais complicado do que o benefício que ele oferece.

Etapas de manuseio de dados

A entrada bruta é transformada em dados seguros em duas etapas primárias:

• Análise
• Validação

A análise é responsável por transformar a sequência de entrada bruta em uma matriz associativa. Se o seu aplicativo estiver estruturado para fazê -lo, esta etapa poderá ser ignorada completamente.

A validação é a parte mais útil da biblioteca - pegando um conjunto definido de parâmetros opcionais e necessários e seus tipos e comparando os valores de entrada com a especificação. A implementação impede que os dados inválidos sejam totalmente propagados; Não é possível criar um objeto SafeInput (que seu aplicativo usará) a partir de dados inválidos!

Após a conclusão deste processo, é retornado um objeto SafeInput que contém dados de acordo com a especificação definida pelo objeto que implementa ValidationInterface (os valores opcionais ausentes são nulos).

Como essa biblioteca existe para fornecer dados confiáveis, ela o impedirá ativamente de adivinhar; Por exemplo, o uso de isset ou empty na estrutura de dados lançará uma exceção. É a experiência do autor que agir incapaz de confiar em seus dados validados é um anti-padronização e um cheiro de código; Se você insistir em fazê -lo, essa não é a ferramenta certa para você. Forçar a confiança como essa tende a impedir que a documentação se separe da realidade.

Exemplo

Um exemplo básico a seguir:

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