別スレッドdrupal8はフレームワークのSymfony2を採用したのでしょうか。- Pluginシステムで qchan さんが紹介してくださった Drupal 8 Plugin architecture のページを和訳してみました。できるだけわかりやすく訳したつもりですが、正直、実際の中身がわからないので訳語などが間違っている可能性があります。ご確認いただけたら幸いです。
もう１つのページ Introduce Plugin System to Core の方は時間の都合で訳せていません（しばらくは訳す時間がとれないと思います）。
Drupal 8 プラグイン アーキテクチャー
概要
D8 プラグイン システムは、準拠しやすいガイドラインのセットおよび再利用可能なコード コンポーネント群を設けるためにデザインされています。これらによって開発者たちはプラグ（着脱）可能なコンポーネントを自らのコード内で公開できるようになります。また、必要に応じた状況でユーザー インターフェースを通してそれらのコンポーネントをより円滑に管理できるようにもなります。このプラグイン システムから最大限の効果を引き出すには、いくつものコンセプトを理解しなくてはなりません。プラグイン システムの最も基礎的なレベルは以下のコンポーネントからできています。
- プラグイン タイプ（Plugin Types）：
- プラグインの検出（Plugin Discovery）：
- プラグイン ファクトリー（Plugin Factory）：
プラグイン タイプは、同じタイプに属するプラグインを検出およびインスタンス化する方法を定義する中心的な制御クラスです。タイプは、それに属するプラグインすべての主な目的を記述します。たとえば、バックエンドのキャッシュ、画像の動作、ブロックなどです。
プラグイン検出は、利用可能なコード ベース内にあるプラグインを見つけるプロセスです。プラグイン タイプの用途に合った形で使用できるプラグインが検出対象となります。
ファクトリーは、一定の使用ケース用に選択された特定のプラグインをインスタンス化する役目を負っています。
最も一般的な使い方から見れば、プラグイン システムの心臓部はこれら 3 つのコンポーネントからできています。これらのコンセプトに加え、状況に応じて以下のコンポーネント群を利用できます。
- プラグイン デリバティブ（Plugin Derivatives）：
- 検出デコレーター（Discovery Decorators）：
- プラグイン マッパー（Plugin Mappers）：
プラグイン デリバティブを利用すると、単独のプラグインが多数のプラグインに代わって動作できるようになります。これは、利用できるプラグイン群に対してユーザーからの入力データが影響を与え得るような状況で特に役立ちます。たとえば、ひとつのプラグインを使って画面上にいくつかのメニューが配置されているとき、サイト管理者が新しいメニューを作成した場合、そのメニューは新しいプラグインをもうひとつ使うことなしに配置できなくてはなりません。プラグイン デリバティブは、ひとつではなく複数のプラグインを表示できるようにすることで、ユーザー インターフェースもサポートします。これにより、使用ケースに合わせたヘルプ テキストの表示および利用が可能になります。プラグイン デリバティブの主な目的は、部分的に設定されたプラグインを「ファースト クラス」のプラグインとして提供することです。これらのプラグインは UI 内では他のプラグインと区別できないので、これらのプラグインを使用する管理者たちの負担を減らすことができます。
検出デコレーターは既存の検出メソッドをラップするために利用できる、もうひとつの検出メソッドです。コアには現在、ひとつのプラグイン タイプ用に選択された検出プロセスをキャッシュする cacheDecorator が備わっています。このパターンは必要に応じて他の使用ケースへと拡張できることでしょう。
プラグイン マッパーを利用すると、特定のプラグイン インスタンスに対して何か（ほとんどの場合は単独のストリング）をマッピングできます。このアプローチを使用するプラグイン タイプは、任意に定義できる名前に基づいたプラグイン インスタンスをフルに設定してインスタンス化したうえで返すことができます。開発者がこの API を使って手動でインスタンス化および設定する必要はありません。
この文書では、これらのコンセプトすべてに関する踏み込んだ解説、最適な使用方法を紹介します。これらのコンセプトをできるだけ素早く容易に使用するためのコード例も記載されています。
Comments
WSCCI プラグイン スプリントのまとめ
参考情報として、ラリー ガーフィールド（Larry Garfield）氏が昨年 11 月末に書いた記事「WSCCI Plugin Sprint Summary」を一部、訳してみました（ちょっと中途半端な感じですみません…）。もし間違いを見つけられた場合は教えていただけたら幸いです。以下、カッコ内は訳注です。
背景
「プラグイン問題」が Drupal（コミュニティー）を悩ませるようになって久しい。僕たちにはフック（hooks）がある。フックは、システム内部のイベントに応答し、存在しているシステムに機能を追加するにはすばらしい方法だ。ただし、「スワップ可能な（swappable）コンポーネント」を定義するにはかなりお粗末な方法だ。現在、コアはこうしたコンポーネントの必要なシステムのそれぞれに対して、別々で一貫性のない、いくつものメカニズムを提供している。それは、キャッシュ、セッション、テキスト形式、ブロック、パスワードのハッシュ（暗号化）といったものだ。そして、他のさまざまなコア システムもすべて、自前で別個にその場限りのやり方、それも一貫性のないやり方で、スワップ可能なものを定義している。それは、学習するのが難しくなるだけではなく、共通のパターンまたは共通のコードから最適化が行えないことを意味する。最適化しようにもパターンもコードも共通化されていないのだから。
スワップ可能なシステムは、さまざまな拡張（貢献）モジュールにも備わっている。ほとんどは似たような単発モノで能力も限定されている（汎用性がない）。（そのなかでも）いちばん高度に発達し、いちばん広く使用されているのは ctools プラグイン システムだ。それは概念のうえではかなり頑丈にできているが、その実装は今や古い荷物をたくさん抱えている。そのせいで、僕たちがコアに取り込みたいと思っても、取り込むには複雑すぎるものになっている。
ctools プラグインを大いに応用して、コア用の統一されたプラグイン API を設けること。それによって、僕たちは Drupal の API を簡素化できるし、より学習しやすくできる。オン デマンドでコードを遅延読み込み（lazy-load）する共通のやり方を設けると共にコードの量を減らすことでパフォーマンスも改善できる。また、モジュール開発者たちにもっとパワーを与えることにもなる。
僕たちはこれまでに他のいくつかの PHP フレームワークを調べてみた。その結果、僕たちが必要としているほど強固なプラグイン システムを備えているものはないことがわかった。ただし、その基底コンセプトは他の多くのプロジェクトに見られる。それは Symfony2、多数の Java プログラム、そして、Cassandra ドキュメント データベースなどだ。
なぜ Web サービス（イニシアチブ）が関与するのか
では、どうしてプラグインは「Web サービスとコンテクスト コア」イニシアチブに関係があるのか？主な理由は 2 つある：