汎用レンダーシーケンス (2)

ここで XOOPS Cube コアのレンダリングについてもう一度みてみましょう。 XOOPS Cube コアでは、「CMSがテーマのフォーマットをデザイナーに強制しない」という前提条件で作られています。フォーマットを新作するためにはプログラムが必要ですが、交換できないよりずっとマシです。

XOOPS Cube コアは「描画機構:レンダーシステム」と「描画対象のバッファ:レンダーターゲット」を抽象化して扱っています。レンダーシステムとレンダーターゲットはメインシーケンスの統括的コントロールとは無関係に、独自に使用できる必要があります。

一方、レンダーオペレーションは、「レンダーシステムとレンダーターゲットをどう使うか」という、汎用レンダーシーケンス専用の指令データです。コアの汎用レンダーシーケンスがレンダーシステムとレンダーターゲットを自動的に使用するため、プログラム側でこれらの要素に直接アクセスする必要はなくなります。

ただしアクセスを禁じるわけではありません。汎用レンダーシーケンスは、上位の「シーケンス」の仕組みであり、レンダーシステムとレンダーターゲットは、下位の「レンダリング」の仕組みです。どちらも利用可能です。

XOOPS Cube Developers Group Japan のメーリングリストで onokazu さんが鋭く指摘したのは、「レンダーオペレーションと同主旨のメンバをレンダーターゲットが持っている」という点です。

対 Legacy 用の XOOPS Cube 0.9 にはレンダーオペレーションという仕組みはなく、レンダーターゲットがその役割を兼ねていました。

Legacy で重視したかったことに、アトリビュート（テンプレート変数）のリセットがあります。 XOOPS2 には先に登録されたテンプレート変数を、後のレンダリングが参照するというテクニックがありました。しかし、 Legacy は XOOPS Cube コアの交換式レンダーシステムに対応しているため、レンダーシステムＡで使われた変数にレンダーシステムＢがアクセスできないという問題(?)があります。 Legacy では同じレンダーシステムでも原則変数は引き継がないという仕様で操作感の統一を図りました。

もしこれが３Ｄプログラミングなら、そのような利用（パラメータの預けっぱなしを活かすことも、それでつまずくことも）はプログラマの責任です。しかし、私達は、XOOPS2 の経験を持つプログラマに対して、レンダリングが他のレンダリングのテンプレート変数にアクセスできないことを明示する必要があると考えました。そこで Legacy はレンダリング後にテンプレート変数を消去する仕様を持つに至りました。

この仕様の実装にあたり、Legacyでは、レンダーシステムを直接制御するのではなく、レンダーターゲットにリクエストを入れて送るという方式を取っています。レンダーシステムのアクセスは Legacy 側で行うことがほとんどでした。言い換えれば、「Legacy は非汎用のレンダーシーケンスを持っている」です。このとき、ターゲットが Legacy 非汎用レンダーシーケンスに対するレンダーオペレーションの一種として機能していたわけです。

Cube コア 1.0 では、レンダーオペレーションの導入とともに、この部分を正しく分離して仕上げる必要があるでしょう。結果として、システム、ターゲット、オペレーションでかなり明瞭なクラス分けができると思います。