[XCL2.2]ユーザ管理を完全交換可能にするために
K. Ono
とりあえずここでは2.2でXCLのユーザー管理の完全入れ替えの実現に必要だと思われることを
書きます。
ユーザ側ではユーザ登録時やユーザ情報編集時にデリゲートで他の関数等に飛ばすことが
できますが、管理画面側では同様の機能が実装されていません。例えユーザ側のユーザ登録や
ユーザ編集で他のテーブルを使用するようにしたとしても、管理側で旧ユーザテーブルを
参照していては完全交換とはいかないので、管理側もデリゲートなりを使用して交換可能
にする必要があると思います。
そこでuserモジュールに手を入れることになると思います。今のところこのモジュールはグループ
管理もやっているので、まずはグループ管理の部分を「group」モジュール等として切り離す
ことでしょうか？おそらくユーザ管理を交換しても、グループ管理を交換する必要はないと
思います。グループ管理を交換するとなると、すでにグループのパーミッション機構（groupperm）
を使用している箇所が動かなくなりますので。grouppermさえも交換すれば良いのかもしれませんが、
それはかなり大掛かりになってしまうと思います。
あとはusersテーブルを参照している箇所が全て変更対象になります。例えばkernel/member.php
のXoopsMemberHandler::getUserCountByNoGroup()や、kernel/group.phpの
XoopsMembershipHandler::getUsersByNoGroup()です。この両メソッド、グループ管理で
使われていますけど、本当に必要でしょうか？
kernel/user.phpについては、XoopsMemberHandler::_uHandlerさえ交換できるようになれば
おそらく手を入れる必要はないと思います。ただ、直接XoopsUserHandlerをxoops_gethandlerで
取得して使用している場合は、その箇所をXoopsMemberHandler経由に変更する必要もあります。
XoopsUserHandlerを直接取得するのは本来意図されたものでもありませんので。
とりあえずこれくらいを把握しています。あとは、サードパーティ製モジュールで
直接usersテーブルを叩いたりしていると最悪です。その場合はそのモジュール開発者に
変更（handler経由にしてもらう等）をお願いするしかないですね。。
zanjibar
これが実現すると、XCL は、他のWebアプリとの連携がぐっと楽になります。
On 10月25日, 午前11:49, "K. Ono" <onok...@gmail.com> wrote:
> onokazuです。
>
> とりあえずここでは2.2でXCLのユーザー管理の完全入れ替えの実現に必要だと思われることを
> 書きます。
>
K. Ono
まずはXoopsMemberHandlerの整理から始めていければと思います。
ユーザ情報のCRUDの中でコアや他モジュールが必要になるのは
おそらくRだけだと思います。そこで下記の３つのメソッドは削除し、
userモジュールのaction等で同ロジックを組むべきかと思います。
function &createUser()
function deleteUser(&$user)
function insertUser(&$user)
下記メソッドはXCLで追加されたものだと思うのですが、
createUserがなくなることから下記も必要なくなるので削除
function delete(&$object)
下記の３メソッドは使用されていないみたいなので削除
function &loginUserMd5($uname, $md5pwd)
function activateUser(&$user)
function updateUsersByField($fieldName, $fieldValue, $criteria = null)
下記はコアではコメントの投稿数をユーザ情報に反映させるために
ところどころ使用されているので、deprecatedとして残すしかなさそうです。
function updateUserByField(&$user, $fieldName, $fieldValue)
各ユーザの投稿数に関しては、確かに便利なのですが、ユーザ管理を汎用化
するには今後は別の方法でこのような統計情報を管理取得できるような仕組みが
必要そうです。
下記メソッドはgroup管理で使用されているが、直接userテーブルにアクセス
している点が好ましくないため、このメソッドを使用しないようにgroup管理を
変更し、このメソッドを削除できればと思います。
function getUserCountByNoGroup($group_id)
2008/10/25 11:49 K. Ono <ono...@gmail.com>:
K. Ono
次に、XoopsMemberHandler::_uHandlerの代わりとなるものを
仮にXCube_IdentityFetcherとしてインタフェースを定義します。下記のような
かんじでいかがでしょう？
interface XCube_IdentityFetcher
{
/**
* @return XCube_Identity
*/
function fetchById($id);
/**
* @return array Array of XCube_Identity objects
*/
function fetchByIds($ids);
/**
* @return array Array of XCube_Identity objects
*/
function fetchByField($field, $value);
/**
* @return array Array of XCube_Identity objects
*/
function fetchByFields($fields);
/**
* @return array Array of XCube_Identity objects
*/
function fetchAll($limit, $offset, $sort, $order);
/**
* @return int
*/
function countAll();
/**
* @return string
*/
function getIdField();
/**
* @return string
*/
function getUsernameField();
/**
* @return string
*/
function getEmailField();
/**
* @return string
*/
function getNameField();
}
XoopsMemberHandlerは従来のようにXoopsUserHandlerを使用するのではなく、
XCube_IdentityFetcherを使用する感じになります。
なのでもちろん、XoopsUserHandlerもXCube_IdentityFetcherの実装が必要になります。後で
XCube_IdentityFetcherを実装したXoopsUserHandlerと、XCube_IdentityFetcherを使用する
XoopsMemberHandlerのコードをこちらに投稿したいと思います。
K. Ono
XCube_Identityへのメソッド追加の提案も忘れていました。今のところ、ユーザ名しか取得
できませんが、他に下記くらいは追加しても良いと思うのですが、いかがでしょうか？
表示名
メールアドレス
パスワード
パスワードなんかは必要ないと思われるかもしれませんが、ユーザ管理を別のユーザ管理
システムへと移行させる時にやはりパスワードのデータも場合によっては必要になると思います。
一つのテーブルからもう一つのテーブルへSQLでやってしまっても良いのかもしれませんが、
結局はまたマッピングする必要が出てくるので。。最低限、上記さえ取得できればマッピング
なしに移行ができるのではと思います。
Minahito
お疲れさまです。
レスできなくてすみません。
（ToDo上から順番に片付け中……）
交換の仕組みは基本的にいけそうですね。若干気になっている部分はある
のですが、非常に細かいことなので週末に時間ができた時にレスします。
最近平日は全然だめです。すみません。orz
On 2008/11/07, at 23:58, "K. Ono" <ono...@gmail.com> wrote:
>
> onokazuです。
>
> XCube_Identityへのメソッド追加の提案も忘れていました。今のとこ
> ろ、ユーザ名しか取得
> できませんが、他に下記くらいは追加しても良いと思うのですが、いか
> がでしょうか？
>
> 表示名
> メールアドレス
> パスワード
>
> パスワードなんかは必要ないと思われるかもしれませんが、ユーザ管理
> を別のユーザ管理
> システムへと移行させる時にやはりパスワードのデータも場合によって
> は必要になると思います。
>
> 一つのテーブルからもう一つのテーブルへSQLでやってしまって
> も良いのかもしれませんが、
> 結局はまたマッピングする必要が出てくるので。。最低限、上記さえ取
> 得できればマッピング
> なしに移行ができるのではと思います。
minahito
１通ずつ読み始めています。
> ユーザ側ではユーザ登録時やユーザ情報編集時にデリゲートで他の関数等に飛ばすことが
> できますが、管理画面側では同様の機能が実装されていません。例えユーザ側のユーザ登録や
> ユーザ編集で他のテーブルを使用するようにしたとしても、管理側で旧ユーザテーブルを
> 参照していては完全交換とはいかないので、管理側もデリゲートなりを使用して交換可能
> にする必要があると思います。
つまり、従来の 2.1 のスタンスでは、
「ユーザーモジュールというモジュールごと入れ替えてね！」
「Wii でいえば、標準のチャンネルを削除して、別のチャンネルを入れてね！」
という考え方だったが、大規模な開発となり、気楽とはいえないので、
「ユーザーモジュールはそのまま使ってね！
それに対応するコールバックを書いてね！」
というポリシーであれば more better ということですね。
> そこでuserモジュールに手を入れることになると思います。今のところこのモジュールはグループ
> 管理もやっているので、まずはグループ管理の部分を「group」モジュール等として切り離す
> ことでしょうか？おそらくユーザ管理を交換しても、グループ管理を交換する必要はないと
> 思います。グループ管理を交換するとなると、すでにグループのパーミッション機構（groupperm）
> を使用している箇所が動かなくなりますので。grouppermさえも交換すれば良いのかもしれませんが、
> それはかなり大掛かりになってしまうと思います。
モジュール化すればプログラマを分けられますし、いいですね。
UIで統合しているように見せかけられると思いますし。
この場合、
グループからユーザーのリストを得たい場合、
グループはユーザーのデータベースを知らないので、 SQL を発行することはできない、
という感じになるんでしょうか？
それともユーザーモジュールが持っているハンドラにグループの ID を投げて
そっちで検索してもらうので、それなりに効率よくいけるかな……
> あとはusersテーブルを参照している箇所が全て変更対象になります。例えばkernel/member.php
> のXoopsMemberHandler::getUserCountByNoGroup()や、kernel/group.phpの
> XoopsMembershipHandler::getUsersByNoGroup()です。この両メソッド、グループ管理で
> 使われていますけど、本当に必要でしょうか？
すみません、実はこのへん詳しくありません。
onokazu さんが一番詳しいと思います。
個人的な感覚では、
メンバーハンドラがハンドラ群の中では一番謎なハンドラで、
モジュール開発者の時代から、 X2 コアが使ってるからそのように使えば良いのか～
という感覚でしか使えていませんでした。
メンバーシップハンドラは、読み出せばリンク情報のテーブルの１行分の情報が帰って
くるので、分かりやすく使いやすかったのです。
基本的に XOOPS ハンドラは、読み出せば、どのテーブルの１行分のデータを返してく
れるのかが割とはっきりしていたのですが、メンバーハンドラのほうはそこがちょっと
分かりにくかったので、扱いづらい印象がありました。
> kernel/user.phpについては、XoopsMemberHandler::_uHandlerさえ交換できるようになれば
> おそらく手を入れる必要はないと思います。ただ、直接XoopsUserHandlerをxoops_gethandlerで
> 取得して使用している場合は、その箇所をXoopsMemberHandler経由に変更する必要もあります。
> XoopsUserHandlerを直接取得するのは本来意図されたものでもありませんので。
やばい……いっぱい使ってる…… user ハンドラ……
この「XoopsUserHandlerを直接取得するのは本来意図されたものでもありません」
というのは知らなかったのですが、
ソース内コメントにも特に何も書いていませんし、ほとんどの開発者は初耳なんじゃ
ないでしょうか？
（僕が知らないだけ！？）
仮にそうだとすれば、
「 user 取得してるプログラムは全部書き直し！」
って通告するんじゃなくて、なんか上手い方法を探したいところなのですが……
# まぁでも別レスで書きましたが、
# 旧 user mod を入れればハンドラもテーブルも X2 互換という環境を用意すれば、
# こっちはこれでもいいかもしれない。
X2 -> XCL 2.1 のときはマイグレーションガイドを書かなかったのですが、
今回は必要そうなので早めに場所を用意しておく必要がありそうですね。
メモメモ...
2008/10/25 11:49 K. Ono <ono...@gmail.com>:
>
--
minahito (mina...@gmail.com)
K. Ono
お忙しいところありがとうございます。
> つまり、従来の 2.1 のスタンスでは、
>
> 「ユーザーモジュールというモジュールごと入れ替えてね！」
> 「Wii でいえば、標準のチャンネルを削除して、別のチャンネルを入れてね！」
>
> という考え方だったが、大規模な開発となり、気楽とはいえないので、
>
> 「ユーザーモジュールはそのまま使ってね！
> それに対応するコールバックを書いてね！」
>
> というポリシーであれば more better ということですね。
そうですね、結局はそのような方向に落ち着きそうです。互換性も
考えると、多少は互換性を捨てるにしても2.2でもちょっと厳しいかも
しれません。
> この場合、
> グループからユーザーのリストを得たい場合、
> グループはユーザーのデータベースを知らないので、 SQL を発行することはできない、
> という感じになるんでしょうか？
はい、直にSQL発行はないと思います。
グループはユーザのデータ元は知りませんが、グループとユーザとの関連付けを
管理するためにユーザIDの一覧を自由に取得したり、ユーザIDを介してユーザの
詳細情報の取得ができさえすればよいのではと思います。その媒介にはやはり
XCube_Identityのようなものが適していると思います。
>> あとはusersテーブルを参照している箇所が全て変更対象になります。例えばkernel/member.php
>> のXoopsMemberHandler::getUserCountByNoGroup()や、kernel/group.phpの
>> XoopsMembershipHandler::getUsersByNoGroup()です。この両メソッド、グループ管理で
>> 使われていますけど、本当に必要でしょうか？
>
> すみません、実はこのへん詳しくありません。
> onokazu さんが一番詳しいと思います。
すいません、ちょっと記憶がないです^^;
グループに属さないユーザを取得したりする処理を書いた覚えはあるのですが、
それをハンドラに書いたかどうかはちょっと分かりません。
> 個人的な感覚では、
> メンバーハンドラがハンドラ群の中では一番謎なハンドラで、
> モジュール開発者の時代から、 X2 コアが使ってるからそのように使えば良いのか～
> という感覚でしか使えていませんでした。
memberハンドラは確かに少し目的が見えにくいですね。ユーザハンドラに直接
触らせないようにすることで、将来的な交換を考えていたのかな？とも思いましたが
そんな記憶もありませんし、当時はそんなこと考えることができたとも思えません^^;
今となってはuserハンドラに色々な開発者がメソッドを追加してしまっていたので、
ほんとに今更かもしれませんが、元々userハンドラでできることはmemberハンドラ
でもできる構成になっていたと思います。
>> kernel/user.phpについては、XoopsMemberHandler::_uHandlerさえ交換できるようになれば
>> おそらく手を入れる必要はないと思います。ただ、直接XoopsUserHandlerをxoops_gethandlerで
>> 取得して使用している場合は、その箇所をXoopsMemberHandler経由に変更する必要もあります。
>> XoopsUserHandlerを直接取得するのは本来意図されたものでもありませんので。
>
> やばい……いっぱい使ってる…… user ハンドラ……
>
> この「XoopsUserHandlerを直接取得するのは本来意図されたものでもありません」
> というのは知らなかったのですが、
> ソース内コメントにも特に何も書いていませんし、ほとんどの開発者は初耳なんじゃ
> ないでしょうか？
> （僕が知らないだけ！？）
>
> 仮にそうだとすれば、
> 「 user 取得してるプログラムは全部書き直し！」
> って通告するんじゃなくて、なんか上手い方法を探したいところなのですが……
そうですね、、先の投稿の後に色々なモジュールも調べましたがかなり使われて
いましたので。。やはり互換性を考えると少し難しいかもしれません。
2.1で作っていただいたユーザ関連のデリゲートでもかなりの拡張ができる（ユーザ管理の交換
はできませんが）ので、Legacyではユーザデータの管理の交換はできなくても良い
のかもしれないと思い始めています。