From df7e5400edf9678877c1595b9ee527e42590b1bf Mon Sep 17 00:00:00 2001 From: Nobuo Kihara Date: Thu, 12 Feb 2015 05:38:23 +0900 Subject: [PATCH] docs/guide-ja/input - reviewing [ci skip] --- docs/guide-ja/input-forms.md | 23 ++--- docs/guide-ja/input-validation.md | 149 +++++++++++++++--------------- 2 files changed, 87 insertions(+), 85 deletions(-) diff --git a/docs/guide-ja/input-forms.md b/docs/guide-ja/input-forms.md index 411f3e14d6..9bde657328 100644 --- a/docs/guide-ja/input-forms.md +++ b/docs/guide-ja/input-forms.md @@ -1,14 +1,14 @@ フォームを作成する ================== -Yii においてフォームを使用するための主たる方法は [[yii\widgets\ActiveForm]] によるものです。 -フォームがモデルに基づくものである場合はこの方法を優先すべきです。 -これに加えて、[[yii\helpers\Html]] にはいくつかの有用なメソッドがあり、どんなフォームでもボタンやヘルプテキストを追加するのには、通常はそれらが使われます。 +Yii においてフォームを使用するときは、主として [[yii\widgets\ActiveForm]] による方法を使います。 +フォームがモデルに基づくものである場合はこの方法を選ぶべきです。 +これに加えて、[[yii\helpers\Html]] にはいくつかの有用なメソッドがあり、どんなフォームでも、ボタンやヘルプテキストを追加するのには、通常、それらのメソッドを使います。 フォームは、クライアント側で表示されるものですが、たいていの場合、サーバ側でフォームの入力を検証するために使われる、対応する [モデル](structure-models.md) を持ちます (入力の検証の詳細については、[入力を検証する](input-validation.md) の節を参照してください)。 モデルに基づくフォームを作成する場合、最初のステップは、モデルそのものを定義することです。 -モデルは、データベースの何らかのデータを表現するために [アクティブレコード](db-active-record.md) クラスから派生させるか、あるいは、任意の入力、例えばログインフォームの入力を捕捉するために ([[yii\base\Model]] から派生させた) 汎用的な Model クラスとすることが出来ます。 +モデルは、データベースの何らかのデータを表現するために [アクティブレコード](db-active-record.md) から派生させたクラスか、あるいは、任意の入力、例えばログインフォームの入力を捕捉するために ([[yii\base\Model]] から派生させた) 汎用的な Model クラスか、どちらかにすることが出来ます。 以下の例においては、ログインフォームのために汎用的なモデルを使う方法を示します。 ```php @@ -51,15 +51,16 @@ $form = ActiveForm::begin([ ``` 上記のコードでは、[[yii\widgets\ActiveForm::begin()|ActiveForm::begin()]] がフォームのインスタンスを作成するだけでなく、フォームの開始をマークしています。 -[[yii\widgets\ActiveForm::begin()|ActiveForm::begin()]] と [[yii\widgets\ActiveForm::end()|ActiveForm::end()]] の間に置かれた全てのコンテントが `
` タグによって囲まれます。 +[[yii\widgets\ActiveForm::begin()|ActiveForm::begin()]] と [[yii\widgets\ActiveForm::end()|ActiveForm::end()]] の間に置かれた全てのコンテントが HTML の `` タグによって囲まれます。 どのウィジェットでも同じですが、ウィジェットをどのように構成すべきかに関するオプションを指定するために、`begin` メソッドに配列を渡すことが出来ます。 -この例では、追加の CSS クラスと要素を特定するための ID が渡されて、開始 `` タグに適用されています。 +この例では、追加の CSS クラスと要素を特定するための ID が渡されて、`` の開始タグに適用されています。 利用できるオプションはすべて [[yii\widgets\ActiveForm]] の API ドキュメントに記されていますので参照してください。 -フォームの中では、フォームの要素を作成し、それと一緒に要素のラベルと、そして、適用できる JavaScript の検証メソッドがあれば、それも追加するために、ActiveForm ウィジェットの [[yii\widgets\ActiveForm::field()|ActiveForm::field()]] メソッドが呼ばれています。 -このメソッドは、[[yii\widgets\ActiveField]] のインスタンスを返します。 +フォームの中では、フォームの要素を作成するために、ActiveForm ウィジェットの [[yii\widgets\ActiveForm::field()|ActiveForm::field()]] メソッドが呼ばれています。 +これは、フォームの要素だけでなく、そのラベルも作成し、適用できる JavaScript の検証メソッドがあれば、それも追加します。 +[[yii\widgets\ActiveForm::field()|ActiveForm::field()]] メソッドは、[[yii\widgets\ActiveField]] のインスタンスを返します。 このメソッドの呼び出し結果を直接にエコーすると、結果は通常の (text の) インプットになります。 -出力結果をカスタマイズするためには、このメソッドの呼び出しに追加の [[yii\widgets\ActiveField|ActiveField]] のメソッドをチェーンします。 +このメソッドの呼び出しに追加の [[yii\widgets\ActiveField|ActiveField]] のメソッドをチェーンして、出力結果をカスタマイズすることが出来ます。 ```php // パスワードのインプット @@ -76,7 +77,7 @@ $form = ActiveForm::begin([ この命名規則の結果として、ログインフォームの全ての属性が配列として、サーバ側においては `$_POST['LoginForm']` に格納されて利用できることになります。 モデルの属性を指定するために、もっと洗練された方法を使うことも出来ます。 -例えば、複数のファイルをアップロードしたり、複数の項目を選択したりする場合に、属性の名前に `[]` を付けて、属性が配列の値を取ることが出来ることを指定することが出来ます。 +例えば、複数のファイルをアップロードしたり、複数の項目を選択したりする場合に、属性の名前に `[]` を付けて、属性が配列の値を取り得ることを指定することが出来ます。 ```php // 複数のファイルのアップロードを許可する @@ -89,7 +90,7 @@ echo $form->field($model, 'items[]')->checkboxList(['a' => 'Item A', 'b' => 'Ite フォームに HTML タグを追加するためには、素の HTML を使うか、または、上記の例の [[yii\helpers\Html::submitButton()|Html::submitButton()]] のように、[[yii\helpers\Html|Html]] ヘルパクラスのメソッドを使うことが出来ます。 > Tip|ヒント: あなたのアプリケーションで Twitter Bootstrap CSS を使っている場合は、[[yii\widgets\ActiveForm]] の代りに [[yii\bootstrap\ActiveForm]] を使うのが良いでしょう。 -> これは ActiveForm クラスのエクステンションであり、bootstrap CSS フレームワークで使用するための追加のスタイルをサポートしています。 +> これは ActiveForm クラスの拡張であり、bootstrap CSS フレームワークで使用するための追加のスタイルをサポートしています。 > tip|ヒント: 必須フィールドをアスタリスク付きのスタイルにするために、次の CSS を使うことが出来ます。 > diff --git a/docs/guide-ja/input-validation.md b/docs/guide-ja/input-validation.md index 2eef6265e7..bb27c84b98 100644 --- a/docs/guide-ja/input-validation.md +++ b/docs/guide-ja/input-validation.md @@ -1,11 +1,11 @@ 入力を検証する ============== -大まかに言うなら、エンドユーザから受信したデータは決して信用せず、利用する前に検証しなければならない、ということです。 +経験則として言えることは、エンドユーザから受信したデータは決して信用せず、利用する前に検証しなければならない、ということです。 [モデル](structure-models.md) にユーザの入力が投入されたら、モデルの [[yii\base\Model::validate()]] メソッドを呼んで入力を検証することが出来ます。 -このメソッドはバリデーションが成功したか否かを示す真偽値を返します。 -バリデーションが失敗した場合は、[[yii\base\Model::errors]] プロパティからエラーメッセージを取得することが出来ます。 +このメソッドは検証が成功したか否かを示す真偽値を返します。 +検証が失敗した場合は、[[yii\base\Model::errors]] プロパティからエラーメッセージを取得することが出来ます。 例えば、 ```php @@ -17,16 +17,16 @@ $model->attributes = \Yii::$app->request->post('ContactForm'); if ($model->validate()) { // 全ての入力が有効 } else { - // バリデーションが失敗。$errors はエラーメッセージを含む配列 + // 検証が失敗。$errors はエラーメッセージを含む配列 $errors = $model->errors; } ``` ## 規則を宣言する -`validate()` を現実に動作させるためには、検証する予定の属性に対してバリデーション規則を宣言しなければなりません。 +`validate()` を現実に動作させるためには、検証する予定の属性に対して検証規則を宣言しなければなりません。 規則は [[yii\base\Model::rules()]] メソッドをオーバーライドすることで宣言します。 -次の例は、`ContactForm` モデルに対してバリデーション規則を宣言する方法を示すものです。 +次の例は、`ContactForm` モデルに対して検証規則を宣言する方法を示すものです。 ```php public function rules() @@ -56,7 +56,7 @@ public function rules() // オプション。この規則が適用されるべき一つまたは複数のシナリオを指定する。 // 指定しない場合は、この規則が全てのシナリオに適用されることを意味する。 // "except" オプションを構成して、列挙したシナリオを除く全てのシナリオに - // この規則が適用されるべきことを指定することも出来る。 + // この規則が適用されるべきことを指定してもよい。 'on' => ['シナリオ1', 'シナリオ2', ...], // オプション。バリデータオブジェクトに対する追加の構成情報を指定する。 @@ -77,21 +77,21 @@ public function rules() `on` オプションを指定することで、規則を特定の [シナリオ](structure-models.md#scenarios) においてのみ適用することが出来ます。 `on` オプションを指定しない場合は、規則が全てのシナリオに適用されることになります。 -`validate()` メソッドが呼ばれると、次のステップを踏んでバリデーションが実行されます。 +`validate()` メソッドが呼ばれると、次のステップを踏んで検証が実行されます。 1. 現在の [[yii\base\Model::scenario|シナリオ]] を使って [[yii\base\Model::scenarios()]] から属性のリストを取得し、どの属性が検証されるべきかを決定します。 検証されるべき属性が *アクティブな属性* と呼ばれます。 -2. 現在の [[yii\base\Model::scenario|シナリオ]] を使って [[yii\base\Model::rules()]] から規則のリストを取得し、どのバリデーション規則が使用されるべきかを決定します。 +2. 現在の [[yii\base\Model::scenario|シナリオ]] を使って [[yii\base\Model::rules()]] から規則のリストを取得し、どの検証規則が使用されるべきかを決定します。 使用されるべき規則が *アクティブな規則* と呼ばれます。 3. 全てのアクティブな規則を一つずつ使って、その規則に関連付けられた全てのアクティブな属性を一つずつ検証します。 - バリデーション規則はリストに挙げられている順に評価されます。 + 検証規則はリストに挙げられている順に評価されます。 -属性は、上記のバリデーションのステップに従って、`scenarios()` でアクティブな属性であると宣言されており、かつ、`rules()` で宣言された一つまたは複数のアクティブな規則と関連付けられている場合に、また、その場合に限って、検証されます。 +属性は、上記の検証のステップに従って、`scenarios()` でアクティブな属性であると宣言されており、かつ、`rules()` で宣言された一つまたは複数のアクティブな規則と関連付けられている場合に、また、その場合に限って、検証されます。 ### エラーメッセージをカスタマイズする -たいていのバリデータはデフォルトのエラーメッセージを持っていて、属性のバリデーションが失敗した場合にそれを検証の対象であるモデルに追加します。 +たいていのバリデータはデフォルトのエラーメッセージを持っていて、属性の検証が失敗した場合にそれを検証の対象であるモデルに追加します。 例えば、[[yii\validators\RequiredValidator|required]] バリデータは、このバリデータを使って `username` 属性を検証したとき、規則に合致しない場合は「ユーザ名は空ではいけません。」というエラーメッセージをモデルに追加します。 規則のエラーメッセージは、次に示すように、規則を宣言するときに `message` プロパティを指定することによってカスタマイズすることが出来ます。 @@ -105,25 +105,25 @@ public function rules() } ``` -バリデータの中には、バリデーションを失敗させたさまざまな原因をより詳しく説明するための追加のエラーメッセージをサポートしているものがあります。 -例えば、[[yii\validators\NumberValidator|number]] バリデータは、検証される値が大きすぎたり小さすぎたりしたときにバリデーションの失敗を説明するために、それぞれ、[[yii\validators\NumberValidator::tooBig|tooBig]] および [[yii\validators\NumberValidator::tooSmall|tooSmall]] のメッセージをサポートしています。 -これらのエラーメッセージも、バリデータの他のプロパティと同様、バリデーション規則の中で構成することが出来ます。 +バリデータの中には、検証を失敗させたさまざまな原因をより詳しく説明するための追加のエラーメッセージをサポートしているものがあります。 +例えば、[[yii\validators\NumberValidator|number]] バリデータは、検証される値が大きすぎたり小さすぎたりしたときに、検証の失敗を説明するために、それぞれ、[[yii\validators\NumberValidator::tooBig|tooBig]] および [[yii\validators\NumberValidator::tooSmall|tooSmall]] のメッセージをサポートしています。 +これらのエラーメッセージも、バリデータの他のプロパティと同様、検証規則の中で構成することが出来ます。 -### バリデーションのイベント +### 検証のイベント -[[yii\base\Model::validate()]] は、呼び出されると、バリデーションプロセスをカスタマイズするためにオーバーライドできる二つのメソッドを呼び出します。 +[[yii\base\Model::validate()]] は、呼び出されると、検証のプロセスをカスタマイズするためにオーバーライドできる二つのメソッドを呼び出します。 * [[yii\base\Model::beforeValidate()]]: デフォルトの実装は [[yii\base\Model::EVENT_BEFORE_VALIDATE]] イベントをトリガするものです。 - このメソッドをオーバーライドするか、または、イベントに反応して、バリデーションが実行される前に、何らかの前処理 (例えば入力されたデータの正規化) をすることが出来ます。 - このメソッドは、バリデーションを続行すべきか否かを示す真偽値を返さなくてはなりません。 + このメソッドをオーバーライドするか、または、イベントに反応して、検証が実行される前に、何らかの前処理 (例えば入力されたデータの正規化) をすることが出来ます。 + このメソッドは、検証を続行すべきか否かを示す真偽値を返さなくてはなりません。 * [[yii\base\Model::afterValidate()]]: デフォルトの実装は [[yii\base\Model::EVENT_AFTER_VALIDATE]] イベントをトリガするものです。 - このメソッドをオーバーライドするか、または、イベントに反応して、バリデーションが完了した後に、何らかの後処理をすることが出来ます。 + このメソッドをオーバーライドするか、または、イベントに反応して、検証が完了した後に、何らかの後処理をすることが出来ます。 -### 条件付きバリデーション +### 条件付きの検証 -特定の条件が満たされる場合に限って属性を検証したい場合、例えば、ある属性のバリデーションが他の属性の値に依存する場合には、[[yii\validators\Validator::when|when]] プロパティを使って、そのような条件を定義することが出来ます。 +特定の条件が満たされる場合に限って属性を検証したい場合、例えば、ある属性の検証が他の属性の値に依存する場合には、[[yii\validators\Validator::when|when]] プロパティを使って、そのような条件を定義することが出来ます。 例えば、 ```php @@ -145,7 +145,7 @@ public function rules() function ($model, $attribute) ``` -クライアント側でも条件付きバリデーションをサポートする必要がある場合は、[[yii\validators\Validator::whenClient|whenClient]] プロパティを構成しなければなりません。 +クライアント側でも条件付きの検証をサポートする必要がある場合は、[[yii\validators\Validator::whenClient|whenClient]] プロパティを構成しなければなりません。 このプロパティは、規則を適用すべきか否かを返す JavaScript 関数を表す文字列を値として取ります。 例えば、 @@ -164,7 +164,7 @@ function ($model, $attribute) ユーザ入力をフィルタまたは前処理する必要があることがよくあります。 例えば、`username` の入力値の前後にある空白を除去したいというような場合です。 -この目的を達するためにバリデーション規則を使うことが出来ます。 +この目的を達するために検証規則を使うことが出来ます。 次の例では、入力値の前後にある空白を除去して、空の入力値を null に変換することを、[trim](tutorial-core-validators.md#trim) および [default](tutorial-core-validators.md#default) のコアバリデータで行っています。 @@ -176,7 +176,8 @@ function ($model, $attribute) ``` もっと汎用的な [filter](tutorial-core-validators.md#filter) バリデータを使って、もっと複雑なデータフィルタリングをすることも出来ます。 -お分かりかと思いますが、これらのバリデーション規則は実際には入力を検証しません。そうではなくて、検証される属性の値を処理して書き戻すのです。 + +お分かりのように、これらの検証規則は実際には入力を検証しません。そうではなくて、検証される属性の値を処理して書き戻すのです。 ### 空の入力値を扱う @@ -208,15 +209,15 @@ HTML フォームから入力データが送信されたとき、入力値が空 ``` > Note|注意: たいていのバリデータは、[[yii\base\Validator::skipOnEmpty]] プロパティがデフォルト値 `true` を取っている場合は、空の入力値を処理しません。 - そのようなバリデータは、関連付けられた属性が空の入力値を受け取ったときは、バリデーションの過程ではスキップされるだけになります。 + そのようなバリデータは、関連付けられた属性が空の入力値を受け取ったときは、検証の過程ではスキップされるだけになります。 [コアバリデータ](tutorial-core-validators.md) の中では、`captcha`、`default`、`filter`、`required`、そして `trim` だけが空の入力値を処理します。 -## アドホックなバリデーション +## その場限りの検証 -時として、何らかのモデルに結び付けられていない値に対する *アドホックなバリデーション* を実行しなければならない場合があります。 +時として、何らかのモデルに結び付けられていない値に対する *その場限りの検証* を実行しなければならない場合があります。 -実行する必要があるバリデーションが一種類 (例えば、メールアドレスの検証) だけである場合は、使いたいバリデータの [[yii\validators\Validator::validate()|validate()]] メソッドを次のように呼び出すことが出来ます。 +実行する必要がある検証が一種類 (例えば、メールアドレスの検証) だけである場合は、使いたいバリデータの [[yii\validators\Validator::validate()|validate()]] メソッドを次のように呼び出すことが出来ます。 ```php $email = 'test@example.com'; @@ -229,10 +230,10 @@ if ($validator->validate($email, $error)) { } ``` -> Note|注意: 全てのバリデータがこの種のバリデーションをサポートしている訳ではありません。 - その一例が [unique](tutorial-core-validators.md#unique) コアバリデータであり、これはモデルとともに使用されることだけを念頭にして設計されています。 +> Note|注意: 全てのバリデータがこの種の検証をサポートしている訳ではありません。 + その一例が [unique](tutorial-core-validators.md#unique) コアバリデータであり、これはモデルとともに使用されることだけを前提にして設計されています。 -いくつかの値に対して複数のバリデーションを実行する必要がある場合は、属性と規則の両方をその場で宣言することが出来る [[yii\base\DynamicModel]] を使うことが出来ます。 +いくつかの値に対して複数の検証を実行する必要がある場合は、属性と規則の両方をその場で宣言することが出来る [[yii\base\DynamicModel]] を使うことが出来ます。 これは、次のような使い方をします。 ```php @@ -244,16 +245,16 @@ public function actionSearch($name, $email) ]); if ($model->hasErrors()) { - // バリデーションが失敗 + // 検証が失敗 } else { - // バリデーションが成功 + // 検証が成功 } } ``` [[yii\base\DynamicModel::validateData()]] メソッドは `DynamicModel` のインスタンスを作成し、与えられた値 (この例では `name` と `email`) を使って属性を定義し、そして、与えられた規則で [[yii\base\Model::validate()]] を呼び出します。 -別の選択肢として、次のように、もっと「クラシック」な構文を使って、アドホックなデータバリデーションを実行することも出来ます。 +別の選択肢として、次のように、もっと「クラシック」な構文を使って、その場限りのデータ検証を実行することも出来ます。 ```php public function actionSearch($name, $email) @@ -264,14 +265,14 @@ public function actionSearch($name, $email) ->validate(); if ($model->hasErrors()) { - // バリデーションが失敗 + // 検証が失敗 } else { - // バリデーションが成功 + // 検証が成功 } } ``` -検証を実行した後は、通常のモデルで行うのと同様に、バリデーションが成功したか否かを [[yii\base\DynamicModel::hasErrors()|hasErrors()]] メソッドを呼んでチェックして、[[yii\base\DynamicModel::errors|errors]] プロパティからバリデーションエラーを取得することが出来ます。 +検証を実行した後は、通常のモデルで行うのと同様に、検証が成功したか否かを [[yii\base\DynamicModel::hasErrors()|hasErrors()]] メソッドを呼んでチェックして、[[yii\base\DynamicModel::errors|errors]] プロパティから検証エラーを取得することが出来ます。 また、このモデルのインスタンスによって定義された動的な属性に対しても、例えば `$model->name` や `$model->email` のようにして、アクセスすることが出来ます。 @@ -294,7 +295,7 @@ Yii のリリースに含まれている [コアバリデータ](tutorial-core-v function ($attribute, $params) ``` -属性がバリデーションに失敗した場合は、メソッド/関数 は [[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存し、後で読み出してエンドユーザに示ことが出来るようにしなければなりません。 +属性が検証に失敗した場合は、メソッド/関数 は [[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存し、後で読み出してエンドユーザに表示することが出来るようにしなければなりません。 下記にいくつかの例を示します。 @@ -330,7 +331,7 @@ class MyForm extends Model } ``` -> Note|注意: デフォルトでは、インラインバリデータは、関連付けられている属性が空の入力値を受け取ったり、既に何らかのバリデーション規則に失敗したりしている場合には、適用されません。 +> Note|注意: デフォルトでは、インラインバリデータは、関連付けられている属性が空の入力値を受け取ったり、既に何らかの検証規則に失敗したりしている場合には、適用されません。 > 規則が常に適用されることを保証したい場合は、規則の宣言において [[yii\validators\Validator::skipOnEmpty|skipOnEmpty]] および/または [[yii\validators\Validator::skipOnError|skipOnError]] のプロパティを false に設定することが出来ます。 > 例えば、 > @@ -345,7 +346,7 @@ class MyForm extends Model スタンドアロンバリデータは、[[yii\validators\Validator]] またはその子クラスを拡張するクラスです。 [[yii\validators\Validator::validateAttribute()]] メソッドをオーバーライドすることによって、その検証ロジックを実装することが出来ます。 -[インラインバリデータ](#inline-validators) でするのと同じように、属性がバリデーションに失敗した場合は、[[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存します。 +[インラインバリデータ](#inline-validators) でするのと同じように、属性が検証に失敗した場合は、[[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存します。 例えば、 ```php @@ -365,26 +366,26 @@ class CountryValidator extends Validator ``` -あなたのバリデータで、モデル無しの値のバリデーションをサポートしたい場合は、[[yii\validators\Validator::validate()]] もオーバーライドしなければなりません。 +あなたのバリデータで、モデル無しの値の検証をサポートしたい場合は、[[yii\validators\Validator::validate()]] もオーバーライドしなければなりません。 または、`validateAttribute()` と `validate()` の代りに、[[yii\validators\Validator::validateValue()]] をオーバーライドしても構いません。 と言うのは、前の二つは、デフォルトでは、`validateValue()` を呼び出すことによって実装されているからです。 -## クライアント側でのバリデーション +## クライアント側での検証 -エンドユーザが HTML フォームで値を入力する際には、JavaScript に基づくクライアント側でのバリデーションを提供することが望まれます。 -というのは、クライアント側でのバリデーションは、ユーザが入力のエラーを早く見つけることが出来るようにすることによって、より良いユーザ体験を提供するものだからです。 -あなたも、サーバ側でのバリデーション *に加えて* クライアント側でのバリデーションをサポートするバリデータを使用したり実装したりすることが出来ます。 +エンドユーザが HTML フォームで値を入力する際には、JavaScript に基づくクライアント側での検証を提供することが望まれます。 +というのは、クライアント側での検証は、ユーザが入力のエラーを早く見つけることが出来るようにすることによって、より良いユーザ体験を提供するものだからです。 +あなたも、サーバ側での検証 *に加えて* クライアント側での検証をサポートするバリデータを使用したり実装したりすることが出来ます。 -> Info|情報: クライアント側でのバリデーションは望ましいものですが、不可欠なものではありません。 +> Info|情報: クライアント側での検証は望ましいものですが、不可欠なものではありません。 その主たる目的は、ユーザにより良い体験を提供することにあります。 - エンドユーザから来る入力値と同じように、クライアント側でのバリデーションを決して信用してはいけません。 - この理由により、これまでの項で説明したように、常に [[yii\base\Model::validate()]] を呼び出してサーバ側でのバリデーションを実行しなければなりません。 + エンドユーザから来る入力値と同じように、クライアント側での検証を決して信用してはいけません。 + この理由により、これまでの項で説明したように、常に [[yii\base\Model::validate()]] を呼び出してサーバ側での検証を実行しなければなりません。 -### クライアント側でのバリデーションを使う +### クライアント側での検証を使う -多くの [コアバリデータ](tutorial-core-validators.md) は、そのままで、クライアント側でのバリデーションをサポートしています。 +多くの [コアバリデータ](tutorial-core-validators.md) は、そのままで、クライアント側での検証をサポートしています。 あなたがする必要があるのは、[[yii\widgets\ActiveForm]] を使って HTML フォームを作るということだけです。 例えば、下の `LoginForm` は二つの規則を宣言しています。 一つは、[required](tutorial-core-validators.md#required) コアバリデータを使っていますが、これはクライアント側とサーバ側の両方でサポートされています。 @@ -434,16 +435,16 @@ class LoginForm extends Model ``` -舞台裏では、[[yii\widgets\ActiveForm]] がモデルで宣言されているバリデーション規則を読んで、クライアント側のバリデーションをサポートするバリデータのために適切な JavaScript コードを生成します。 -ユーザが入力フィールドの値を変更したりフォームを送信したりすると、クライアント側バリデーションの JavaScript が起動されます。 +舞台裏では、[[yii\widgets\ActiveForm]] がモデルで宣言されている検証規則を読んで、クライアント側の検証をサポートするバリデータのために、適切な JavaScript コードを生成します。 +ユーザが入力フィールドの値を変更したりフォームを送信したりすると、クライアント側の検証の JavaScript が起動されます。 -クライアント側のバリデーションを完全に無効にしたい場合は、[[yii\widgets\ActiveForm::enableClientValidation]] プロパティを false に設定することが出来ます。 -また、個々の入力フィールドごとにクライアント側のバリデーションを無効にしたい場合は、入力フィールドの [[yii\widgets\ActiveField::enableClientValidation]] プロパティを false に設定することも出来ます。 +クライアント側の検証を完全に無効にしたい場合は、[[yii\widgets\ActiveForm::enableClientValidation]] プロパティを false に設定することが出来ます。 +また、個々の入力フィールドごとにクライアント側の検証を無効にしたい場合には、入力フィールドの [[yii\widgets\ActiveField::enableClientValidation]] プロパティを false に設定することが出来ます。 -### クライアント側バリデーションを実装する +### クライアント側の検証を実装する -クライアント側バリデーションをサポートするバリデータを作成するためには、クライアント側でのバリデーションを実行する JavaScript コードを返す [[yii\validators\Validator::clientValidateAttribute()]] メソッドを実装しなければなりません。 +クライアント側の検証をサポートするバリデータを作成するためには、クライアント側での検証を実行する JavaScript コードを返す [[yii\validators\Validator::clientValidateAttribute()]] メソッドを実装しなければなりません。 その JavaScript の中では、次の事前定義された変数を使用することが出来ます。 - `attribute`: 検証される属性の名前。 @@ -451,8 +452,8 @@ class LoginForm extends Model - `messages`: 属性に対する検証のエラーメッセージを保持するために使用される配列。 - `deferred`: Deferred オブジェクトをプッシュして入れることが出来る配列 (次の項で説明します)。 -次の例では、既存のステータスのデータに含まれる有効な値が入力されたかどうかを検証する `StatusValidator` を作成します。 -このバリデータは、サーバ側とクライアント側の両方のバリデーションをサポートします。 +次の例では、入力された値が既存のステータスのデータに含まれる有効な値であるかどうかを検証する `StatusValidator` を作成します。 +このバリデータは、サーバ側とクライアント側の両方の検証をサポートします。 ```php namespace app\components; @@ -489,9 +490,9 @@ JS; } ``` -> Tip|ヒント: 上記のコード例の主たる目的は、クライアント側バリデーションをサポートする方法を説明することにあります。 +> Tip|ヒント: 上記のコード例の主たる目的は、クライアント側の検証をサポートする方法を説明することにあります。 > 実際の仕事では、[in](tutorial-core-validators.md#in) コアバリデータを使って、同じ目的を達することが出来ます。 -> 次のようにバリデーション規則を書けばよいのです。 +> 次のように検証規則を書けばよいのです。 > > ```php > [ @@ -499,10 +500,10 @@ JS; > ] > ``` -### Deferred バリデーション +### Deferred 検証 -非同期のクライアント側バリデーションをサポートする必要がある場合は、[Defered オブジェクト](http://api.jquery.com/category/deferred-object/) を作成することが出来ます。 -例えば、AJAX によるカスタムバリデーションを実行するために、次のコードを使うことが出来ます。 +非同期のクライアント側の検証をサポートする必要がある場合は、[Defered オブジェクト](http://api.jquery.com/category/deferred-object/) を作成することが出来ます。 +例えば、AJAX によるカスタム検証を実行するために、次のコードを使うことが出来ます。 ```php public function clientValidateAttribute($model, $attribute, $view) @@ -547,7 +548,7 @@ JS; ``` > Note|注意: 属性が検証された後に、`resolve()` メソッドを呼び出さなければなりません。 - そうしないと、主たるフォームのバリデーションが完了しません。 + そうしないと、主たるフォームの検証が完了しません。 簡潔に記述できるように、`deferred` 配列はショートカットメソッド `add()` を装備しており、このメソッドを使うと、自動的に Deferred オブジェクトを作成して `deferred` 配列に追加することが出来ます。 このメソッドを使えば、上記の例は次のように簡潔に記すことが出来ます。 @@ -575,14 +576,14 @@ JS; ``` -### AJAX バリデーション +### AJAX 検証 場合によっては、サーバだけが必要な情報を持っているために、サーバ側でしか検証が実行できないことがあります。 例えば、ユーザ名がユニークであるか否かを検証するためには、サーバ側で user テーブルを調べることが必要になります。 -このような場合には、AJAX ベースのバリデーションを使うことが出来ます。 -AJAX バリデーションは、通常のクライアント側でのバリデーションと同じユーザ体験を保ちながら、入力値を検証するためにバックグラウンドで AJAX リクエストを発行します。 +このような場合には、AJAX ベースの検証を使うことが出来ます。 +AJAX 検証は、通常のクライアント側での検証と同じユーザ体験を保ちながら、入力値を検証するためにバックグラウンドで AJAX リクエストを発行します。 -AJAX バリデーションをフォーム全体に対して有効にするためには、[[yii\widgets\ActiveForm::enableAjaxValidation]] プロパティを `true` に設定して、`id` にフォームを特定するユニークな ID を設定しなければなりません。 +AJAX 検証をフォーム全体に対して有効にするためには、[[yii\widgets\ActiveForm::enableAjaxValidation]] プロパティを `true` に設定して、`id` にフォームを特定するユニークな ID を設定しなければなりません。 ```php ``` -個別の入力フィールドについても、[[yii\widgets\ActiveField::enableAjaxValidation]] プロパティを設定して、AJAX バリデーションを有効にしたり無効にしたりすることが出来ます。 +個別の入力フィールドについても、[[yii\widgets\ActiveField::enableAjaxValidation]] プロパティを設定して、AJAX 検証を有効にしたり無効にしたりすることが出来ます。 -また、サーバ側では、AJAX バリデーションのリクエストを処理できるように準備しておく必要があります。 +また、サーバ側では、AJAX 検証のリクエストを処理できるように準備しておく必要があります。 これは、コントローラのアクションにおいて、次のようなコード断片を使用することで達成できます。 ```php @@ -604,7 +605,7 @@ if (Yii::$app->request->isAjax && $model->load(Yii::$app->request->post())) { ``` 上記のコードは、現在のリクエストが AJAX であるかどうかをチェックします。 -もし AJAX であるなら、リクエストに応えてバリデーションを実行し、エラーを JSON 形式で返します。 +もし AJAX であるなら、リクエストに応えて検証を実行し、エラーを JSON 形式で返します。 -> Info|情報: AJAX バリデーションを実行するためには、[Deferred バリデーション](#deferred-validation) を使うことも出来ます。 - しかし、ここで説明された AJAX バリデーションの機能の方がより体系化されており、コーディングの労力も少なくて済みます。 +> Info|情報: AJAX 検証を実行するためには、[Deferred 検証](#deferred-validation) を使うことも出来ます。 + しかし、ここで説明された AJAX 検証の機能の方がより体系化されており、コーディングの労力も少なくて済みます。