PEAK XOOPS - Cube 2.1 friendly code for D3 module 
XOOPS
XOOPS : Cube 2.1 friendly code for D3 module
- How to identify Cube2.1
if( defined( 'XOOPS_CUBE_LEGACY' ) ) {class_exists('XCUBE_ROOT') cannot distinguish Shade and Cube 2.1
- add preload/(class).class.php into ROOT_PATH side
D3 module should prepare preload/(class).class.php for the future.
Of course the file should be just a wrapper for TRUST_PATH side.
- outputs messages into oninstall/onupdate/onuninstall
You can use $log object as the second parameter of delegate ...
Legacy.Admin.Event.Module(Install|Update|Uninstall).Success
Thank you minahito!
Related articles
- Compatibility between D3 modules and Cube2.1 alpha4 (2006-08-09 07:10:34)
- Compatibility between D3 and Cube2.1 (2006-07-19 05:05:52)
Comments list
GIJOE
Posted on 2006/9/5 16:36
Quote:なるほど〜。
丁寧な説明ありがとうございます。
基本的にD3のキモは、Duplicatable化における最大のネックであるテーブルとテンプレートをonInstall/onUpdate/onUninstallで処理することなのですが、その両者ともがデリゲートでoverride出来るのなら、そんな怪しげな処理は要らないですよね。
ただ、本当に残念なのですが、そういう作りにしてしまうと、Cube2.1専用モジュールになってしまいます。それは私的には避けたいことなので、X2でもCube2.1でも動く仕掛け、となってonInstall等での処理になると思います。
もちろん、Cube2.1なら、admin/preload/*.class.php に処理を書いて、とやれば、処理分け自体はうまく行くのですが、インストーラについてまったく違うコードを２種類書く羽目になると、さすがに保守しきれません。
バリバリにCube2.1専用チューンされたモジュールを作ってみたい、という気持ちは山々なんですが
実は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専用チューンされたモジュールを作ってみたい、という気持ちは山々なんですが
minahito
Posted on 2006/9/5 11:35 | Last modified
あっ、そうだこれ、すみません、自分なりに D3 をまとめて GIJOE さんか suin さんに連絡しようと思ったのですが、できずじまいでした（汗
実はAlpha4-cでの変更なのですが「レンダーシステムが交換できる仕様なのに、 Legacy のインストーラが LegacyRender 固有のＤＢ流し込み処理を行うのはおかしい」という考え方から、ここもデリゲートに変わっているんです。ただ、関数自体を LegacyRender に移すと、 LegacyRender がインストールされてない状態で動作するセカンド・インストーラがテンプレートを流し込めなくなって動作不良になるんですよ（笑）
なので、「テンプレートのインストール工程をデリゲートしたうえで」「LegacyRender固有処理を内部のメンバ関数に持っていて、それを登録している」という状態になってます。
ああ、前置きが長くなった……
つまりどういうことかというと、 Legacy_ModuleInstaller.InstallTemplate のデリゲートで、「本来処理でテンプレートを挿入するタイミングと完全に同じタイミングで独自の処理を書ける」ということです。このタイミングで呼び出される処理で、
とすれば、ユーザー側からはテンプレートが無事インサートされたというログメッセージを他のモジュールのテンプレート報告と同じ位置（同じ順番というべきか）で見ることができるんですよ。また、 insertTable もデリゲートになっていますから、 Legacy_ModuleInstaller.InstallTable に自己関数を登録して自由にやって、正常にメッセージを書き出すことも可です。そのログメッセージはコアのものと全く同じにしてもいいし、 D3 独自のメッセージを出すのも独自処理って感じでいいですよね。(^^)
ま、動作的にはいずれも最後にまとめて行っていただいて構わないものばかりなんですが;;
Quote:
そうだった ... orz
実はAlpha4-cでの変更なのですが「レンダーシステムが交換できる仕様なのに、 Legacy のインストーラが LegacyRender 固有のＤＢ流し込み処理を行うのはおかしい」という考え方から、ここもデリゲートに変わっているんです。ただ、関数自体を LegacyRender に移すと、 LegacyRender がインストールされてない状態で動作するセカンド・インストーラがテンプレートを流し込めなくなって動作不良になるんですよ（笑）
なので、「テンプレートのインストール工程をデリゲートしたうえで」「LegacyRender固有処理を内部のメンバ関数に持っていて、それを登録している」という状態になってます。
ああ、前置きが長くなった……
つまりどういうことかというと、 Legacy_ModuleInstaller.InstallTemplate のデリゲートで、「本来処理でテンプレートを挿入するタイミングと完全に同じタイミングで独自の処理を書ける」ということです。このタイミングで呼び出される処理で、
function D3_moduleinstalle(&$module, &$log)
{
...
$log->addReport(...));
}
ま、動作的にはいずれも最後にまとめて行っていただいて構わないものばかりなんですが;;
Quote:
残念ながら、この仕掛けの後半部分は、複製可能モジュールには利用できないので、「(class名)のクラスを作らないこと」が重要です。クラスが存在したら、インスタンスが作られ、登録されてしまいます。
そうだった ... orz
Login