3

sfGuardUserモジュールのフォームをカスタマイズしようとしています。sfGuardDoctrinePluginをインストールした後、Symfonyの設定より規約に従い、次の構造を作成しました。

apps/backend/modules/sfGuardUser
apps/backend/modules/sfGuardUser/config
apps/backend/modules/sfGuardUser/config/generator.yml

ファイル内で、この関連する質問と公式ブログのこの投稿でgenerator.yml提案されているように、デフォルトのプラグイン設定をオーバーライドしようとし ました：

発生器：
  クラス：sfDoctrineGenerator
  param：
    構成：
      田畑：
        ファーストネーム：
          ラベル：名前
        苗字：
          ラベル：名前
        電子メールアドレス：
          ラベル：Eメール
        updated_at：
          ラベル：最終更新
          date_format：f
      リスト：
        タイトル：People
        表示：[=ユーザー名、名前、メールアドレス、last_login]
        並べ替え：[ユーザー名、asc]
      フィルター：
        表示：[ユーザー名、名、名前、メールアドレス]
      編集：
        タイトル：「%%name%%」を編集
      新着：
        タイトル：新しいユーザーを追加します
      形：
        画面：
          「ユーザー」：[first_name、last_name、email_address、username、password、password_again]
          「権限とグループ」：[is_active、is_super_admin、groups_list]

ただし、フォームにはデフォルト設定が反映されています。たとえば、まだ表示されていpermissions_listます。

さらに、sfGuardUserAdminFormをオーバーライドしてウィジェットの設定を解除しようとすると、ウィジェットも機能しないことがわかります。

どうすればそれを回避して実際のオーバーライドを強制できますか？私は何かが足りないのですか？

ありがとう！

UPDATE 1 回避策を見つけました。これは、グループにfalse値を割り当ててから、必要なフィールドを使用して新しいグループを設定します。

"User":  [first_name, last_name, email_address, username, password, password_again]
"Permissions and groups":  false
"Status and groups":  [is_active, is_super_admin, groups_list]

UPDATE 2 これは文書化されたバグですが、コア開発者はこれに対処していないようです。チケットには、私のようなこの問題を経験している人のためのパッチが含まれていました。

4

1 に答える 1

2

残念ながら、オーバーライド規則は、プラグインのgenerator.ymlで期待するようには機能しません。最も簡単な方法は、プラグインのgenerator.ymlファイルを構成することです。これは私が行うことです。

プラグインのgenerator.ymlをアプリ/モジュールに移動（コピーではなく）することもできます。このスレッドには、興味深い解決策が1つあります：http：//oldforum.symfony-project.org/index.php/m/43279/

于 2011-03-16T13:33:19.813 に答える