あっ、そうだこれ、すみません、自分なりに D3 をまとめて GIJOE さんか suin さんに連絡しようと思ったのですが、できずじまいでした(汗
実はAlpha4-cでの変更なのですが「レンダーシステムが交換できる仕様なのに、 Legacy のインストーラが LegacyRender 固有のDB流し込み処理を行うのはおかしい」という考え方から、ここもデリゲートに変わっているんです。ただ、関数自体を LegacyRender に移すと、 LegacyRender がインストールされてない状態で動作するセカンド・インストーラがテンプレートを流し込めなくなって動作不良になるんですよ(笑)
なので、「テンプレートのインストール工程をデリゲートしたうえで」「LegacyRender固有処理を内部のメンバ関数に持っていて、それを登録している」という状態になってます。
ああ、前置きが長くなった……
つまりどういうことかというと、 Legacy_ModuleInstaller.InstallTemplate のデリゲートで、「本来処理でテンプレートを挿入するタイミングと完全に同じタイミングで独自の処理を書ける」ということです。このタイミングで呼び出される処理で、
function D3_moduleinstalle(&$module, &$log)
{
...
$log->addReport(...));
}
とすれば、ユーザー側からはテンプレートが無事インサートされたというログメッセージを他のモジュールのテンプレート報告と同じ位置(同じ順番というべきか)で見ることができるんですよ。また、 insertTable もデリゲートになっていますから、 Legacy_ModuleInstaller.InstallTable に自己関数を登録して自由にやって、正常にメッセージを書き出すことも可です。そのログメッセージはコアのものと全く同じにしてもいいし、 D3 独自のメッセージを出すのも独自処理って感じでいいですよね。(^^)
ま、動作的にはいずれも最後にまとめて行っていただいて構わないものばかりなんですが;;
Quote:
残念ながら、この仕掛けの後半部分は、複製可能モジュールには利用できないので、「(class名)のクラスを作らないこと」が重要です。クラスが存在したら、インスタンスが作られ、登録されてしまいます。
そうだった ... orz
Quote:
実はAlpha4-cでの変更なのですが「レンダーシステムが交換できる仕様なのに、 Legacy のインストーラが LegacyRender 固有のDB流し込み処理を行うのはおかしい」という考え方から、ここもデリゲートに変わっているんです。ただ、関数自体を LegacyRender に移すと、 LegacyRender がインストールされてない状態で動作するセカンド・インストーラがテンプレートを流し込めなくなって動作不良になるんですよ(笑)(snip)
なるほど〜。
丁寧な説明ありがとうございます。
基本的にD3のキモは、Duplicatable化における最大のネックであるテーブルとテンプレートをonInstall/onUpdate/onUninstallで処理することなのですが、その両者ともがデリゲートでoverride出来るのなら、そんな怪しげな処理は要らないですよね。
ただ、本当に残念なのですが、そういう作りにしてしまうと、Cube2.1専用モジュールになってしまいます。それは私的には避けたいことなので、X2でもCube2.1でも動く仕掛け、となってonInstall等での処理になると思います。
もちろん、Cube2.1なら、admin/preload/*.class.php に処理を書いて、とやれば、処理分け自体はうまく行くのですが、インストーラについてまったく違うコードを2種類書く羽目になると、さすがに保守しきれません。
バリバリにCube2.1専用チューンされたモジュールを作ってみたい、という気持ちは山々なんですが