0

対応するエンティティの構成方法によってフィールドが異なる Symfony 2 でフォームを作成しています。

簡単に言うと、各エンティティには、さまざまなタイプと構成のデータを保持できる一連の「詳細」フィールドがあります。

たとえば、Projectエンティティは次の構成を持つ場合があります。

  • urlテキスト入力としてレンダリングし、最大長 300 文字の URL として検証します。
  • description検証制約のないテキストエリアとしてレンダリングします。
  • logoファイル入力としてレンダリングし、最大サイズが 500x500 の画像ファイルとして検証します。

等々。これを興味深いものにしている部分は、管理者が UI を介してこれらのモデルの構成を変更できるように、これらすべてがデータベース テーブルを介して構成されていることです。

データベース構造 (の関連部分) は次のようになります。

4 つのテーブルを示す ERD - project、project_detail、detail_type、detail_type_assignment

  • projectプロジェクト レコードを格納します。
  • project_detail各プロジェクトの各詳細フィールドの値を格納します。
  • detail_type各詳細フィールドのタイプと構成を定義します。
  • detail_type_assignment各エンティティで使用できる詳細タイプと、フィールドがフォームに表示される順序を定義します。

フォームでのエラー メッセージのレンダリングを除いて、これまでのところすべてうまく機能しています。

これらの詳細フィールドのいずれかで検証エラーが発生すると、フォームの上部に表示されます。

詳細フィールドのエラー メッセージが上部に表示されたプロジェクト編集フォームのスクリーンショット。

上の画像で、「EIN」はProjectエンティティに存在するフィールド (つまり、Symfony フォームの通常の方法で実装) であり、「URL」と「ロゴのアップロード」は詳細フィールドとして実装されていることに注意してください。

ProjectType外観は次のとおりです。

class ProjectType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('name')
            ->add('ein', 'ein')
        ;

        /* Add detail fields to the form builder. */
        foreach($this->getDetailTypes() as $detailType)
        {
            $slug       = $detailType->getSlug();
            $formatter  = $detailType->createFormatterInstance('');

            $builder->add(
                  $slug
                , $formatter->getFormFieldType()
                , $formatter->getFormFieldOptions()
            );

            /* E.g.,
             *
             * $builder->add(
             *     'url'
             *   , 'text'
             *   , array('label' => 'URL', ...)
             * )
             */
        }
    }

    ...
}

ここで起こっていることは、 が を正しくViolationMapper翻訳できないことだと確信しています。property_path

たとえば、実行時property_pathurl値の は ですproject.details[url].valueが、フィールドは にありproject.urlます。

各フィールドの位置がそのproperty_path. 違反が追加されるパスを変更する方法はありExecutionContextますか?

4

1 に答える 1