ユーザ関連デリゲートに関して
K. Ono
先日、日本サイトにユーザ管理の改良版を導入しましたが、いくつか
困っていることがあります。
1. XCube_Controller::mSetupUserのようなデリゲートは、登録デリゲートが複数あると困る。
複数のデリゲートが登録されていても、プライオリティで実行順の設定はできますが、
複数のデリゲートがXCUBE_DELEGATE_PRIORITY_FIRSTを指定していた場合、
自分の登録デリゲートが一番最初に実行されるとは限りません。
このデリゲートの性質上、複数のデリゲートが実行されてしまうと正常にカレント
ユーザを初期化できない場合があるので、かなり困ります。仕方ないので、一度
XCube_Controller::mSetupUserの登録デリゲートをクリアし、その上で
XCUBE_DELEGATE_PRIORITY_FIRSTで登録していますが、他プリロード等によって
これを更に上書きされてしまう場合も考えられるので、あまり良い対応策ではないと
思っています。
2. Site.Closeのような名称のサイト閉鎖用デリゲートが欲しい
サイトの閉鎖はXCube_Controller::mSetupUserおよびSite.CheckLogin.Successデリゲートで
実現しています。ただ、XCube_Controller::mSetupUserへと登録したデリゲート
（Legacy_SiteClose::callbackCheckLoginSuccess()）で、$controller->checkLogin()および
$controller->logout()の呼び出しがハードコードされています。
これらのメソッドはLegacypage.User.Access時にも呼ばれます。通常の場合はこれでも良いのですが、
モジュール側で通常のLegacypage.User.Accessをオーバーライドしていて、これらのメソッドに全く
依存していない場合には困ります。
そこでLegacypage.User.Accesのように、ロジックを全てオーバーライドできるような
デリゲートが欲しいと思います。
とりあえず今のところのこちらの対応策は、サイト閉鎖が有効であるかをプリロードでチェックし、
有効の場合には強制的に他ページへと飛ばすようなことをやっています。
zanjibar
機能の中に、簡単に変更できるものとそうでないものがあったほうがいいというわけですね。
minahito さんの考えでは、どうなんでしょうか？
デリゲートを登録するコードを書く人が気をつければいいともいえますけど
mSetupUser は、開発中なんで、
いいかげんでもいいや状態のでうごかしたい場合もあるといえます。
minahito
> 1. XCube_Controller::mSetupUserのようなデリゲートは、登録デリゲートが複数あると困る。
たぶん user module のことだと思うのですが、
site_custom.ini.php で標準設定である「user モジュールの各デリゲートへの登録」を行う
プリロードを切ってしまえば、ひとまずバッティングはなくなると思います。
[Legacy.PrimaryPreloads]
User_PrimaryFilter=
（右側になにも書かない）
これで user モジュール系のデリゲート登録は全部行われなくなります。
あとは必要なデリゲート登録を行うプリロードを書いて放り込んでおけば、
とりあえず 2.1.6 でも何とかなるんじゃないかと。
2.2 で既に話が出ていますが、
今後、考えなくてはいけないのは、
「user module のオブジェクト生成プロセスなどは使用しないが、
user module 自体は続けて使用するケース」
ですね。。。
2.1.0 を作ってるときは、正面切ってカスタマイズされる場合は、
user module はアンインストールされるだろうから問題なかろうと踏んでて、
user module 相当のモジュール開発は面倒なので管理部分は続けて使いたい
というような流れをまったく想定してませんでした。
2.1 添付の user module は「入り口から出口まで全てワタクシめが」という
主旨のモジュールなので、
その点、限界があると思うので、
だましだまし使っていって 2.2 の new user module で出来るだけ部分差し替え
を担保するしかないかなと思ってます。
> 2. Site.Closeのような名称のサイト閉鎖用デリゲートが欲しい
これは何か方法を考えてみます。
サイトクローズはセカンドインストーラとも関連があるので、一部 Legacy_Controller と
べったりなところはあります。;;
--
minahito (mina...@gmail.com)
minahito
> 機能の中に、簡単に変更できるものとそうでないものがあったほうがいいというわけですね。
> minahito さんの考えでは、どうなんでしょうか？
過去何度か書きましたが、
user module 全体で「簡単に変更できるもの」という発想で作りました。
user module は xoops_user べったりな XOOPS 認証と XOOPS2 互換ユーザー機能を
担うモジュールなので、
「互換機能が利用されないときは、
モジュールごとアンインストールされるだろうＪＫ」
くらいに考えてました。 orz
認証部のデリゲートも
BASIC 認証を追記するくらいなら、デリゲートのマルチキャストががっちり活用できる
から便利でしょくらいに思ってたんですが。
ちょろっと単純に認証方法を追加するレベルの Tweaking と、
本来 module をぶっこぬいて欲しいレベルの Cofigration の、
両方のケースで user module が使われ続けてるのが今の状況です。
いぁ、
2.1.0 をリリースした直後くらいに LDAP 認証モジュールの開発者と話をして、
「やべー、意外とみんな user module 抜かねー」
とは思ってたんですが;;
今は "状況了解" です。
ただ、これ 2.2 の new user module で出来るだけ対応しましょうと言っても、
やっぱり限度はあると思うんですよ。
こういう交換可能性ってケース想定ばっかりしてるときりがないし。
仮想関数系に依存した交換可能性は速度低下を招くし（泣）
まして仮想関数のつなぎ合わせの権利はユーザーにあるわけですしね。
やればやるだけコンフィグレーションが複雑になって...
そういう意味では、
単体で淡々と動くモジュール(2.1)と、
ある程度想定されるモジュールと協調するモジュール（2.2）、
プログラムの書けるサイトオーナーの素材となるようなモジュール
（↑単体で動かなくてもいいくらい）
の３種くらいにブランチしてコミュニティの場に登場すれば完璧だと
思ってます。
あと、 2.2 はバッティングするかもしれない部分は
デリゲートの使用を抑えるのがよさそうですね。。
# 2.1 のは 2.1 との互換性もあるので 2.2 でもこのままにせざるをえないけど
--
minahito (mina...@gmail.com)
K. Ono
> たぶん user module のことだと思うのですが、
> site_custom.ini.php で標準設定である「user モジュールの各デリゲートへの登録」を行う
> プリロードを切ってしまえば、ひとまずバッティングはなくなると思います。
>
> [Legacy.PrimaryPreloads]
> User_PrimaryFilter=
そうですか、やはりiniファイルを設定する必要ありですか。
ただ、userモジュール以外のプリロードでもユーザ関連デリゲートを登録
している場合も結構あると思うのですが、その場合には自モジュールの
プリロードを上記プライマリに書くことになるのでしょうか。
また、自モジュールのプリロードが先に実行されたとしても、他モジュールが
プリロードで更にデリゲートを登録したりもできるので、その辺り制御できる
方法（更にデリゲートを追加できないようにロックする機能をつけたり？）が
あれば便利だなと思います。
>> 2. Site.Closeのような名称のサイト閉鎖用デリゲートが欲しい
>
> これは何か方法を考えてみます。
よろしくお願いします。
minahito
あけましておめでとうございます。
> また、自モジュールのプリロードが先に実行されたとしても、他モジュールが
> プリロードで更にデリゲートを登録したりもできるので、その辺り制御できる
> 方法（更にデリゲートを追加できないようにロックする機能をつけたり？）が
> あれば便利だなと思います。
排他ロックはありなのですが、
その "ロックしている存在" が邪魔になったときに、結局同じ事が起こるので
--------
（シミュレーション↓）
「他モジュールがプリロードで自分より先にロックをかけてしまうので、
この辺り制御する方法が欲しい」
--------
「コンポーネントのコンストラクション」はプログラムのコード内ではなく、
外部の設定でコントロールしたほうが現実的だと思ったのですが、、、
まぁでも、、、そうか、、、
たとえば僕の書いた排他ロックのプログラムと、
onokazu さんが配った排他ロックのプログラムを、
同時にインストールしたユーザーさんは、
そこに書かれたプライオリティでどっちが勝つか決まるから、
どっちかをアンインストールしなければいけなくなる。
元々排他関係だから、これでいいのか。
惜しむらくは、
最初のレスで書いた、
「もともと相乗するつもりの機能」も全部排除されちゃうことですけど、
これもよく考えると、
まずは排他機能を用いて、開発やさくっと配るときに使ってもらって、
あとは何らかの推奨方法（iniに設定を書いて優先度をコントロール出来る
ようにして、ハイエンドユーザーさんがチューニングできるような実装方
法）を、後からじっくり実装してもらう……とかで良さそうですね。
それを積むかどうかもモジュール作者の暇次第という感じで。
# 排他機能を実際には使えないデリゲートマネージャを構成設定で指名する
# 方法もあるし、都合に合わせてどうとでもできそうですね。
2009/01/01 13:16 K. Ono <ono...@gmail.com>:
--
minahito (mina...@gmail.com)
K. Ono
本年もよろしくお願いします。
> 惜しむらくは、
> 最初のレスで書いた、
> 「もともと相乗するつもりの機能」も全部排除されちゃうことですけど、
そうですね、排他ロックの機能を追加するのは現在の仕様に対応するための苦肉
の策だと思います。
デリゲートに関して以前にも書いたと思うのですが、デリゲートの中でも
「もともと相乗するつもりの機能」と「もともと相乗すべきでない機能」とがあると
思うんです。例えば前者はChecklogin.Successデリゲートとかで、後者は
Checkloginデリゲート。
現在のデリゲートの仕様はどちらかというと前者のデリゲートのためのものなので、
後者を実現するには排他ロック等の対応を取らざるを得ないですが、これらを別物
として取り扱うのも一つの案かと。
個別デリゲートへの対応であれば今のままでも良いのかもしれませんが、
ユーザモジュールの換装という程のレベルになってくると、一つのデリゲートが
正常に動作しないとユーザモジュール全体として機能しなくなることがありますので。。
とりあえずは、ユーザにインストールしてもらう場合にはiniファイルの設定と、
競合する可能性のあるモジュールの告知で対応しようかと思います。