One render-target of the site

次の XOOPS Cube とその CVS は、日本では全く話題になっていませんが、海外のアーリーアダプターからはいくつかの技術的質問をいただきました。それらのうちの一つは、 XOOPS Cube の仕様の問題点を指摘するものでした。

通常、 CMS の出力は、パーツの集合体です。従って、ほとんどの CMS は、各部分のパーツ出力とテーマ（スキン）から最終出力を合成します。そのため、最終出力に関係するテンプレートファイルは、複数です。 CMS が Blogger のように１つの表示形態しか持たないのであれば、私達は全てのテンプレートを１つのファイルで扱うことができます。しかし、 XOOPS や他の CMS は、 Blogger のような Blog ではありません。

サイトを組み立てるために複数のテンプレートがあることは、問題ではありません。しかし、ユーザーが１つのテンプレートによってサイトを組み立てる選択肢を持つことができるならば、それは、更に良いです。メールは、それを指摘しました。それは、専門の人にとって有益です。

実際、 XOOPS Cube は、１つのテンプレートを扱うことが得意ではありません。なぜなら、 XOOPS Cube は、いかに上手く CMS レンダリングを扱うかについて熟慮したからです。レンダリングのメカニズムは、分割されたシーケンスに特化されました。XOOPS が 1 つのテンプレートによってレンデリングうることができないように、 XOOPS Cube は、それをすることができませんでした。

私は、最近にこれについて考えており、そして、解決策を発見しました。BASE がスクリーンターゲットを全タスクのレンダーオペレーションとリンクするとき、 XOOPS Cube は、 1 つのテンプレートと複数のオペレーションの組み合わせによって描画を行うことが可能かもしれません。汎用レンダーシーケンスの一部は、交換可能です。専門家は、この目的のために、再利用可能なタスクとして、いくらかのプログラムを作ることができます。

いずれにせよ、それは、特別なケースです。しかし、私は、ケーススタディを歓迎します。

ところで、ホダ塾ディストリビューションは、 XCL の限界に遭遇しなければなりませんでした。次の XOOPS Cube は、容易にそれらの挑戦を解決することができます。このディストリビューションは次の XOOPS Cube にとって最高のケーススタディでした。