lablab.jp （日本語版）

Description

Legacy_ControllerはXoosModueインスタンスと同様にXoopsBlockインスタンスを直接使用しません。 ブロックプロセスでは、Legacy_ControllerはLegacy_AbstractBlockProcedureクラス系を使用します。 これとLegacy_AbstractModuleは同じ概念です。 Legacy_AbstractModuleを理解していないなら、このエントリを読んでください。

モジュールがクラス使用を宣言しない場合では、Legacy_ControlleはアダプターのクラスとしてLegacy_BlockProdecureAdapterを使用します。 このクラスはXOOPS2仕様を完全に模倣します。 Legacy_AbstractModuleとは異なり、Legacy_Controllerは明示宣言なしではブロックのクラスを見つけようとしません。 したがって、モジュール開発者はそれを望むならxoops_version.phpでのブロックのクラス名を定義する必要があります。

How to create instance

1. $modversion['blocks'][x]['class'] = '{Class}'; を xoops_version.php で定義します
2. $modversion['blocks'][x]['file']で指定されたファイルに Legacy_BlockProcedure のサブクラスとして {Dirname}_{Class} クラスを定義します
3. メソッドを実装します

開発者はこれを何のために使いますか？

Legacy_Controllerが正しくアダプターのクラスを使用するので、多くの場合、モジュール開発者はこのメカニズムを使用する必要はありません。 しかし、いくつかのケースでは、XOOPS2 JP仕様は十分ではありません。 それに対して、このメカニズムは役に立ちます。

XoopsBlockへのアクセス

XOOPS2 JPによって呼ばれたブロックショー関数は、この関数のシグニチャがXoopsBlockインスタンスを含んでいないので、XoopsBlockインスタンスにアクセスすることができません。Legacy_Controllerは、Legacy_BlockProcedure::execute() をブロックショー関数の代わりにコールします。したがって、モジュール開発者は$this->_mBlock にアクセスできます。

XoopsBlock解釈の変更

たとえば、piCalはブロックのタイトルを変えるためにcommon.phpが使用した大域変数にアクセスします。 それはすばらしく、かつ、正統でないアプローチです。 しかし、XOOPS Cube Legacyはそのような場合のための正統のアプローチを提供します。 クラスを作成してください、そして、getTitle()をオーバーライドしてください。

ヒドゥンブロック

仮想のcronとしてブロックキャッシュつきブロックを使用するのを望んでいるなら、isDisplay()をオーバーライドしてください。 isDislay()がfalseを戻す場合、Legacyはブロックディスプレイなしでキャッシュを作成しようとします。

描画プロセスの変更

common.phpがブロックを描画するため、XOOPS2 JPブロックはレンダリングプロセスを変えることができません。 しかし、XOOPS Cube Legacyでは、Legacy_BlockProcedureがそれ自身の結果をレンダリングしようとします。 したがって、モジュール開発者はテンプレートファイルや依存レンダーシステムを変更することが出来ます。

Note

もし $modverison['block'][x]['class'] が定義済みであるなら、モジュールインストーラは $modversion['block'][x]['show_func'] を無視します。

実例

βの stdCache モジュールを見てください。