Sök…


parametrar

Parameter detaljer
nödvändig Fältet krävs
ibland Kör valideringskontroller mot ett fält endast om det fältet finns i inmatningsfältet
e-post Inmatningen är ett giltigt e-postmeddelande
max: värde Ingångsvärdet ska ligga under det maximala värdet
unik: db_table_name Inmatningsvärdet ska vara unikt i det angivna namnet på databastabellen
accepterad Ja / På / 1 sant, användbart för att kontrollera TOS
active_url Måste vara en giltig URL enligt checkdnsrr
efter : datum Fält under validering måste ge ett värde efter det angivna datumet
alfa Fältet under validering måste vara helt alfabetiska tecken.
alpha_dash Fältet under validering kan ha alfanumeriska tecken samt streck och understreck.
alpha_num Fältet under validering måste vara helt alfanumeriska tecken.
array Måste vara en PHP- grupp
före : datum Fältet måste vara ett värde under det givna datumet
mellan: min, max Ingångsvärdet ska ligga mellan minsta (min) och max (max) värde
boolean Fältet under validering måste kunna kastas som en booleska. Accepterade ingångar är true , false , 1 , 0 , "1" och "0" .
bekräftad Fältet under validering måste ha ett matchande fält för foo_confirmation . Om till exempel fältet under validering är password måste ett matchande password_confirmation finnas i ingången.
datum Fältet under validering måste vara ett giltigt datum enligt strtotime PHP-funktionen.
heltal Fältet under validering måste vara ett heltal
sträng Fältet under validering måste vara en strängtyp .

Grundläggande exempel

Du kan validera förfrågningsdata med validate (tillgänglig i baskontrollern, som tillhandahålls av egenskapen ValidatesRequests ).

Om reglerna passerar kommer din kod att fortsätta fungera normalt. om valideringen dock misslyckas skickas ett felrespons som innehåller valideringsfelen automatiskt tillbaka:

  • för typiska HTML-formulärförfrågningar, kommer användaren att omdirigeras till föregående sida, med formuläret behåller de skickade värdena
  • för förfrågningar som förväntar sig ett JSON-svar genereras ett HTTP-svar med kod 422

I din UserController kan du till exempel spara en ny användare i store , vilket måste behöva valideras innan du sparar.

/**
 * @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
}

I exemplet ovan, validerar vi att name fältet finns med icke-tomt värde. För det andra kontrollerar vi att email postfältet har ett giltigt e-postformat, är unikt i databastabellen "användare" och har maximal längd på 255 tecken.

Den | (pipe) -tecken kombinerar olika valideringsregler för ett fält.

Ibland kanske du vill sluta köra valideringsregler för ett attribut efter det första valideringsfelet. För att göra det, tilldela bail regeln till attributet:

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

Den fullständiga listan över tillgängliga valideringsregler finns i parameterdelen nedan .

Matrisvalidering

Validering av matningsinmatningsfält är mycket enkelt.

Anta att du måste validera varje namn, e-postadress och fadernamn i en given grupp. Du kan göra följande:

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

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

Laravel visar standardmeddelanden för validering. Om du vill ha anpassade meddelanden för matrisbaserade fält kan du dock lägga till följande kod:

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

Din slutkod ser ut så här:

$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());
}

Andra valideringsmetoder

1) Validering av formulärbegäran

Du kan skapa en "formulärbegäran" som kan innehålla behörighetslogiken, valideringsreglerna och felmeddelanden för en viss begäran i din ansökan.

Kommandot make:request Artisan CLI genererar klassen och placerar den i katalogen app/Http/Requests :

php artisan make:request StoreBlogPostRequest

authorize kan åsidosättas med godkännandelogiken för denna begäran:

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

rules kan åsidosättas med de specifika reglerna för denna begäran:

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

messages kan åsidosättas med specifika meddelanden för denna begäran:

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',
    ];
}

För att validera begäran, skriv bara antydan till den specifika förfrågningsklassen på motsvarande styrmetod. Om valideringen misslyckas skickas ett felsvar tillbaka.

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

2) Manuellt skapa Validators

För mer flexibilitet kanske du vill skapa en Validator manuellt och hantera den misslyckade valideringen direkt:

<?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) Flytande regler

Ibland kan det hända att du behöver skapa unika regler för att flyga. Att arbeta med boot() -metoden inom en tjänsteleverantör kan vara över toppen. Från Laravel 5.4 kan du skapa nya regler flytande genom att använda Rule .

Som ett exempel kommer vi att arbeta med UserRequest för när du vill infoga eller uppdatera en användare. För tillfället vill vi att ett namn ska krävas och e-postadressen måste vara unik. Problemet med att använda den unique regeln är att om du redigerar en användare kan de hålla samma e-post, så du måste utesluta den aktuella användaren från regeln. Följande exempel visar hur du enkelt kan göra det genom att använda den nya 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)
            ]
        ];
    }
}

Enkeltformulär för klass för POST, PUT, PATCH

Efter exemplet 'Form Request Validation' , kan samma Request Class användas för POST , PUT , PATCH så att du inte behöver skapa en annan klass med samma / liknande valideringar. Detta är praktiskt om du har attribut i tabellen som är unika.

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

Från början kommer vårt switch-uttalande att titta på metodtypen för begäran ( GET , DELETE , POST , PUT , PATCH ).

Beroende på metod kommer arrayen av regler som definieras att returnera. Om du har ett område som är unik, såsom name fält i exemplet måste du ange en särskild id för validering att ignorera.

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

Om du har en primär nyckel märkt något annat än id , anger du den primära nyckelkolumnen som den fjärde parametern.

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

I det här exemplet använder vi PUT och överför värdet på produkt-id till rutten ( admin/products/{product} ). Så $this->product kommer att vara lika med id att ignorera.

Nu PUT|PATCH dina PUT|PATCH och POST valideringsregler inte vara desamma. Definiera din logik som passar dina krav. Den här tekniken låter dig återanvända de anpassade meddelanden du kan ha definierat i den anpassade formförfrågan.

Felmeddelanden

Anpassa felmeddelanden

Filerna / /resources/lang/[lang]/validation.php innehåller felmeddelanden som ska användas av validatorn. Du kan redigera dem efter behov.

De flesta av dem har platshållare som automatiskt kommer att ersättas när felmeddelandet genereras.

Till exempel i 'required' => 'The :attribute field is required.' , kommer :attribute platshållare att ersättas av fältnamnet (alternativt kan du också anpassa visningsvärdet för varje fält i attributes i samma fil).

Exempel

meddelandekonfiguration:

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

regler:

`email' => `required`

resulterande felmeddelande:

"Vänligen meddela din e-postadress."


Anpassa felmeddelanden inom en Request-klass

Klassförfrågan har tillgång till en metod messages() -metod som ska returnera en matris, detta kan användas för att åsidosätta meddelanden utan att behöva gå in i lang-filerna. Om vi till exempel har en anpassad file_exists validering kan du meddelanden som nedan.

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

}

Visar felmeddelanden

Valideringsfelen blinkas till sessionen och finns också i variabeln $errors , som automatiskt delas till alla vyer.

Exempel på visning av fel i en Blade-vy:

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

Anpassade valideringsregler

Om du vill skapa en anpassad valideringsregel kan du göra det till exempel i en boot för en tjänsteleverantör via Validator-fasaden.

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

extend tar en sträng som kommer att vara namnet på regeln och en funktion som i sin tur kommer att ges namnet på attributet, värdet som valideras, en matris med regelparametrarna och validatorinstansen och bör returnera om valideringen passerar. I det här exemplet kontrollerar vi om värdesträngen börjar med en given substring.

Felmeddelandet för den här anpassade regeln kan ställas in som vanligt i filen /resources/lang/[lang]/validation.php och kan innehålla platshållare, till exempel för parametervärden:

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

replacer tar en sträng som är namnet på regeln och en funktion som i sin tur kommer att skickas över det ursprungliga meddelandet (innan det ersätts), namnet på attributet, namnet på regeln och en rad regelparametrar, och bör returnera meddelandet efter att ha byt ut platshållarna efter behov.

Använd denna regel som alla andra:

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


Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow