とりあえずここでは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を直接取得するのは本来意図されたものでもありませんので。

On 10月25日, 午前11:49, "K. Ono" <onok...@gmail.com> wrote:

まずは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 <onok...@gmail.com>:

次に、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();

XCube_Identityへのメソッド追加の提案も忘れていました。今のところ、ユーザ名しか取得
できませんが、他に下記くらいは追加しても良いと思うのですが、いかがでしょうか？

表示名
メールアドレス
パスワード

パスワードなんかは必要ないと思われるかもしれませんが、ユーザ管理を別のユーザ管理
システムへと移行させる時にやはりパスワードのデータも場合によっては必要になると思います。

交換の仕組みは基本的にいけそうですね。若干気になっている部分はある
のですが、非常に細かいことなので週末に時間ができた時にレスします。

最近平日は全然だめです。すみません。orz

On 2008/11/07, at 23:58, "K. Ono" <onok...@gmail.com> wrote:

「ユーザーモジュールというモジュールごと入れ替えてね！」
「Wii でいえば、標準のチャンネルを削除して、別のチャンネルを入れてね！」

という考え方だったが、大規模な開発となり、気楽とはいえないので、

「ユーザーモジュールはそのまま使ってね！
　それに対応するコールバックを書いてね！」

というポリシーであれば more better ということですね。

この場合、
グループからユーザーのリストを得たい場合、
グループはユーザーのデータベースを知らないので、 SQL を発行することはできない、
という感じになるんでしょうか？

それともユーザーモジュールが持っているハンドラにグループの ID を投げて
そっちで検索してもらうので、それなりに効率よくいけるかな……

個人的な感覚では、
メンバーハンドラがハンドラ群の中では一番謎なハンドラで、
モジュール開発者の時代から、 X2  コアが使ってるからそのように使えば良いのか～
という感覚でしか使えていませんでした。

メンバーシップハンドラは、読み出せばリンク情報のテーブルの１行分の情報が帰って
くるので、分かりやすく使いやすかったのです。

基本的に XOOPS ハンドラは、読み出せば、どのテーブルの１行分のデータを返してく
れるのかが割とはっきりしていたのですが、メンバーハンドラのほうはそこがちょっと
分かりにくかったので、扱いづらい印象がありました。

この「XoopsUserHandlerを直接取得するのは本来意図されたものでもありません」
というのは知らなかったのですが、
ソース内コメントにも特に何も書いていませんし、ほとんどの開発者は初耳なんじゃ
ないでしょうか？
（僕が知らないだけ！？）

仮にそうだとすれば、
「 user 取得してるプログラムは全部書き直し！」
って通告するんじゃなくて、なんか上手い方法を探したいところなのですが……

# まぁでも別レスで書きましたが、
# 旧 user mod を入れればハンドラもテーブルも X2 互換という環境を用意すれば、
# こっちはこれでもいいかもしれない。

X2 -> XCL 2.1 のときはマイグレーションガイドを書かなかったのですが、
今回は必要そうなので早めに場所を用意しておく必要がありそうですね。
メモメモ...

2008/10/25 11:49 K. Ono <onok...@gmail.com>:

グループはユーザのデータ元は知りませんが、グループとユーザとの関連付けを
管理するためにユーザIDの一覧を自由に取得したり、ユーザIDを介してユーザの
詳細情報の取得ができさえすればよいのではと思います。その媒介にはやはり
XCube_Identityのようなものが適していると思います。

今となってはuserハンドラに色々な開発者がメソッドを追加してしまっていたので、
ほんとに今更かもしれませんが、元々userハンドラでできることはmemberハンドラ
でもできる構成になっていたと思います。