Symfony2のフォームアーキテクチャ

Symfony 2にはフォームを操作するための完全に新しいコンポーネントがあります。私の知る限り、PHPのこれらのライブラリのほとんどは機能的にも、可能であれば拡張時にも簡単に置き換えられます（もちろん、JavaScriptを操作するときに小さな欠陥を考慮しない場合） 。 このコンポーネントの開発には2年以上かかりましたが、2009年またはそれ以前に別の場所で考え始めました。 新しいバージョンごとに、このコンポーネントはますます安定しており、Symfony 2.2のリリースでは完全に安定したバージョンが期待されています。



この投稿はZend Framework 2 Form RFCのリリースに捧げられています。なぜなら、その開発者は実際、私たちがすでにやったことの多くをしたように思えるからです。 もちろん、Zend Framework 2には、フレームワークに付属するコンポーネントの機能を完全に考慮したフォームを操作するためのレイヤーが必要であることは誰にとっても明らかです。 この投稿の目的は、Symfony2 Formsがこれらの要件に完全に適合していることを示すことです。 Symfony2に固有の機能は簡単に削除できます。フォームおよびすべての抽象化レベルを処理するためのコードは完全に独立しています。 Zendコンポーネントの機能のバインディングサポートも難しくありません。



開発中に発生する可能性のあるすべての使用シナリオをカバーする、フォームを操作するための汎用ライブラリーの作成は、難しいテストであり、長くて難しいタスクであり、さらに、まだ完了していません。 コラボレーションとさらなる共同開発は、PHPからのより柔軟でシンプルなフォーム管理の実現に役立つはずです。





おそらく、私たちの仕事に影響を与えたフォームを処理するためのフレームワークとライブラリの開発に参加したすべての人に感謝して、この投稿を開始します。 次に、アーキテクチャ自体を説明する前に、フォームを操作するための便利で柔軟なコンポーネントを設計するための重要な側面を紹介します。

この投稿では、このコンポーネントの「キラー機能」の使用例を見つけることはできません。これに関するドキュメントがあります 。 また、ここでは、フレームワークに関係なく、コンテキストの外で、その使用に関する情報を見つけることはできません。 このような情報は、たとえばGistで説明する必要があります。

影響力

フォームコンポーネントは、 symfony 1 、 Zend Framework 1 、 Django 、 Ruby on Rails 、 Struts、 JSFなど、さまざまな言語で書かれた多くのフレームワークの影響を受けています。 さらに、 Formlets 、 WUI 、 iData 、Links、Curry、Cleanなどの関数型プログラミング言語用に記述されたフォームを操作するためのライブラリとの類似点を見つけることができます。

主な側面

フォームを操作するためのコンポーネントを設計する際の重要な側面は次のとおりです。

• 増加した抽象化
• 拡張性
• 構成性
• タスク分離
• モデルバインディング
• 動的挙動

実装されたアーキテクチャがそれらをどのようにカバーするかを議論する前に、これらの各側面を簡単に説明します。

増加した抽象化

抽象化のレベルを上げると、フォームの任意の部分（フォーム全体を含む）を取得し、それをデータ構造に配置して、再び使用できるようになります。 日付を選択するフォームについて考えてみましょう。このフォームには、日、月、年で選択するための3つのドロップダウンリストがあります。 開始するには、すべてのドロップダウンオプションでHTMLを生成するコードが必要です。 次に、アプリケーションの形式（たとえば、PHPについて話している場合はDateTimeオブジェクト）からプレゼンテーションに適した形式にデータを変換するコードが必要です（リストで選択した値をマークするため）。 もちろん、逆の手順が必要になります。 ここで、いくつかの追加データ用に別のドロップダウンリストを追加する必要がある状況を想像してください。 この場合、このリストのすべてのコードを複製し、新しい要件に適合させる必要があります。



抽象化の導入により、コードの記述と再利用に適した構造を提供することでこの問題が解決されます。

拡張性

拡張性は、抽象化に関連する2つの概念に基づいています。

1. 特殊化は、抽象化の論理的なシーケンスです。 機能を一般化されたデータ構造に抽象化できる場合は、それらをより特殊な構造に拡張することもできます。 たとえば、時間フィールドを追加することで、上記の日付選択の例を拡張できます。 日付を選択するために既存のフィールドの機能を拡張する機会がなかった場合、機能の大部分を書き直さなければなりません。
   
   
2. 不純物は特殊化の反対です。 たとえば、既存のすべてのフィールドを変更して、これらのフィールドが必須であることを示すアスタリスク（ "*"）が説明に含まれるようにします。 使用可能なすべてのフィールドを拡張して同じ機能を実装する必要があるため 、このアプローチを特殊化で使用するのはやや実用的ではありません。 不純物を使用すると、機能を既存のオブジェクトに再定義することなく接続できます。 さらに、この方法で追加された機能は、継承ツリーのすべての子オブジェクトに継承されます。
   
   

拡張性とは、イベントを介した機能のより詳細な拡張も指します。 これについては後で検討します。

リンカー

最後の例を分析すると、 フィールド （検討中の例のような複合フィールド 、または入力テキストフィールドのようなプリミティブなフィールド）とformsの間に特別な違いがないことがわかります。 そしてフィールドと形状

1. モデル（配列、日付、文字列など）からデフォルト値を受け入れます。
2. ビューで使用できるように値を変換する
3. フォームHTML
4. ユーザーが入力した値を受け入れる
5. 値をモデル形式に戻す
6. データを検証できる

同じ基本的なデータ構造を使用してフィールドとフォームを実装できます。 リンカーの追加-ネストされた構造を追加できるツール（「リンカー」デザインテンプレートを参照）-任意の複雑なフォームを作成できます。 フィールドとフォームを区別する代わりに、 フォームとそのコンポーネントについて説明します 。 フォームに子孫が表示されるとすぐに、

1. デフォルト値（配列またはオブジェクト）をその子孫に渡す
2. 入力された各子の値を配列またはオブジェクトに返します

タスク分離

上記のタスクをいくつかの特定のグループに分けることができます。

• データ変換
• HTML生成（プレゼンテーション）
• 検証
• データバインディング

これらの各タスクグループは、明示的に定義されたインターフェイスを持つ個別のコンポーネントによって実装する必要があります。 これにより、これらのコンポーネントのいずれかが独自のものに置き換えられます。たとえば、ビューハンドラー、または検証レイヤーなどが置き換えられます。

モデルバインディング

ほとんどの場合、フォームは定義のドメインのモデルで記述された構造に直接接続されます 。 ユーザープロファイル情報を送信する例を考えてみましょう。 すべてのユーザー情報がデータベースの別のテーブルに保存されているとします。 テーブルには、プロファイルに含まれるプロパティ 、各プロパティに使用されるデータの種類 、 デフォルト値 、 データ入力制限に関する情報が格納されます。 理想的には、アプリケーションには、たとえばDoctrine2 ORMを介したデータベース内のテーブルバインディングとともに、必要なすべてのプロパティを持つProfileクラスも含める必要があります。 このクラスには、テーブルに保存されているよりも多くのプロファイルに関する情報が含まれている場合があります。たとえば、プロファイルがユーザーにとって関心のある特定のアイテムのセットを示している場合などです。 簡単にするために、これらのアイテムのリストを構成ファイルから取得します。



通常、オブジェクトを記述する情報（ メタデータと呼びましょう）は、フォームレイヤーで複製する必要があります。 開発者は、フィールドが変更されていないこと、編集可能なフィールド、フォームにHTMLフィールドに対応するウィジェットが表示されていること、一部のフィールドが空のままにならないことなどを確認する必要があります。 これらのことから、フォームを作成するのはかなりありがたい仕事になります。



モデルバインディングは、違いを生むように設計されています。 次の2つのアイデアに基づいています。

1. 重複するコードや設定の数を減らすために、フォームの作成中に既存のメタデータを使用します。

デフォルト値は、定義エリアのモデルから取得する必要があり（この場合はProfileクラスのインスタンスになります）、 入力したデータの入力もモデルで実行する必要があります。

動的挙動

最後になりましたが、これらはフォームの動的な動作です。 フォームのコードがサーバーに完全に実装され、ユーザーが入力したデータのセキュリティチェックが厳密に定義された構造の下で実行されていた時代は終わりました。 今日では、JavaScriptを使用してクライアント側のフォームを変更し、システムの使いやすさを向上させることが流行しています。



テーブルの形でフォームを想像してください。 各列には同じタイプのフィールドがあり、各行はサーバー上のオブジェクトを表します。 フォームには、行を追加または削除できるボタンがあります。 これらすべてにより、フォームを検証する可能性が残っているはずです。フォームはサーバー上で正常に処理される必要があります。



このフォームを実装するために、動的な動作が考案されました。 さらに、それらの使用は比較的単純な表形式に限定されません。 クライアント側で行われた構造の変更に応答するフォームを作成できます。 残念ながら、このようなメカニズムの関連性にもかかわらず、この問題はほとんどのライブラリで解決されていません。

高レベルのアーキテクチャ

フォームを操作するためのSymfony2のレイヤーアーキテクチャの概要を説明します。 その礎石はフォームコンポーネントです。 このコンポーネントは、フォームのコンパイルと処理の基礎を実装し、Symfony2 イベントマネージャーを使用して内部イベントを処理します。 このコンポーネントの上には、プラグイン拡張機能のレイヤーがあります。

• カーネルレベルの拡張機能は、フレームワークに実装されたフィールド構造の説明を提供します（フォームタイプと呼びましょう）。
• フォーム内のユーザー入力を検証するには 、 検証の拡張が必要です。
• DI拡張により、 依存関係コンテナを使用できます。
• CSRF拡張機能は、その名前が示すように、フォームにCSRF保護を追加します。
• Doctrine2拡張機能（ Doctrine Bridgeで提供）は、フォームで使用するオブジェクトメタデータを取得できるようにするDoctrine固有のドロップダウンリストとコンポーネントを追加します。

上位レベルには、HTML-Iの形成を実装するコンポーネントが含まれています。 デフォルトでは、Symfony2にはそのような2つのコンポーネントがあります。1つはTwig経由でフォームをレンダリングするため（ Twig bridgeで提供 ）、もう1つは古き良きPHPでレンダリングするためです（ FrameworkBundleで提供 ）。



おそらく、このアーキテクチャの最も興味深い機能は、任意のコンポーネントを交換できることです。 フォームがZendの検証コンポーネントを使用するように拡張機能を作成できます。 また、Smartyまたはその他のテンプレートエンジンを介してレンダリングを実装するビューコンポーネントを作成することもできます。 カーネルレベルの拡張機能を削除して、単純なフィールドの基本的なフォームタイプを記述することもできます。 基になるイベントディスパッチャでさえ、 EventDispatcherInterfaceインターフェイスを実装するコンポーネントに置き換えることができます 。 これは、多少の不便さにもかかわらず、柔軟性に優れた利点をもたらします。

低レベルのアーキテクチャ

このセクションでは、フォームコンポーネントの内部アーキテクチャに焦点を当てます。 前述のように、フォームとそのすべての部分は、「リンカー」設計パターンを実装する同じデータ構造で表示されます。 Formコンポーネントでは、この構造はFormInterfaceインターフェースによって記述されます。 このインターフェイスを実装する主なクラスはFormクラスで、このクラス全体で機能する3つのコンポーネントを使用します。

• データマッパーは、フォームデータをその子に分配します。 さらに、子供からデータを収集してデータを形成することは、このコンポーネントの責任です。
• 名前が示すとおり、 データコンバーターの 2つのチェーンは 、異なる表現の値を変換します。 データコンバーターは、それを表すために使用される形式に関係なく、アプリケーションが厳密に定義された形式で値を受け取ることを保証します。
• イベントマネージャを使用すると、フォーム処理の所定の段階で特定のコードを実行できます。 このアプローチにより、フォーム構造を受信データに適合させたり、これらの非常に受信データを除外したり、検証または変更したりできます。

これらのすべてのコンポーネントは、 Formオブジェクトのコンストラクターに渡され、 フォームの作成後に変更することはできません。これは、フォームの状態に望ましくない変更を引き起こす可能性があるためです。 Formオブジェクトのコンストラクターのインターフェイスは非常に複雑なので、 フォームコンストラクター （FormBuilder）が実装されており、これらのオブジェクトのインスタンスの作成が簡単になっています。



フォームのビューは、ビューを記述するデータ構造です。 つまり、テンプレートで直接Formクラスを呼び出す代わりに、 FormViewクラスのインスタンスを使用します。 このオブジェクトには、フォームのHTML要素の名前属性、IDなど、プレゼンテーション専用の追加情報が格納されます。



以下のUML図は、アーキテクチャの本質を示しています。







この図からわかるように、フォームのライフサイクルは3つの異なる表現で構成されています。

• 作成されると、フォームはFormBuilderオブジェクトの階層として表されます
• コントローラーでは、フォームはFormオブジェクトの階層で表されます
• プレゼンテーションレベルでは、 FormViewオブジェクトの階層で表されます。

プレゼンテーション用にフォームデザイナーを構成するのはかなり面倒なので、Symfony2は、基本設定を既に実装しているフォームの基本タイプを実装します。 フォームタイプは動的継承をサポートします。 つまり、フォームコンストラクターに渡されたオプションに基づいて、さまざまな基本型を拡張できます。 次の図は、Symfony2に同梱されているすべてのタイプを示しています（カーネルに同梱されている緑でマークされたタイプ、追加のバンドルが黄色の場合）







前述の不純物は、いわゆる型拡張としてSYmfony2に実装されています。 これらの拡張機能は、既存の種類のフォームに接続し、何らかの動作を追加できます。 たとえば、Symfony2には、「フォーム」タイプ（およびその結果、このタイプを継承するすべてのタイプ）にCSRF保護を追加するための拡張機能があります。



フォームファクトリは 、ロードされた拡張機能から型階層を取得し、それを使用してFormBuilderおよびFormViewオブジェクトをカスタマイズします 。 この段階は制御できることに注意することが重要です。 たとえば、タイプ「 choice 」を使用すると、設定で属性「 choices 」を指定できます。これには、表示されるオプションのすべての値が含まれます。



Formコンポーネントタイプの予測子には、もう1つのかなり重要な概念があります。 これらの「予測子」は、フォームが割り当てられている定義領域のオブジェクトから取得されたメタデータに基づいて、フォームフィールドのタイプとオプションを予測しようとします（もちろん、固定されている場合を除く）。 たとえば、オブジェクトのプロパティのいずれかにTagオブジェクト間の1対多の関係が含まれている場合、型予測子はこのプロパティのこのフォームフィールドを自動的に構成し、複数の値を選択できる機能を持つ選択フィールドになります。 Tagオブジェクトのすべてのインスタンスをこのフィールドのオプションとして使用します。 同様の概念がDjangoフレームワークのModelFormsで使用されています 。 確かに、大きな違いが1つあります。型予測子は、ORMだけでなくすべてのオブジェクトメタデータによって提供されるメタデータを使用します。 Symfony2には3つのタイプの予測子が付属しています。1つはDoctrine2によって提供されるメタデータを使用し、もう1つは提供されるpropelを使用し、もう1つは検証ルールを使用します。



上記の概念は、次のUML図で説明できます。

おわりに

この投稿で示したかったのは、Symfony2 Formコンポーネントには、フォーム処理の多くの重要な側面をカバーする適切に設計されたアーキテクチャがあることです。



このアーキテクチャは、不十分なレベルの抽象化 、 特殊 化 、および不純物の問題を解決し、フォームのタイプとその拡張の継承の動的ツリーを提供します。 フォームを処理するタスクをそのすべての要素に分散することにより、 構成の問題を解決します。 また、コンポーネント間でタスクを明確に分離できるため、独自のタスクに置き換えることができます。 フォームの作成時に定義ドメインのオブジェクトのメタデータを使用して、説明されているアーキテクチャはこれらのモデルへのデータバインディングを実装し、データの直接読み取りと書き込みを可能にします。 また、 動的な動作も無視しませんでした。たとえば、ハンドラーを使用してフォームの処理中に発生する特定のイベントを追跡し、データの検証やフィルター処理を行うことができます。



に興味がありますか？ コードを学ぶ 。 それで実験してください 。 そして、お気に入りのフレームワークに統合するのを手伝ってください。



翻訳者から：この記事の翻訳は存在しますが、高品質ではないと思われました。 はい、それは痛くないと思います。 翻訳では不正確な可能性がありますので、PMでご指摘いただいた場合は感謝いたします。 ご清聴ありがとうございました。