SymfonyのForm

SymfonyのForm

用語や構造が複雑すぎる

最初に読むと流れが掴めて良いかも

3行俯瞰

FormObjectを定義するもの

formの実装方法は2つあるが基本的にはFormTypeを使う

Symfonyの仕組み上formを作るときに必要なObject

ここでfieldの定義, Entityとのmapping, validationの記述などをする

defaultで用意されているfieldとして使うFormTypes

既存のFormTypeを外部から拡張したいときに使う

FormTypeが継承するclass

userがfieldに入力した値を、別の形式に変換したいときに使う

「データがセットされたとき」「submitしたとき」とかに実行したい処理を記述する

validationを書く方法について。

addの連鎖などを書く

builderからcreateFormしてform objectを作る

このタイミングでsubmit処理も書くの？

form objectをViewに返却する

Viewはそのform objectを使って、フォームを構築する

ここも何種類かある

1行で全ての要素を表示する

個別の要素を1つ1つ表示する

form_startを使ったり、使わなかったり

etc.

submitのための処理も複数個ある

Docsに書いている方法

formを表示する処理と、submitされたものを扱う処理を同じ1つのactionに書く

Controllerで別途request先を作る方法

なんとなくこっちのほうが良い気がしている

formタグ

nameとacitonはどう指定する？

Controlllerとの関係

table:a

Controllerのannotation formタグの属性

name action内のurl('')

Validation Rule

Entityのperopertyに@Assertアノテーションを書くとそれができようされるらしい

validation ruleをform用に別途書かなくていい

viewの作り方も一つに決まらない

FormObjectをどこまで利用するかの差がある

あまり柔軟性がないイメージがある

生成されるものと全く同じものを手動で書けば同じ動作になる

form_startを使うかどうか

使わないなら自分でformタグを追加し、name属性を指定する

そのnameのRouteであるcontrollerのactionを作ればいい

code:twig

<form

name="form{{ productClass.id }}"

action="{{ url('hoge_form', {id:product.id }) }}"

method="post"

...</form>

code:controller.php

/**

* @Route("/products/{id}", name="hoge_form", methods={"POST"}, requirements={"id" = "\d+"})

* @ParamConverter("ProductClass", options={"mapping"={"productClassId"="id"}})

*/

public function hogeSubmit(Request $request, Product $Product, ProductClass $ProductClass) {

...

}

こっちのやり方のほうが正しい実装になりそう

VIew側

createViewしてアクセスする

code:twig

{{ form_widget(productForm.createView.quantity, {'attr': {'class': 'quantitySelectForm__input quantity'}}) }}

ざっくりわかりやすい

v2だが

「お気に入りボタン」を実装するときにもわざわざformタグを使うの？

EventDispatcherってなに