| layout | title |
|---|---|
default |
フォーム情報を整理して入力値チェックも追加しよう |
-
前章で作成した、フォーム定義の内容を、FormTypeに切り分けます。
-
目的としては、フォームの定義が一箇所に集まっているとメンテナンスが容易になるからです。
-
EC-CUBE 3でフォームを作成する際は、通常本章の方法を用います。
-
本章では以下を行います。
-
FormTypeファイルの作成します。
-
バリデーションの定義方法を説明します。
-
FormTypeをコントローラーから利用するために、サービスプロバイダへの登録方法を説明します。
-
コントローラーメソッドにRequestを渡す方法を説明します。
-
ビルダーからFormTypeファイルを用い、フォームオブジェクトを作成する方法を説明します。
-
Requestとフォームオブジェクトの連携を説明します。
-
バリデーションの判定方法を説明します。
-
バリデーション機構の簡単な説明を行います。
-
Twigファイルの修正します。
-
Twigファイルでの判定方法を説明します。
-
Twigファイルの判定による表示内容の変更方法を説明します。
-
- 以下にFormTypeが保存されています。
- /src/Eccube/Form/Type/Front
- 「Type」フォルダまでは、「管理画面」「ユーザー画面」共通です
- 管理画面 : Admin
- ユーザー画面 : Front
- 「Type」フォルダまでは、「管理画面」「ユーザー画面」共通です
-
次にCrudType.phpを作成します。
-
ContactType.phpをコピー、リネームします。
- CrudType.php( 中身はContactType.phpのコピー )
- 上記を以下に変更します。
- 上記でコントローラーに記述していた、フォーム構成を「FormType」へ転記を行いました。
-
上記でFormTypeを作成しましたが、ここで、フォームの各項目の入力値チェック(以後、バリデーションと呼びます)を定義していきます。
-
作成した「CrudType」の各項目のオプション欄に追記していきます。
- CrudType.php
- 上記で記述した通り、バリデーションは以下構文で追加します。
- Symfony2のサイトで確認してください。
- 上記ソース内のフォームビルダーの最後に以下が定義されています。
->addEventSubscriber(new \Eccube\Event\FormEventSubscriber());
- 上記はフォームの処理に対して割り込むイベントを定義していますが、慣例的なものとして、記述を削除しないでくだい。
- 通常は利用の必要がないため、ここでの説明は割愛させていただきます。
- FormTypeの定義が完了したら、コントローラー内「$app」で呼び出せる様に、サービスプロバイダーへの登録が必要です。
-
以下にServiceProviderが保存されています。
-
/src/Eccube/ServiceProvider
-
フォルダの中のEccubeServiceProvider.phpが該当ファイルです。
-
今回はユーザー画面(フロント画面)に関する「FormType」です。そのために、ファイルを開いたら「front」を検索してください。
-
「front」を検索すると、ユーザー画面に関する、「Type定義」がまとまっているはずですので、その最下部に以下の様に、作成した「CrudType」の定義を行いましょう。
- EccubeServiceProvider.php
-
-
- 今回は必要ありませんが、引数にコンフィグ情報を渡しています。
-
次はコントローラーに記述していた、Form項目の設定を削除し、CrudTypeの読み込みを記述していきます。
-
まずcreateBuilderでビルダーを生成している箇所から、Form定義部を全て削除します。
-
以下の通りになります。
- CrudController.php
-
次はコントローラーに「FormType」の呼び出しと、サブミットされた値に対して、入力値チェックを行います。
-
コントローラーに以下を追加します。
-
上記内容の説明を行います
- まずはじめに、リクエストを受け取るために「名前空間」とメソッドの引数を設定します。
- 名前空間に「Silex(Symfony2)」のリクエストクラスの読み込み宣言を行います。
- メソッドの引数に、タイプヒンティングを設定、Request型を指定し、リクエストオブジェクトを受け取れるようにします。
- リクエストオブジェクトは「Silex(Symfony2)」が自動で処理を行い、クライアントからのリクエスト内容を渡してくれます。
- 次にフォーム生成のために、$app[form.factory]のcreateBuilderメソッドでフォームオブジェクトを生成します。
- CrudTypeのgetNameメソッドで定義した、FormType名称crudをcreateBuilderの第一引数として渡します。
- 第二引数には、今回は関連エンティティがないため「null」を指定します。
- オプションは指定しません。
- 次にhandleRequestで取得したリクエストオブジェクトとFormTypeを関連付けます。
- 厳密にはサブミット値とFormType値の突き合わせが行われています。
-
次に入力値チェックですが、以下の様に記述しているかと思います。
if ($form->isSubmitted() && $form->isValid()) {
-
以下入力値チェックの説明です。
-
まず「isSubmitted」でFormからサブミットされた値かどうかチェックしています。
- セキュリティのためです
-
次に「isValid」でFormTypeの内容に基づき、入力値チェックを行います。
- 入力値に問題がなければ、trueを、内容に問題あればfalseが返却されます。
- またフォームオブジェクト内で、エラーがあった項目と、それに対して設定されていたエラーメッセージも格納されているため、ビューの設定でエラーメッセージが表示されます。
- ※ただし、バリデーションエラーが保持されるためには、エンティティが必要ですが、本章では、エンティティを保持していないため、ビューで自動でエラーが表示されるわけではありません。そのため今回は、コントローラーで判定し、判定に応じたメッセージをビューに渡しています。
-
最後にTwigファイルを修正しましょう
-
crud_top.twig
-
現状では以下表示となります。
-
- コントローラーの修正にあわせて以下の様に追記、変更を行います。
-
上記の説明を行います。
-
Twigでのif文
- メッセージ表示箇所で、変数の有無を判定しています。
- if [変数] is definedがそうですが、この記述中のdefinedはPHPのissetと同義です。
- Twigの**ロジック部は{%%}**で囲っています。
- 条件により、表示されるタグが異なります。
-
フォームの追加
- 次にhtmlのフォームを定義します。
- action属性以外は通常のフォーム定義と同様です。
- action属性に記載されているのが、Twig構文でurl([ルーティング名])、指定したURLを取得できます。
- ここで云うルーティング名とはFrontControllerProviderでルーティングの設定を行なった際に、bind()に設定した値です。
-
-
最後に確認のためにブラウザにアクセスしてみましょう。
-
ブラウザのURLに「http://[ドメイン + インストールディレクトリ]/tutorial/crud」を入力してください。
-
フォームビルダーで構築したフォームが表示されています。
-
-
入力値が正常な場合の表示を確認します。
-
投稿ハンドルネームに「a」、投稿のタイトルに「a」を入力
-
この内容で登録するをクリック
-
-
入力値にエラーがある場合の表示を確認します。
-
投稿ハンドルネームに「あ」、投稿のタイトルに「あ」を入力
-
この内容で登録するをクリック
-
- コントローラーに記述された、Form定義情報をFormTypeに移設しました。
- FormTypeで、バリデーションを設定しました。
- サービスプロバイダに作成したFormTypeを登録しました。
- Twigにformを記述する際、「action」で「url構文」を利用しルーティング名により「URL」の取得を行いました。
- $app['form.factory']の「createBuilder」の第一引数にフォームタイプ名を記述し、フォーム定義を取得しました。
- フォーム定義をフォームオブジェクトへ変換した後に、リクエストオブジェクトに紐付けしました。
- コントローラーのメソッドからリクエストオブジェクトを取得しました。
- リクエストがサブミット値か、さらに入力値に異常がないかの判定を行いました。
- 取得結果で、表示文言がかわるように、Twigで「if文」を用いました。
- Twigの構文「defined」を利用して、変数の有無を判定しました。


