4

extendLaravel 4 の Validation Class にカスタムルールを拡張・追加する機能を利用しました。

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

新しく作成したカスタム拡張機能を使用してルールを検証するとvalidation.foo、ルールが失敗した場合に返されます。Laravel 4でバリデーションクラスを拡張するときにジェネリック/デフォルトメッセージを定義する方法はありますか?

4

3 に答える 3

9

Laravel 4 のドキュメントでは、カスタム ルールのエラー メッセージを定義する必要があると具体的に述べています。

2 つのオプションがあります。

オプション1：

$messages = array(
    'foo' => 'The :attribute field is foo.',
);

$validator = Validator::make($input, $rules, $messages);

オプション 2:

カスタム メッセージをバリデーターに直接渡すのではなく、言語ファイルで指定します。これを行うには、メッセージを app/lang/xx/validation.php 言語ファイルのカスタム配列に追加します。

'custom' => array(
    'foo' => array(
        'required' => 'We need to know your foo!',
    ),
),
于 2013-07-15T05:05:21.313 に答える
1

誰かが Laravel 5 について疑問に思っている場合: すべてのデフォルト メッセージのすぐ下にある validation.php にメッセージを追加してください。例えば：

<?php

return [
// .. lots of Laravel code omitted for brevity ...

"timezone"             => "The :attribute must be a valid zone.",

/* your custom global validation messages for your custom validator follow below */

"date_not_in_future"          => "Date :attribute may not be in future.",

date_not_in_futureカスタム関数はどこにありますかvalidateDateNotInFuture。Laravel は、任意のフィールドにルールを使用するたびにメッセージを選択しますcustom。特定のフィールドのグローバル メッセージをオーバーライドする場合を除き、配列を使用する必要はありません。

バリデータを実装する完全なコードは次のとおりです。

Custom Validator (date_format と date_before のローカライズに関するおまけのコメント付き):

<?php namespace App\Services\Validation;

use Illuminate\Validation\Validator as BaseValidator;

/**
 * Class for your custom validation functions
 */
class Validator extends BaseValidator  {

    public function validateDateNotInFuture($attribute, $value, $parameters)
    {
        // you could also test if the string is a date at all 
        // and if it matches your app specific format 
        // calling $this->validateDateFormat validator with your app's format 
        // loaded from \Config::get, but be careful - 
        // Laravel has hard-coded checks for DateFormat rule 
        // to extract correct format from it if it exists, 
        // and then use for validateBefore. If you have some unusual format
        // and date_format has not been applied to the field,
        // then validateBefore will give unpredictable results.
        // Your best bet then is to override protected function 
        // getDateFormat($attribute) to return your app specific format

        $tomorrow = date('your app date format here',  strtotime("tomorrow"));

        $parameters[0] = $tomorrow;
        return $this->validateBefore($attribute, $value, $parameters);
    }
}

ValidatorServiceProvider ファイル:

<?php namespace App\Providers;

namespace App\Providers;

use App\Services\Validation\Validator;
use Illuminate\Support\ServiceProvider;

class ValidatorServiceProvider extends ServiceProvider{

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

    public function register()
    {
    }
}

次に、config/app.php に次の行を追加します。

    'App\Providers\RouteServiceProvider',
    'App\Providers\ValidatorServiceProvider', // your custom validation
于 2015-05-27T19:57:33.943 に答える
0

TheShiftExchange が述べたことに加えて、validation.php 言語ファイルを見ると、指定できるさまざまなルールがすべて表示されます。たとえば、バリデータに次のようなエントリがあるとします。

class ArticleValidator extends Validator
{
    public static $rules = [
        'create'    => [
            'title'                     => ['required'],
            'slug'                      => ['required', 'regex:([a-z\0-9\-]*)']
        ]
    ];

}

次に、カスタム検証ルールは次のようになります。

'custom' => array(
    'company_article_type_id' => array(
        'required' => 'The slug field is really important',
        'exists' => 'The slug already exists',
    ),
),

カスタム検証ルールの「required」キーと「exists」キーが、上記のバリデーターのキーとどのように一致するかに注目してください。

于 2014-09-18T17:27:19.063 に答える