20

Symfony 2 のドキュメントでは、次のように述べられています。

バンドルには、JavaScript、CSS、またはその他の言語で記述されたサードパーティ ライブラリを埋め込まないでください。

では、どうすればいいですか?Composer を使用して、Twitter Bootstrap、DataTables、およびその他の多くのものを依存関係としてインストールしたいと考えています。しかし、私が考えることができる唯一の方法は、バンドルを作成して埋め込むことです。

これを行う正しい方法は何ですか?

4

2 に答える 2

14

Twitter でBowerを使用する必要があります。HTML、CSS、Javascript のパッケージ マネージャーです。あなたが抱えているまさにこの問題に対処するために作成されました。

于 2013-01-19T19:23:39.770 に答える
6

編集: 現在、Bower、Jam、Component などの JS ライブラリ用の非常に優れたパッケージ マネージャーがあります。

バージョン管理システム

セマンティック バージョニング- Composer は、セマンティック バージョニング システムの使用を推奨しています。XYZ 設定を使用します。X はメジャー バージョン、Y はマイナー バージョン、Z はパッチ バージョンです。Y と Z は常に下位互換性がある必要がありますが、X は下位互換性を損なう可能性のあるコードの変更を反映しています。

埋め込み

埋め込みは、コード (およびバイナリ) をサード パーティ (ベンダー) のパッケージ/バンドルとして要求するのではなく、ライブラリの一部としてコピー アンド ペーストするものと解釈する必要があります。リソース フォルダーに query.js を含めるか、proper コードをコピーしてバンドル内のフォルダーに貼り付けるようなものです。

サードパーティのライブラリを埋め込まない理由

バンドルには、JavaScript、CSS、またはその他の言語で記述されたサードパーティ ライブラリを埋め込まないでください。

このステートメントは、ベスト プラクティスの観点から得られたものです。あらゆる種類のサードパーティ ライブラリ (特に PHP ライブラリ) を (コピー/貼り付けのように) 埋め込むことは、通常はお勧めできません。たとえば、BUNDLE A が LIBRARY FOO v1.4.1 を使用し、BUNDLE B も LIBRARY FOO を使用していますが、バージョンは v1.5.2 とは異なるとします。BUNDLES (A または B) のいずれかに FOO lib が組み込まれている場合、互換性がなくなる可能性があります (おそらくそうなります)。たとえば、php のクラスと関数は再宣言できません。もちろん、いずれのバンドルも、FOO のバージョンのネームスペースやオートロード ルールなど、この問題を軽減するための回避策を使用できますが、解析される同じものの 2 つのバージョンがあるため、メモリ使用量が確実に増加する以外に、他の問題が発生する可能性があります。 PHPによって。

PHP パッケージがこのベスト プラクティスに従っていない場合、発生するエラーは通常、簡単に見つけることができます (エラー: cannot redeclcare function blablabla を含む)。ただし、Javascript ライブラリの場合はそうではありません。関数を再宣言できます (オブジェクト プロパティであるため)。そのため、代わりに FOO が JS Lib になり、BUNDLE A と B がそれらをライブラリに埋め込むと、それらが含まれたときに奇妙な問題が発生する可能性があります。たとえば、バンドルの 1 つの重要な機能を欠いている関数を再宣言して、それを壊すことができます。

Symfony は PHP フレームワークです。

PHP ライブラリ/バンドルを扱います。Symfony は、必要なパッケージのダウンロードとロードを処理するパッケージ マネージャーとして Composer を使用するため、ライブラリを埋め込むのではなく、依存関係としてライブラリを要求することをお勧めします。私が覚えている限りでは、2 つのバンドル/パッケージが同じライブラリを使用する場合、それらのバージョン要件が異なる場合、後方互換性がない限り、最も実際のものを使用します。Composer は、手動で解決する必要がある競合を報告します。

しかし... JavaScriptライブラリを適切に処理する方法がありません。これは、Composer が PHP ライブラリのパッケージであるためです。あなたは私が考えることができる2つの方法でこれを回避することができます: (これを処理するための最良の方法はおそらく他にもあります。

  1. javascript ライブラリの周りに PHP ラッパーを作成し、それを含めます (ただし、別のバンドルが同じことを行い、パッケージに別の名前を付けることを決定した場合、これは同じ問題を引き起こす可能性があります)。
  2. composer を使用してサード・パーティーの依存関係として JavaScript ライブラリーを必要とするバンドルを作成します。javascript ライブラリのリポジトリにはおそらく composer.json ファイルが含まれていないため (スタンドアロンの縮小ファイルとして存在する場合もあります)、これはカスタム composer インストーラーを作成し、javascript リポジトリをフォークして (たとえば gitHub で) 追加することで実現できます。それに composer.json など... ただし、前述のライブラリを常に維持およびアップグレードする必要があり、これは面倒な場合があります。

次の点に注意する必要があります。

  1. JS および CSS ライブラリは、クライアントがアクセスできるように公開する必要があります (セキュリティ上の考慮事項)。
  2. Symfony は PHP フレームワークであり、サーバー側のパッケージを扱います。JS/CSS はクライアント側です。これは、適切に機能するように考慮する必要があります。
  3. (他の PHP フレームワークと同様に) symfony の背後にある主なアイデアの 1 つは、プロジェクト内およびプロジェクト間でのコードの再利用性です。Pure Javascript ライブラリは、それ自体で再利用可能です。それらは通常自己完結型です。その上、サーバー側から JS ライブラリを「バンドル」しても、実際のメリットはありません。再利用性を実現するために、いかなる種類のバンドルも必要ありません。

私のアプローチ

Composer システムは非常に魅力的であるため、特にバンドル/パッケージ/ライブラリを他の人にデプロイする場合は、サード パーティの javascript/css ライブラリを使用するための私のアプローチは、他のパッケージ/バンドルが依存できる JS/CSS 固有の依存関係マネージャーを作成することでした。これを気にせずに JS/CSS の依存関係を処理してください。

私の提案

プロジェクトを一般に公開する予定がある場合、つまり symfony バンドルとしてリリースする予定がある場合は、これにどのようにアプローチするかを慎重に計画する必要があります。プロジェクトが自己完結型 (個人使用またはクライアント向けであり、広く使用されていない) の場合、使用するサード パーティ ツールをプロジェクトに含めることをプログラマ (プログラマー) が完全に制御できるため、関連性ははるかに低くなります。これらは、将来の問題を回避するためのベスト プラクティスの「提案」にすぎません。

于 2012-07-24T02:58:41.133 に答える