اعتبار سنجی

• استفاده پایه
• اعتبار سنجی کنترلر
• اعتبار درخواست فرم
• کار با پیام های خطا
• پیام های خطا و نمایش ها
• قوانین اعتبار سنجی موجود
• اضافه کردن قوانین مشروط
• پیام های خطای سفارشی
• قوانین اعتبار سنجی سفارشی

استفاده پایه

لاراول با یک تسهیلات ساده و راحت برای اعتبارسنجی داده ها و بازیابی پیام های خطای اعتبارسنجی از طریق Validator کلاس ارائه می شود.

مثال اعتبار سنجی پایه

$validator = Validator::make(
    ['name' => 'Dayle'],
    ['name' => 'required|min:5']
);

اولین آرگومان ارسال شده به make متد، داده های تحت اعتبارسنجی است. آرگومان دوم قوانین اعتبارسنجی است که باید روی داده ها اعمال شود.

استفاده از آرایه ها برای تعیین قوانین

قوانین چندگانه ممکن است با استفاده از یک کاراکتر "pipe" یا به عنوان عناصر جداگانه یک آرایه مشخص شوند.

$validator = Validator::make(
    ['name' => 'Dayle'],
    ['name' => ['required', 'min:5']]
);

اعتبارسنجی چندین فیلد

$validator = Validator::make(
    [
        'name' => 'Dayle',
        'password' => 'lamepassword',
        'email' => 'email@example.com'
    ],
    [
        'name' => 'required',
        'password' => 'required|min:8',
        'email' => 'required|email|unique:users'
    ]
);

هنگامی که یک Validator نمونه ایجاد شد، روش fails (یا passes ) ممکن است برای انجام اعتبار سنجی استفاده شود.

if ($validator->fails())
{
    // The given data did not pass validation
}

اگر اعتبارسنجی ناموفق بود، می‌توانید پیام‌های خطا را از اعتبارسنجی بازیابی کنید.

$messages = $validator->messages();

همچنین می‌توانید به آرایه‌ای از قوانین اعتبارسنجی ناموفق، بدون پیام دسترسی داشته باشید. برای این کار از failed روش زیر استفاده کنید:

$failed = $validator->failed();

اعتبار سنجی فایل ها

این Validator کلاس چندین قانون را برای اعتبارسنجی فایل‌ها ارائه می‌کند، مانند size ، mimes و غیره. هنگام اعتبارسنجی فایل‌ها، می‌توانید به سادگی آن‌ها را با سایر داده‌های خود به اعتبارسنجی ارسال کنید.

پس از اعتبارسنجی هوک

اعتباردهنده همچنین به شما امکان می‌دهد تا پس از تکمیل اعتبارسنجی، تماس‌های برگشتی را ضمیمه کنید. این به شما امکان می دهد تا به راحتی اعتبار سنجی بیشتری را انجام دهید و حتی پیام های خطای بیشتری را به مجموعه پیام اضافه کنید. برای شروع، after از روش یک نمونه اعتبار سنجی استفاده کنید:

$validator = Validator::make(...);
 
$validator->after(function($validator)
{
    if ($this->somethingElseIsInvalid())
    {
        $validator->errors()->add('field', 'Something is wrong with this field!');
    }
});
 
if ($validator->fails())
{
    //
}

می‌توانید به تعداد after مورد نیاز تماس‌های برگشتی را به اعتبارسنجی اضافه کنید.

اعتبار سنجی کنترلر

البته، ایجاد و بررسی دستی یک Validator نمونه هر بار که اعتبارسنجی را انجام می‌دهید، سردرد است. نگران نباشید، شما گزینه های دیگری دارید! کلاس پایه App\Http\Controllers\Controller موجود در لاراول از یک ValidatesRequests ویژگی استفاده می کند. این ویژگی یک روش واحد و راحت برای اعتبارسنجی درخواست‌های HTTP دریافتی ارائه می‌کند. در اینجا به نظر می رسد:

/**
 * Store the incoming blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $this->validate($request, [
        'title' => 'required|unique|max:255',
        'body' => 'required',
    ]);
 
    //
}

اگر اعتبار سنجی انجام شود، کد شما به طور عادی اجرا می شود. با این حال، اگر اعتبار سنجی ناموفق باشد، یک Illuminate\Contracts\Validation\ValidationException پرتاب می شود. این استثنا به طور خودکار گرفته می شود و یک تغییر مسیر به مکان قبلی کاربر ایجاد می شود. خطاهای اعتبارسنجی حتی به طور خودکار به جلسه فلش می شوند!

اگر درخواست دریافتی یک درخواست AJAX باشد، هیچ تغییر مسیری ایجاد نخواهد شد. در عوض، یک پاسخ HTTP با کد وضعیت 422 به مرورگر بازگردانده می‌شود که حاوی نمایش JSON از خطاهای اعتبارسنجی است.

به عنوان مثال، در اینجا کد معادل به صورت دستی نوشته شده است:

/**
 * Store the incoming blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $v = Validator::make($request->all(), [
        'title' => 'required|unique|max:255',
        'body' => 'required',
    ]);
 
    if ($v->fails())
    {
        return redirect()->back()->withErrors($v->errors());
    }
 
    //
}

سفارشی کردن فرمت خطای فلش شده

اگر می‌خواهید فرمت خطاهای اعتبارسنجی را که در صورت شکست اعتبارسنجی به جلسه فلش می‌شوند سفارشی کنید، formatValidationErrors روی کنترل‌کننده پایه خود را لغو کنید. فراموش نکنید که Illuminate\Validation\Validator کلاس را در بالای فایل وارد کنید:

/**
 * {@inheritdoc}
 */
protected function formatValidationErrors(Validator $validator)
{
    return $validator->errors()->all();
}

اعتبار درخواست فرم

برای سناریوهای اعتبارسنجی پیچیده تر، ممکن است بخواهید یک "درخواست فرم" ایجاد کنید. درخواست‌های فرم، کلاس‌های درخواست سفارشی هستند که حاوی منطق اعتبارسنجی هستند. برای ایجاد کلاس درخواست فرم، از make:request دستور Artisan CLI استفاده کنید:

php artisan make:request StoreBlogPostRequest

کلاس تولید شده در app/Http/Requests دایرکتوری قرار می گیرد. بیایید چند قانون اعتبارسنجی به rules روش اضافه کنیم:

/**
 * Get the validation rules that apply to the request.
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique|max:255',
        'body' => 'required',
    ];
}

بنابراین، قوانین اعتبارسنجی چگونه اجرا می شوند؟ تنها کاری که باید انجام دهید این است که درخواست را در روش کنترلر خود تایپ کنید:

/**
 * Store the incoming blog post.
 *
 * @param  StoreBlogPostRequest  $request
 * @return Response
 */
public function store(StoreBlogPostRequest $request)
{
    // The incoming request is valid...
}

درخواست فرم ورودی قبل از فراخوانی متد کنترلر تأیید می شود، به این معنی که نیازی نیست کنترل کننده خود را با هیچ منطق اعتبارسنجی درهم و برهم کنید. قبلاً تأیید شده است!

اگر اعتبارسنجی ناموفق باشد، یک پاسخ تغییر مسیر برای ارسال کاربر به مکان قبلی خود ایجاد می شود. خطاها نیز به جلسه فلش می شوند تا برای نمایش در دسترس باشند. اگر درخواست یک درخواست AJAX بود، یک پاسخ HTTP با کد وضعیت 422 شامل نمایش JSON از خطاهای اعتبار سنجی به کاربر بازگردانده می شود.

مجوز درخواست های فرم

کلاس درخواست فرم نیز حاوی یک authorize متد است. در این روش، می‌توانید بررسی کنید که آیا کاربر احراز هویت شده واقعاً اختیار به‌روزرسانی یک منبع داده شده را دارد یا خیر. به عنوان مثال، اگر کاربری در تلاش برای به روز رسانی یک نظر پست وبلاگ باشد، آیا واقعاً مالک آن نظر است؟ مثلا:

/**
 * Determine if the user is authorized to make this request.
 *
 * @return bool
 */
public function authorize()
{
    $commentId = $this->route('comment');
 
    return Comment::where('id', $commentId)
                  ->where('user_id', Auth::id())->exists();
}

به فراخوانی route متد در مثال بالا توجه کنید. این روش به شما امکان دسترسی به پارامترهای URI تعریف شده در مسیر فراخوانی شده را می دهد، مانند {comment} پارامتر در مثال زیر:

Route::post('comment/{comment}');

اگر authorize روش برگردد false ، یک پاسخ HTTP با کد وضعیت 403 به طور خودکار برگردانده می شود و روش کنترل کننده شما اجرا نمی شود.

اگر قصد دارید منطق مجوز را در قسمت دیگری از برنامه خود داشته باشید، به سادگی true از authorize روش برگردید:

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

سفارشی کردن فرمت خطای فلش شده

اگر می‌خواهید قالب خطاهای اعتبارسنجی را که در صورت شکست اعتبارسنجی به جلسه فلش می‌شوند سفارشی کنید، formatErrors درخواست پایه خود را لغو کنید ( App\Http\Requests\Request ). فراموش نکنید که Illuminate\Validation\Validator کلاس را در بالای فایل وارد کنید:

/**
 * {@inheritdoc}
 */
protected function formatErrors(Validator $validator)
{
    return $validator->errors()->all();
}

کار با پیام های خطا

پس از فراخوانی messages متد بر روی یک Validator نمونه، یک نمونه دریافت خواهید کرد MessageBag که دارای انواع روش های راحت برای کار با پیام های خطا است.

بازیابی اولین پیام خطا برای یک فیلد

echo $messages->first('email');

بازیابی همه پیام های خطا برای یک فیلد

foreach ($messages->get('email') as $message)
{
    //
}

بازیابی همه پیام های خطا برای همه فیلدها

foreach ($messages->all() as $message)
{
    //
}

تعیین اینکه آیا پیام برای یک فیلد وجود دارد یا خیر

if ($messages->has('email'))
{
    //
}

بازیابی پیام خطا با فرمت

echo $messages->first('email', '<p>:message</p>');

توجه: به طور پیش فرض، پیام ها با استفاده از نحو سازگار با بوت استرپ قالب بندی می شوند.

بازیابی همه پیام های خطا با فرمت

foreach ($messages->all('<li>:message</li>') as $message)
{
    //
}

پیام های خطا و نمایش ها

هنگامی که اعتبار سنجی را انجام دادید، به یک راه آسان برای بازگرداندن پیام های خطا به دیدگاه های خود نیاز دارید. این به راحتی توسط لاراول انجام می شود. مسیرهای زیر را به عنوان مثال در نظر بگیرید:

Route::get('register', function()
{
    return View::make('user.register');
});
 
Route::post('register', function()
{
    $rules = [...];
 
    $validator = Validator::make(Input::all(), $rules);
 
    if ($validator->fails())
    {
        return redirect('register')->withErrors($validator);
    }
});

توجه داشته باشید که وقتی اعتبارسنجی ناموفق باشد، Validator نمونه را با استفاده از روش به Redirect منتقل می کنیم withErrors . این روش پیام های خطا را به جلسه فلش می کند تا در درخواست بعدی در دسترس باشد.

با این حال، توجه داشته باشید که ما مجبور نیستیم پیغام های خطا را به صراحت به نمای مسیر GET متصل کنیم. این به این دلیل است که لاراول همیشه خطاها را در داده های جلسه بررسی می کند و در صورت در دسترس بودن آنها را به طور خودکار به view متصل می کند. بنابراین، مهم است که توجه داشته باشید که یک $errors متغیر همیشه در همه نماهای شما، در هر درخواست، در دسترس خواهد بود، و به شما این امکان را می دهد که به راحتی فرض کنید $errors متغیر همیشه تعریف شده است و می توان با خیال راحت از آن استفاده کرد. متغیر $errors نمونه ای از MessageBag .

بنابراین، پس از تغییر مسیر، می توانید از $errors متغیر محدود شده خودکار در نمای خود استفاده کنید:

<?php echo $errors->first('email'); ?>

به نام کیسه های خطا

اگر چندین فرم در یک صفحه دارید، ممکن است بخواهید MessageBag خطاها را نام ببرید. این به شما امکان می دهد پیام های خطا را برای یک فرم خاص بازیابی کنید. به سادگی یک نام را به عنوان آرگومان دوم به withErrors :

return redirect('register')->withErrors($validator, 'login');

سپس می توانید به MessageBag نمونه نامگذاری شده از $errors متغیر دسترسی پیدا کنید:

<?php echo $errors->login->first('email'); ?>

قوانین اعتبار سنجی موجود

در زیر لیستی از تمام قوانین اعتبارسنجی موجود و عملکرد آنها آمده است:

• پذیرفته شده
• URL فعال
• بعد از (تاریخ)
• آلفا
• خط آلفا
• عدد آلفا
• آرایه
• قبل از (تاریخ)
• بین
• بولی
• تایید شده
• تاریخ
• فرمت تاریخ
• ناهمسان
• ارقام
• ارقام بین
• پست الکترونیک
• موجود است (پایگاه داده)
• فایل تصویری)
• که در
• عدد صحیح
• آدرس آی پی
• حداکثر
• انواع MIME
• حداقل
• نه در
• عددی
• عبارت منظم
• ضروری
• مورد نیاز اگر
• مورد نیاز با
• مورد نیاز با همه
• مورد نیاز بدون
• مورد نیاز بدون همه
• یکسان
• اندازه
• رشته
• منطقه زمانی
• منحصر به فرد (پایگاه داده)
• URL

پذیرفته شده

فیلد مورد تایید باید بله ، در ، 1 یا درست باشد . این برای تأیید پذیرش «شرایط خدمات» مفید است.

فعال_url

فیلد تحت اعتبارسنجی باید مطابق تابع checkdnsrr PHP یک URL معتبر باشد.

بعد از: تاریخ

فیلد مورد تأیید باید مقداری پس از تاریخ معین باشد. تاریخ ها به تابع PHP منتقل می شوند strtotime .

آلفا

فیلد مورد تأیید باید کاملاً حروف الفبا باشد.

alpha_dash

فیلد تحت اعتبارسنجی ممکن است دارای نویسه‌های الف-عددی و همچنین خط تیره و زیرخط باشد.

alpha_num

فیلد مورد تأیید باید کاملاً نویسه‌های الفا عددی باشد.

آرایه

فیلد تحت اعتبارسنجی باید از نوع آرایه باشد.

قبل از: تاریخ

فیلد تحت اعتبارسنجی باید مقداری قبل از تاریخ معین باشد. تاریخ ها به تابع PHP منتقل می شوند strtotime .

بین: حداقل ، حداکثر

فیلد تحت اعتبارسنجی باید دارای اندازه ای بین حداقل و حداکثر باشد . رشته ها، اعداد و فایل ها به همان روشی که size قانون ارزیابی می شود.

بولی

فیلد تحت اعتبارسنجی باید بتواند به صورت بولی فرستاده شود. ورودی های پذیرفته شده عبارتند از true , false , 1 , 0 , "1" و "0" .

تایید شده

فیلد تحت اعتبارسنجی باید دارای یک فیلد منطبق با foo_confirmation . به عنوان مثال، اگر فیلد تحت اعتبارسنجی است password ، یک password_confirmation فیلد مطابق باید در ورودی وجود داشته باشد.

تاریخ

فیلد تحت اعتبارسنجی باید مطابق تابع strtotime PHP دارای تاریخ معتبر باشد.

date_format: قالب

فیلد تحت اعتبارسنجی باید با فرمت تعریف شده مطابق date_parse_from_format تابع PHP مطابقت داشته باشد.

متفاوت: میدانی

فیلد داده شده باید با فیلد تحت اعتبارسنجی متفاوت باشد.

ارقام: ارزش

فیلد مورد تأیید باید عددی باشد و باید دارای طول دقیق باشد .

ارقام_بین: حداقل ، حداکثر

فیلد تحت اعتبارسنجی باید دارای طولی بین حداقل و حداکثر باشد .

پست الکترونیک

فیلد مورد تأیید باید به عنوان یک آدرس ایمیل قالب بندی شود.

وجود دارد: جدول ، ستون

فیلد تحت اعتبار باید در جدول پایگاه داده مشخص وجود داشته باشد.

قانون اساسی استفاده از موجود

'state' => 'exists:states'

تعیین نام ستون سفارشی

'state' => 'exists:states,abbreviation'

همچنین می توانید شرایط بیشتری را مشخص کنید که به عنوان بندهای "where" به پرس و جو اضافه می شوند:

'email' => 'exists:staff,email,account_id,1'

ارسال NULL به عنوان یک مقدار عبارت "where" یک بررسی برای مقدار پایگاه داده اضافه می کند NULL :

'email' => 'exists:staff,email,deleted_at,NULL'

تصویر

فایل تحت اعتبارسنجی باید یک تصویر (jpeg، png، bmp، gif، یا svg) باشد.

در: فو ، بار ، ...

فیلد مورد تایید باید در لیست مقادیر داده شده گنجانده شود.

عدد صحیح

فیلد تحت اعتبارسنجی باید یک مقدار صحیح داشته باشد.

آی پی

فیلد تحت تأیید باید به عنوان یک آدرس IP قالب بندی شود.

حداکثر: ارزش

فیلد تحت اعتبارسنجی باید کمتر یا مساوی یک مقدار حداکثر باشد . رشته ها، اعداد و فایل ها به همان روشی که size قانون ارزیابی می شود.

میم: فو ، بار ،...

فایل تحت اعتبارسنجی باید دارای یک نوع MIME مطابق با یکی از پسوندهای فهرست شده باشد.

استفاده اساسی از قانون MIME

'photo' => 'mimes:jpeg,bmp,png'

دقیقه: ارزش

فیلد تحت اعتبارسنجی باید دارای حداقل مقدار باشد . رشته ها، اعداد و فایل ها به همان روشی که size قانون ارزیابی می شود.

not_in: فو ، بار ،...

فیلد تحت اعتبارسنجی نباید در لیست مقادیر داده شده گنجانده شود.

عددی

فیلد مورد تایید باید دارای مقدار عددی باشد.

regex: الگو

فیلد تحت اعتبارسنجی باید با عبارت منظم داده شده مطابقت داشته باشد.

توجه: هنگام استفاده از regex الگو، ممکن است لازم باشد به جای استفاده از جداکننده لوله، قوانین را در یک آرایه مشخص کنید، به خصوص اگر عبارت منظم حاوی یک کاراکتر لوله باشد.

ضروری

فیلد مورد تایید باید در داده های ورودی وجود داشته باشد.

الزامی_اگر: فیلد ، مقدار ،...

اگر فیلد با هر مقداری برابر باشد، فیلد تحت اعتبارسنجی باید وجود داشته باشد .

مورد نیاز_با: فو ، بار ،...

فیلد تحت اعتبارسنجی فقط در صورتی باید وجود داشته باشد که هر یک از فیلدهای مشخص شده دیگر وجود داشته باشد.

مورد نیاز_با_همه: فو ، بار ،...

فیلد تحت اعتبارسنجی فقط در صورتی باید وجود داشته باشد که تمام فیلدهای مشخص شده دیگر وجود داشته باشد.

الزامی_بدون: فو ، بار ،...

فیلد تحت اعتبارسنجی باید فقط زمانی وجود داشته باشد که هیچ یک از فیلدهای مشخص شده دیگر وجود نداشته باشد.

مورد نیاز_بدون_همه: فو ، بار ،...

فیلد تحت اعتبارسنجی باید فقط زمانی وجود داشته باشد که همه فیلدهای مشخص شده دیگر وجود نداشته باشند.

همان: میدان

فیلد داده شده باید با فیلد تحت اعتبارسنجی مطابقت داشته باشد.

اندازه: ارزش

فیلد تحت اعتبارسنجی باید اندازه ای مطابق با مقدار داده شده داشته باشد . برای داده های رشته ای، مقدار مربوط به تعداد کاراکترها است. برای داده های عددی، مقدار مربوط به یک مقدار صحیح داده شده است. برای فایل ها، اندازه با حجم فایل بر حسب کیلوبایت مطابقت دارد.

رشته

فیلد تحت اعتبارسنجی باید از نوع رشته ای باشد.

منطقه زمانی

فیلد تحت اعتبار باید یک شناسه منطقه زمانی معتبر مطابق تابع timezone_identifiers_list PHP باشد.

منحصر به فرد: جدول ، ستون ، به جز ، idColumn

فیلد تحت اعتبارسنجی باید در یک جدول پایگاه داده خاص منحصر به فرد باشد. اگر column گزینه مشخص نشده باشد، از نام فیلد استفاده می شود.

گاهی اوقات، ممکن است لازم باشد یک اتصال سفارشی برای درخواست های پایگاه داده ایجاد شده توسط Validator تنظیم کنید. همانطور که در بالا مشاهده شد، تنظیم unique:users به عنوان یک قانون اعتبارسنجی از اتصال پایگاه داده پیش فرض برای پرس و جو از پایگاه داده استفاده می کند. برای نادیده گرفتن آن، موارد زیر را انجام دهید:

$verifier = App::make('validation.presence');
 
$verifier->setConnection('connectionName');
 
$validator = Validator::make($input, [
    'name' => 'required',
    'password' => 'required|min:8',
    'email' => 'required|email|unique:users',
]);
 
$validator->setPresenceVerifier($verifier);

استفاده اساسی از قانون منحصر به فرد

'email' => 'unique:users'

تعیین نام ستون سفارشی

'email' => 'unique:users,email_address'

اجبار یک قانون منحصر به فرد برای نادیده گرفتن شناسه داده شده

'email' => 'unique:users,email_address,10'

اضافه کردن بند های اضافی Where

همچنین می توانید شرایط بیشتری را مشخص کنید که به عنوان بندهای "where" به پرس و جو اضافه می شوند:

'email' => 'unique:users,email_address,NULL,id,account_id,1'

در قاعده بالا، فقط ردیف‌هایی با account_id علامت یک 1 در بررسی یکتا گنجانده می‌شوند.

آدرس اینترنتی

فیلد تحت تأیید باید به عنوان یک URL قالب بندی شود.

توجه: این تابع از متد PHP استفاده می کند filter_var .

اضافه کردن قوانین مشروط

در برخی شرایط، ممکن است بخواهید فقط در صورتی که آن فیلد در آرایه ورودی وجود داشته باشد، بررسی های اعتبار سنجی را بر روی یک فیلد اجرا کنید. برای انجام سریع این کار، sometimes قانون را به لیست قوانین خود اضافه کنید:

$v = Validator::make($data, [
    'email' => 'sometimes|required|email',
]);

در مثال بالا، email فیلد فقط در صورتی تایید می شود که در آرایه موجود باشد $data .

اعتبار سنجی مشروط پیچیده

گاهی اوقات ممکن است بخواهید یک فیلد معین را فقط در صورتی بخواهید که فیلد دیگری دارای مقدار بیشتر از 100 باشد. اضافه کردن این قوانین اعتبار سنجی نباید دردسرساز باشد. ابتدا یک نمونه با قوانین استاتیک Validator خود ایجاد کنید که هرگز تغییر نمی کند:

$v = Validator::make($data, [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

بیایید فرض کنیم برنامه وب ما برای کلکسیونرهای بازی است. اگر یک کلکسیونر بازی در برنامه ما ثبت نام کند و بیش از 100 بازی داشته باشد، از او می خواهیم توضیح دهد که چرا صاحب این همه بازی است. برای مثال، شاید آنها یک فروشگاه فروش مجدد بازی راه اندازی کنند، یا شاید فقط از جمع آوری لذت می برند. برای اضافه کردن مشروط این نیاز، می‌توانیم از sometimes روش روی Validator نمونه استفاده کنیم.

$v->sometimes('reason', 'required|max:500', function($input)
{
    return $input->games >= 100;
});

اولین آرگومان ارسال شده به sometimes متد، نام فیلدی است که به صورت مشروط اعتبارسنجی می کنیم. آرگومان دوم قوانینی است که می خواهیم اضافه کنیم. اگر Closure آرگومان تصویب شده به عنوان سومین آرگومان برگردد true ، قوانین اضافه خواهند شد. این روش ساختن اعتبارسنجی های شرطی پیچیده را آسان می کند. حتی می توانید اعتبار سنجی شرطی را برای چندین فیلد به طور همزمان اضافه کنید:

$v->sometimes(['reason', 'cost'], 'required', function($input)
{
    return $input->games >= 100;
});

توجه: پارامتر $input ارسال شده به شما Closure نمونه ای از آن خواهد بود Illuminate\Support\Fluent و ممکن است به عنوان یک شی برای دسترسی به ورودی و فایل های شما استفاده شود.

پیام های خطای سفارشی

در صورت نیاز، می‌توانید از پیام‌های خطای سفارشی برای اعتبارسنجی به جای پیش‌فرض‌ها استفاده کنید. راه های مختلفی برای تعیین پیام های سفارشی وجود دارد.

ارسال پیام های سفارشی به اعتبار سنجی

$messages = [
    'required' => 'The :attribute field is required.',
];
 
$validator = Validator::make($input, $rules, $messages);

توجه: مکان :attribute نگهدار با نام واقعی فیلد تحت اعتبار سنجی جایگزین می شود. همچنین می‌توانید از سایر مکان‌دارها در پیام‌های اعتبارسنجی استفاده کنید.

سایر دارندگان مکان اعتبارسنجی

$messages = [
    'same'    => 'The :attribute and :other must match.',
    'size'    => 'The :attribute must be exactly :size.',
    'between' => 'The :attribute must be between :min - :max.',
    'in'      => 'The :attribute must be one of the following types: :values',
];

تعیین یک پیام سفارشی برای یک ویژگی مشخص

گاهی اوقات ممکن است بخواهید یک پیام خطای سفارشی را فقط برای یک فیلد خاص مشخص کنید:

$messages = [
    'email.required' => 'We need to know your e-mail address!',
];

تعیین پیام های سفارشی در فایل های زبان

در برخی موارد، ممکن است بخواهید پیام های سفارشی خود را به جای ارسال مستقیم به فایل زبان، در یک فایل زبان مشخص کنید Validator . برای انجام این کار، پیام های خود را به custom آرایه در resources/lang/xx/validation.php فایل زبان اضافه کنید.

'custom' => [
    'email' => [
        'required' => 'We need to know your e-mail address!',
    ],
],

قوانین اعتبار سنجی سفارشی

ثبت یک قانون اعتبارسنجی سفارشی

لاراول انواع مختلفی از قوانین اعتبار سنجی مفید را ارائه می دهد. با این حال، ممکن است بخواهید برخی از موارد خود را مشخص کنید. یکی از روش‌های ثبت قوانین اعتبارسنجی سفارشی استفاده از Validator::extend روش زیر است:

Validator::extend('foo', function($attribute, $value, $parameters)
{
    return $value == 'foo';
});

اعتبار سنجی سفارشی Closure سه آرگومان دریافت می کند: نام مورد $attribute تایید شده، $value صفت و آرایه ای از $parameters ارسال به قانون.

همچنین می توانید یک کلاس و متد را extend به جای Closure به متد ارسال کنید:

Validator::extend('foo', 'FooValidator@validate');

توجه داشته باشید که برای قوانین سفارشی خود نیز باید یک پیام خطا تعریف کنید. می توانید این کار را با استفاده از یک آرایه پیام سفارشی درون خطی یا با افزودن یک ورودی در فایل زبان اعتبارسنجی انجام دهید.

گسترش کلاس Validator

به جای استفاده از تماس‌های Closure برای گسترش Validator، می‌توانید خود کلاس Validator را نیز گسترش دهید. برای انجام این کار، یک کلاس Validator بنویسید که گسترش می یابد Illuminate\Validation\Validator . می توانید با قرار دادن پیشوند آنها با : متدهای اعتبارسنجی را به کلاس اضافه کنید validate :

<?php
 
class CustomValidator extends \Illuminate\Validation\Validator {
 
    public function validateFoo($attribute, $value, $parameters)
    {
        return $value == 'foo';
    }
 
}

ثبت یک حل کننده اعتبار سنجی سفارشی

در مرحله بعد، باید افزونه Validator سفارشی خود را ثبت کنید:

Validator::resolver(function($translator, $data, $rules, $messages)
{
    return new CustomValidator($translator, $data, $rules, $messages);
});

هنگام ایجاد یک قانون اعتبار سنجی سفارشی، گاهی اوقات ممکن است نیاز داشته باشید که جایگزین های نگهدارنده مکان سفارشی را برای پیام های خطا تعریف کنید. شما می توانید این کار را با ایجاد یک اعتبارسنجی سفارشی همانطور که در بالا توضیح داده شد و افزودن یک replaceXXX تابع به اعتبارسنجی انجام دهید.

protected function replaceFoo($message, $attribute, $rule, $parameters)
{
    return str_replace(':foo', $parameters[0], $message);
}

اگر می خواهید یک پیام سفارشی "replacer" را بدون گسترش Validator کلاس اضافه کنید، می توانید از Validator::replacer روش استفاده کنید:

Validator::replacer('rule', function($message, $attribute, $rule, $parameters)
{
    //
});