2

別のウェブサイトで使用されている既存のsymfonyソフトウェアを再利用する新しいウェブサイトを構築しています。コードとデータの重複を避けるために、再利用可能なコンポーネントをプラグイン( "app-plugin")に移動しています。プラグインは、Webサイトのsvnリポジトリでsvn-externalとして構成されます。

既存のsymfonyインスタンスには、他のプラグイン(sfDoctrineGuardPluginなど)で最初に定義されたオーバーライドされたドクトリンクラス(モデル、フォーム、フォームフィルター)が含まれています。オーバーライドされたクラスは両方のsymfonyインスタンスで再利用できるため、それらを「app-plugin」に移動します。しかし、これは問題を引き起こします:

たとえば、誰かが実行した場合symfony doctrine:build-forms、移動されたファイルはlib / form / doctrine内のタスクによって再作成され、空のクラス定義が含まれます。その理由は私には非常に明白です。symfonyは「app-plugin」がすでにそれらのフォームクラスを定義していることをどのように知っているのでしょうか?唯一の方法は、タスクを実行してクラスがすでに使用可能かどうかを確認する前に、すべてのクラスを自動ロードすることです。

回避策は、app-pluginのconfig/autoload.ymlでこれらのクラスを除外することです。しかし、もっと良い方法はありますか?

編集

通常のプラグイン(sfGuardなど)と共有コンポーネントを含むプラグインとの混同を避けるために、「app-plugin」という用語を使用しています。


前:

以前の依存関係


後:

後の依存関係

4

2 に答える 2

2

あなたが話しているこの「アプリプラグイン」とは何ですか?通常、あなたがしなければならないのは、オーバーライドされたクラスをそのままにして、プラグインにあるはずの親クラスに含まれているコードを移動することだけです。また、特定のsymfonyアプリの動作を変更したい場合は、これらのオーバーライドされたクラスを編集できます。

于 2011-05-17T12:50:03.087 に答える
0

app-pluginのconfig/autoload.ymlで元のモデルを除外するよりも良い方法はないようです。上の画像に示されているようにモデルクラスを導出できたとしても、build-formsタスクを実行するとすぐに問題が発生します。フォームジェネレータのソースコードを調べたところ、これは不可能であることがわかりました。したがって、唯一の解決策は、build-formsタスクを回避するか、form-generatorを書き直すか、またはすでに述べたように、autoload.ymlを使用することです。

于 2011-06-14T12:12:48.950 に答える