下の図を見てください:
これは XOOPS2 のテーマフォーマットです。ブロック配列のための５つのプレースホルダと、１つのモジュール用プレースホルダで構成されています。このテーマを描画するためには、テーマより先にこの６つのプレースホルダの描画が終えて、テーマからその描画結果を引き込む（引用する）必要があります。 XOOPS2 は６つのプレースホルダの存在をハードコードされており、拡張は困難でした。ユーザーは管理画面から、ブロックを５つのプレースホルダに割り当てることができましたね:
XOOPS Cube では、 CMS は特定のテーマフォーマットに対して交換不可能なハードコードを用いて直接的な関係を結ぶべきではない、ということになっています。これは多くのユーザーが望んだ仕様です。
ともかく、 XOOPS Cube は固定フォーマットを持たず、柔軟性を追求しようということになっています。しかし、技術的にどういう仕組みでそれを実装するのか？ 汎用レンダーシーケンスは、「左カラム」「右カラム」といったハードコードされた固定カラムの代わりに、シーケンスIDという概念を用います。
シーケンスIDを理解することは大切です。
通常、描画の実行順とプログラムの実行順は異なっています。たとえば、テーマは CMS コアによって準備され使われますが、描画の順番でいえば一番最後になります。対して、 CMS コアというプログラムは一番最初に実行されなくてはいけません。シーケンスIDは、描画の順番とプログラムの順番を別々に扱うためのメカニズムです。
XOOPS Cube の次案では、それぞれのプログラムは直接描画を行うことはできず、シーケンスIDを持つレンダーオペレーション（描画命令）を発行することになっています。
Root のコレクタは、タスクリストを巡回してレンダーオペレーションを集めます。集めた後、描画順にソートしてからレンダリングを開始します。このとき、後ろのレンダリングはそれより前のレンダリングの結果を引用できます。テーマはこの汎用の機構を利用して各プレースホルダの描画結果にアクセスします:
もちろん、この基本的な仕組みはどんな合成にも有効です。
もう一度見てみましょう。最初、コレクタは空っぽです:
もし、コレクタが単純にオペレーションを集めてしまうと、オペレーションの集合体は以下のように順不同（アウトオーダー）になります:
しかし、コレクタはオペレーションを収集する際に同時にソートをかけていきますので、最終的には順番どおりに整えられます（インオーダー）:
それから、それぞれのレンダーオペレーションに指名された各レンダーシステムを使って順番に描画を実行します。「後ろのレンダリングは前のレンダリングの結果を引用できる」ので、最終的にはテーマが正しく描画されます:
ちなみに、このテーマのオペレーションはスクリーンバッファ役の特別なレンダーターゲットに紐づけされています。それが最終出力の結果がブラウザに出力されるカラクリです。
しかし、これはあくまでプログラマにとって有効な仕掛けであって、エンドユーザーに対しては隠蔽されていなければなりません。たとえこのメカニズムが XOOPS Cube の目的のためにパワフルであっても、 CMS (Base) はユーザーがコンテンツをプレースホルダに割り当てるために XCL や X2 のように管理機能を提供する必要があるでしょう。XOOPS Cube では、マニフェストを読み込むことで、プレースホルダの数や種類を取得し、管理画面に反映させます:
プレースホルダ情報は [Theme] チャンクに書くことになると思います。しかし、マニフェストは拡張可能でさまざまな情報を格納できますので、 Base の名前でチャンクを作って、特定の Base のために特定の情報を格納してもよいかもしれません。
ところで、プログラムはレンダーオペレーションにタグをつけておくことができます。後ろのレンダリングはタグを使って前のレンダリングの結果を引用することができます。これはパンくずリストやバナーに有効です。
汎用レンダーシーケンスはコアの固定パイプラインで、 BASE レベルで交換ができないものです。描画仕様が厳格化されたため、Legacy 以外の全 BASE の描画ロジックが確定でき、プログラムの作成や共有が容易になります。一方で、非常に柔軟性の高い仕組みなので、完全に理解すれば本当に色々なことができます。
0 件のコメント:
コメントを投稿