Laravel
Validazione

Parametri

Esempio di base

È possibile convalidare i dati della richiesta utilizzando il metodo di validate (disponibile nel controller di base, fornito dalla caratteristica ValidatesRequests ).

Se le regole passano, il tuo codice continuerà ad essere eseguito normalmente; tuttavia, se la convalida fallisce, verrà inviata automaticamente una risposta di errore contenente gli errori di convalida:

• per richieste di moduli HTML tipiche, l'utente verrà reindirizzato alla pagina precedente, con il modulo che mantiene i valori inviati
• per le richieste che prevedono una risposta JSON, verrà generata una risposta HTTP con codice 422

Ad esempio, nel tuo UserController , potresti salvare un nuovo utente nel metodo store , che avrebbe bisogno di essere convalidato prima di salvare.

/**
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required',
        'email' => 'email|unique:users|max:255'
    ],
    // second array of validation messages can be passed here
    [
        'name.required' => 'Please provide a valid name!',
        'email.required' => 'Please provide a valid email!',
    ]);

    // The validation passed
}

Nell'esempio sopra, convalidiamo che il campo del name esiste con un valore non vuoto. In secondo luogo, controlliamo che il campo di email abbia un formato di posta elettronica valido, sia univoco nella tabella del database "utenti" e abbia una lunghezza massima di 255 caratteri.

Il | Il carattere (pipe) combina diverse regole di convalida per un campo.

A volte potresti voler interrompere l'esecuzione delle regole di convalida su un attributo dopo il primo errore di convalida. Per fare ciò, assegna la regola di bail all'attributo:

$this->validate($request, [
    'name' => 'bail|required',
    'email' => 'email|unique:users|max:255'
]);

L'elenco completo delle regole di convalida disponibili è disponibile nella sezione dei parametri riportata di seguito .

Convalida matrice

La convalida dei campi di input del modulo matrice è molto semplice.

Supponiamo di dover convalidare ogni nome, e-mail e nome padre in un determinato array. Potresti fare quanto segue:

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required'
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

Laravel visualizza i messaggi predefiniti per la convalida. Tuttavia, se desideri messaggi personalizzati per campi basati su array, puoi aggiungere il seguente codice:

[
    'name.*' => [
        'required' => 'Name field is required',
    ],
    'email.*' => [
        'unique'   => 'Unique Email is required',
    ],
    'fatherName.*' => [
        'required' => 'Father Name required',
    ]
]

Il tuo codice finale sarà simile a questo:

$validator = \Validator::make($request->all(), [
    'name.*'       => 'required', 
    'email.*'      => 'email|unique:users',
    'fatherName.*' => 'required',
], [
    'name.*'       => 'Name Required',
    'email.*'      => 'Unique Email is required',
    'fatherName.*' => 'Father Name required',
]);

if ($validator->fails()) {
    return back()->withInput()->withErrors($validator->errors());
}

Altri approcci di convalida

1) Convalida della richiesta di modulo

È possibile creare una "richiesta di modulo" che può contenere la logica di autorizzazione, le regole di convalida e i messaggi di errore per una particolare richiesta nell'applicazione.

La make:request comando CLI Artisan genera la classe e la inserisce nella directory app/Http/Requests :

php artisan make:request StoreBlogPostRequest

Il metodo authorize può essere sovrascritto con la logica di autorizzazione per questa richiesta:

public function authorize()
{        
    return $this->user()->can('post');
}

Il metodo delle rules può essere sovrascritto con le regole specifiche per questa richiesta:

public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Il metodo dei messages può essere sovrascritto con i messaggi specifici per questa richiesta:

public function messages()
{
    return [
        'title.required' => 'A title is required',
        'title.unique' => 'There is another post with the same title',
        'title.max' => 'The title may not exceed :max characters',
        'body.required' => 'A message is required',
    ];
}

Per convalidare la richiesta, basta digitare-suggerire la classe di richiesta specifica sul metodo del controller corrispondente. Se la convalida fallisce, verrà inviata una risposta di errore.

public function store(StoreBlogPostRequest $request)
{
    // validation passed
}

2) Creazione manuale dei validatori

Per maggiore flessibilità, è possibile creare manualmente un validatore e gestire direttamente la convalida non riuscita:

<?php    
namespace App\Http\Controllers;

use Validator;
use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class PostController extends Controller
{
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        if ($validator->fails()) {
            return redirect('post/create')
                    ->withErrors($validator)
                    ->withInput();
        }

        // Store the blog post...
    }
}

2) Creazione fluente di regole

Occasionalmente potrebbe essere necessario creare regole univoche al volo, lavorare con il metodo boot() all'interno di un Service Provider potrebbe essere esagerato, a partire da Laravel 5.4 è possibile creare fluentemente nuove regole usando la classe Rule .

Ad esempio, lavoreremo con UserRequest per quando si desidera inserire o aggiornare un utente. Per ora vogliamo che sia richiesto un nome e che l'indirizzo email sia univoco. Il problema con l'utilizzo della regola unique è che se stai modificando un utente, potrebbero mantenere la stessa email, quindi devi escludere l'utente corrente dalla regola. L'esempio seguente mostra come puoi farlo facilmente utilizzando la nuova classe Rule .

<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

class UserRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules(Request $request)
    {
        $id = $request->route()->getParameter('user');

        return [
            'name'           =>  'required',
            
            // Notice the value is an array and not a string like usual
            'email'         =>  [
                'required',
                Rule::unique('users')->ignore($id)
            ]
        ];
    }
}

Classe di richiesta modulo singolo per POST, PUT, PATCH

Seguendo l'esempio di convalida della richiesta di form , è possibile utilizzare la stessa classe di richiesta per POST , PUT , PATCH modo da non dover creare un'altra classe utilizzando le stesse convalide / simili. Questo è utile se hai attributi nella tua tabella che sono unici.

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules() {
    switch($this->method()) {
        case 'GET':
        case 'DELETE':
            return [];
        case 'POST':
            return [
                'name'     => 'required|max:75|unique',
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        case 'PUT':
        case 'PATCH':
            return [
                'name'     => 'required|max:75|unique:product,name,' . $this->product,
                'category' => 'required',
                'price'    => 'required|between:0,1000',
            ];
        default:break;
    }
}

Partendo dall'alto, la nostra istruzione switch analizzerà il tipo di metodo della richiesta ( GET , DELETE , POST , PUT , PATCH ).

A seconda del metodo restituirà la serie di regole definite. Se si dispone di un campo univoco, ad esempio il campo del name nell'esempio, è necessario specificare un particolare ID per la convalida da ignorare.

'field_name' => 'unique:table_name,column_name,' . $idToIgnore`

Se si ha una chiave primaria etichettata diversa da id , si specifica la colonna chiave primaria come quarto parametro.

'field_name' => 'unique:table_name,column_name,' . $idToIgnore . ',primary_key_column'

In questo esempio, stiamo utilizzando PUT e passando alla route ( admin/products/{product} ) il valore dell'id del prodotto. Quindi $this->product sarà uguale id da ignorare.

Ora le tue regole di convalida PUT|PATCH e POST non devono essere le stesse. Definisci la tua logica che si adatta alle tue esigenze. Questa tecnica ti consente di riutilizzare i messaggi personalizzati che potresti aver definito all'interno della classe di richiesta modulo personalizzata.

Messaggio di errore

Personalizzazione dei messaggi di errore

I file /resources/lang/[lang]/validation.php contengono i messaggi di errore che devono essere utilizzati dal validatore. Puoi modificarli secondo necessità.

La maggior parte di essi ha segnaposti che verranno automaticamente sostituiti durante la generazione del messaggio di errore.

Ad esempio, in 'required' => 'The :attribute field is required.' , il segnaposto :attribute sarà sostituito dal nome del campo (in alternativa, è possibile personalizzare anche il valore di visualizzazione di ciascun campo nell'array degli attributes nello stesso file).

Esempio

configurazione del messaggio:

'required' => 'Please inform your :attribute.',
//...
'attributes => [
    'email' => 'E-Mail address'
]

regole:

`email' => `required`

messaggio di errore risultante:

"Per favore informa il tuo indirizzo e-mail."

Personalizzazione dei messaggi di errore all'interno di una classe di richiesta

La classe Request ha accesso a un metodo messages() che dovrebbe restituire un array, questo può essere usato per sovrascrivere i messaggi senza dover accedere ai file lang. Ad esempio, se abbiamo una convalida personalizzata di file_exists puoi inviare messaggi come di seguito.

class SampleRequest extends Request {

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'image' =>  'required|file_exists'
        ];
    }

    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    public function messages()
    {
        return [
            'image.file_exists' =>  'That file no longer exists or is invalid'
        ];
    }

}

Visualizzazione dei messaggi di errore

Gli errori di convalida vengono visualizzati sulla sessione e sono disponibili anche nella variabile $errors , che viene condivisa automaticamente su tutte le visualizzazioni.

Esempio di visualizzazione degli errori in una vista Blade:

@if (count($errors) > 0)
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

Regole di convalida personalizzate

Se si desidera creare una regola di convalida personalizzata, è possibile farlo ad esempio nel metodo di boot di un fornitore di servizi, tramite la facciata Validator.

<?php
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Validator;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Validator::extend('starts_with', function($attribute, $value, $parameters, $validator) {
            return \Illuminate\Support\Str::startsWith($value, $parameters[0]);
        });

        Validator::replacer('starts_with', function($message, $attribute, $rule, $parameters) {
            return str_replace(':needle', $parameters[0], $message);
        });
    }
}

Il metodo extend prende una stringa che sarà il nome della regola e una funzione che a sua volta sarà passata il nome dell'attributo, il valore che viene convalidato, una matrice dei parametri della regola e l'istanza del validatore, e dovrebbe restituire se la convalida passa. In questo esempio, stiamo controllando se la stringa del valore inizia con una sottostringa data.

Il messaggio di errore per questa regola personalizzata può essere impostato normalmente nel file /resources/lang/[lang]/validation.php e può contenere segnaposti, ad esempio, per i valori dei parametri:

'starts_with' => 'The :attribute must start with :needle.'

Il metodo replacer prende una stringa che è il nome della regola e una funzione che a sua volta verrà passata al messaggio originale (prima della sostituzione), il nome dell'attributo, il nome della regola e una matrice dei parametri della regola, e dovrebbe restituire il messaggio dopo aver sostituito i segnaposto secondo necessità.

Usa questa regola come qualsiasi altra:

$this->validate($request, [
    'phone_number' => 'required|starts_with:+'
]);