PEAK XOOPS - Cube2.1でも気持ちよく動くD3モジュール実装法 in englishin japanese

| Archive | RSS |
XOOPS
XOOPS : Cube2.1でも気持ちよく動くD3モジュール実装法
Poster : GIJOE on 2006-09-05 05:21:58 (7877 reads)

in englishin japanese
wrapsモジュールを手直しした際の覚え書きで恐縮ですが…

・Cube2.1かどうかを判断する

	if( defined( 'XOOPS_CUBE_LEGACY' ) ) {

class_exists('XCUBE_ROOT') だと、Shadeとの区別がつきません。
（ShadeでもX2でも動くモジュール、というのはさすがに想像つきませんが）

・デリゲートやアクションフィルターを登録する
X2, Cube2.1の両方で通過し得るコードについて、Cube2.1専用の機能を使うなら、当然、上の条件式で判断します。（そうしなければ、X2側でfatal）
ただ、モジュールpreloadを使う、というのも良い手です。
ROOT_PATH側に、preload/(class名).class.php というファイルを置いておけば、ここを処理するのは、Cube2.1だけです。

Legacy_Controllerを読めば判りますが、そのファイルをrequire_onceした後で、(class名)のインスタンスを作り、アクションフィルターに登録しようとします。

残念ながら、この仕掛けの後半部分は、複製可能モジュールには利用できないので、「(class名)のクラスを作らないこと」が重要です。クラスが存在したら、インスタンスが作られ、登録されてしまいます。

D3モジュール側でアクションフィルターを登録する場合は、(class名)とは異なるクラスを作って、自分で $root->mController->addActionFilter()する必要がありそうです。

・preloadディレクトリを用意する
当たり前ではありますが、XOOPS_ROOT_PATH側にpreload/ディレクトリを掘る必要があります。

ただ、ROOT_PATH側である、というところが嫌らしい点で、せっかくのD3モジュールの売りである、ROOT_PATH側はアップデートしなくていい、というメリットが消えてしまいます。早めに、ROOT_PATH側にpreload/(class名).class.php を用意しておいた方が良いでしょう。もちろん中身はTRUST_PATH側を読み出しに行くだけのスケルトンで構いません。

意味あるロジックはすべてTRUST_PATH側で処理するのがD3モジュールの基本ですから。

・インストール/アップデート/アンインストール時のメッセージ出力
デリゲート
Legacy.Admin.Event.Module(Install|Update|Uninstall).Success
の第２パラメーターに、logオブジェクトが渡されます。

というわけで、$log->add( メッセージ ) ; するだけです！

minahitoさん、ありがとう。

2 comments

Related articles
Printer friendly page Send this story to a friend

Comments list

Re: D3 on Cube 2.1
GIJOE  Posted on 2006/9/5 16:36
Quote:
実はAlpha4-cでの変更なのですが「レンダーシステムが交換できる仕様なのに、 Legacy のインストーラが LegacyRender 固有のＤＢ流し込み処理を行うのはおかしい」という考え方から、ここもデリゲートに変わっているんです。ただ、関数自体を LegacyRender に移すと、 LegacyRender がインストールされてない状態で動作するセカンド・インストーラがテンプレートを流し込めなくなって動作不良になるんですよ（笑）(snip)
なるほど〜。
丁寧な説明ありがとうございます。

基本的にD3のキモは、Duplicatable化における最大のネックであるテーブルとテンプレートをonInstall/onUpdate/onUninstallで処理することなのですが、その両者ともがデリゲートでoverride出来るのなら、そんな怪しげな処理は要らないですよね。

ただ、本当に残念なのですが、そういう作りにしてしまうと、Cube2.1専用モジュールになってしまいます。それは私的には避けたいことなので、X2でもCube2.1でも動く仕掛け、となってonInstall等での処理になると思います。

もちろん、Cube2.1なら、admin/preload/*.class.php に処理を書いて、とやれば、処理分け自体はうまく行くのですが、インストーラについてまったく違うコードを２種類書く羽目になると、さすがに保守しきれません。

バリバリにCube2.1専用チューンされたモジュールを作ってみたい、という気持ちは山々なんですが
No title
minahito  Posted on 2006/9/5 11:35 | Last modified
あっ、そうだこれ、すみません、自分なりに D3 をまとめて GIJOE さんか suin さんに連絡しようと思ったのですが、できずじまいでした（汗

実はAlpha4-cでの変更なのですが「レンダーシステムが交換できる仕様なのに、 Legacy のインストーラが LegacyRender 固有のＤＢ流し込み処理を行うのはおかしい」という考え方から、ここもデリゲートに変わっているんです。ただ、関数自体を LegacyRender に移すと、 LegacyRender がインストールされてない状態で動作するセカンド・インストーラがテンプレートを流し込めなくなって動作不良になるんですよ（笑）

なので、「テンプレートのインストール工程をデリゲートしたうえで」「LegacyRender固有処理を内部のメンバ関数に持っていて、それを登録している」という状態になってます。

ああ、前置きが長くなった……
つまりどういうことかというと、 Legacy_ModuleInstaller.InstallTemplate のデリゲートで、「本来処理でテンプレートを挿入するタイミングと完全に同じタイミングで独自の処理を書ける」ということです。このタイミングで呼び出される処理で、
function D3_moduleinstalle(&$module, &$log)
{
  ...
  $log->addReport(...));
}
とすれば、ユーザー側からはテンプレートが無事インサートされたというログメッセージを他のモジュールのテンプレート報告と同じ位置（同じ順番というべきか）で見ることができるんですよ。また、 insertTable もデリゲートになっていますから、 Legacy_ModuleInstaller.InstallTable に自己関数を登録して自由にやって、正常にメッセージを書き出すことも可です。そのログメッセージはコアのものと全く同じにしてもいいし、 D3 独自のメッセージを出すのも独自処理って感じでいいですよね。(^^)

ま、動作的にはいずれも最後にまとめて行っていただいて構わないものばかりなんですが;;

Quote:
残念ながら、この仕掛けの後半部分は、複製可能モジュールには利用できないので、「(class名)のクラスを作らないこと」が重要です。クラスが存在したら、インスタンスが作られ、登録されてしまいます。

そうだった ... orz
View more comments...
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!