XoopsGuestUserクラスについて
投稿者: might | 投稿日時: 2005-9-12 23:57 | 閲覧: 5356回
xoopsのソースコードを見ていて、
is_object($xoopsUser)
とか
$xoopsUser == ""
とかが非常に気になっています。
片や/kernel/users.phpファイルにはXoopsGuestUserクラスがXoopsUserのNullクラスが定義されていますが活用されていません。
ちゃんとXoopsGustUserクラスを活用すれば、下記のような教科書に出てそうなコード
if(is_object($xoopsUser)){
$uid = $xoopsUser->getVar("uid");
} else {
$uid = 0;
}
は
$uid = $xoopsUser->getVar("uid");
に集約できると思いませんか？
ということでXoopsGuestUserクラスを実装してみました。
見た限りでは動いているようです。
もちろん既存のコードは使えなくなる可能性はありますし、すべてのケースでif文が排除できるわけではありません。
ですが将来のことを考えると、少なくとも
if(is_object($xoopsUser))
よりかは
if(!$xoopsUser->isGuest())
の方がよっぽど可読性が高いのではないかと考えています。
同じことがXoopsGroupクラス、XoopsModuleクラスなどにも言えると思いますので、後ほどそれぞれ実装してみたいと思います。
is_object($xoopsUser)
とか
$xoopsUser == ""
とかが非常に気になっています。
片や/kernel/users.phpファイルにはXoopsGuestUserクラスがXoopsUserのNullクラスが定義されていますが活用されていません。
ちゃんとXoopsGustUserクラスを活用すれば、下記のような教科書に出てそうなコード
if(is_object($xoopsUser)){
$uid = $xoopsUser->getVar("uid");
} else {
$uid = 0;
}
は
$uid = $xoopsUser->getVar("uid");
に集約できると思いませんか？
ということでXoopsGuestUserクラスを実装してみました。
見た限りでは動いているようです。
もちろん既存のコードは使えなくなる可能性はありますし、すべてのケースでif文が排除できるわけではありません。
ですが将来のことを考えると、少なくとも
if(is_object($xoopsUser))
よりかは
if(!$xoopsUser->isGuest())
の方がよっぽど可読性が高いのではないかと考えています。
同じことがXoopsGroupクラス、XoopsModuleクラスなどにも言えると思いますので、後ほどそれぞれ実装してみたいと思います。
コメント(3)
新しいものから |
古いものから |
ネスト表示 |
Re: XoopsGuestUserクラスについて
投稿者: minahito | 投稿日時: 2005-9-13 0:16
引用：
はい、しかし、互換性のために $xoopsUser に関してはこのままいくしかないと思っています。過去、これで判定を取るしかなかった時代のコードがここをアテにしている以上、ここの判定が変わると大混乱を招きかねません。
$xoopsUser は下位互換性のために残しておき、新しいユーザー情報取得手段を提供することになると思います。
X2 の問題のあるコードはおおむね把握しており、ほぼ全コードを書き直す予定で動いています。
もはや、少々使い勝手を直してどうにかなるレベルではありません。orz ＞ X2
少し弄る程度で、根本的なコードの気持ちよさが改善されず、かつ、下位互換性を失うのであれば、現状のものは下位互換性に残しておいて、別の名前空間、別体系としてのコードを加えていく、という開発が今後の主なコンセプトになっています。
ですが将来のことを考えると、少なくとも
if(is_object($xoopsUser))
よりかは
if(!$xoopsUser->isGuest())
の方がよっぽど可読性が高いのではないかと考えています。
はい、しかし、互換性のために $xoopsUser に関してはこのままいくしかないと思っています。過去、これで判定を取るしかなかった時代のコードがここをアテにしている以上、ここの判定が変わると大混乱を招きかねません。
$xoopsUser は下位互換性のために残しておき、新しいユーザー情報取得手段を提供することになると思います。
X2 の問題のあるコードはおおむね把握しており、ほぼ全コードを書き直す予定で動いています。
もはや、少々使い勝手を直してどうにかなるレベルではありません。orz ＞ X2
少し弄る程度で、根本的なコードの気持ちよさが改善されず、かつ、下位互換性を失うのであれば、現状のものは下位互換性に残しておいて、別の名前空間、別体系としてのコードを加えていく、という開発が今後の主なコンセプトになっています。
Re: XoopsGuestUserクラスについて
投稿者: might | 投稿日時: 2005-9-15 22:57
[blockquote]
はい、しかし、互換性のために $xoopsUser に関してはこのままいくしかないと思っています。過去、これで判定を取るしかなかった時代のコードがここをアテにしている以上、ここの判定が変わると大混乱を招きかねません。
[/blockquote]
このあたりはやり方次第では？
たとえば新しい方法（手段）を使うファイルでは何かのシンボル（たとえばXOOPS_NEW_FRAMEWORKとか）をdefineして、ライブラリ内部でその値に応じて条件分岐させるとかすればよいかと。
もちろん最終的にはそれらは削除されることになるんですけど。
違う名前空間でやろうとすると、全体の複雑さが増大して破綻してしまうような気がします。
根本的に書き換えていくのも良いと思うんですけど、リファクタリングを少しずつ進めていくのも手だと思うんですよね。
はい、しかし、互換性のために $xoopsUser に関してはこのままいくしかないと思っています。過去、これで判定を取るしかなかった時代のコードがここをアテにしている以上、ここの判定が変わると大混乱を招きかねません。
[/blockquote]
このあたりはやり方次第では？
たとえば新しい方法（手段）を使うファイルでは何かのシンボル（たとえばXOOPS_NEW_FRAMEWORKとか）をdefineして、ライブラリ内部でその値に応じて条件分岐させるとかすればよいかと。
もちろん最終的にはそれらは削除されることになるんですけど。
違う名前空間でやろうとすると、全体の複雑さが増大して破綻してしまうような気がします。
根本的に書き換えていくのも良いと思うんですけど、リファクタリングを少しずつ進めていくのも手だと思うんですよね。
Re: XoopsGuestUserクラスについて
投稿者: minahito | 投稿日時: 2005-9-16 10:12
引用：
いやー、いろいろ難しいと思います。
もちろん、おっしゃられる define に関しては、色んな方法が考えられますよ、といううちのなかの、おひとつに過ぎないと思いますけど、
これが define 値に応じて common.php 内における $xoopsUser の注入値を変えるという意味ならば、ページコントローラ特有の問題で、新方式のページに出力している旧方式のままのモジュールのブロックの動作保証ができなくなります。サードパーティ製の Smarty plugin のうち global $xoopsUser を見ているプログラムの動作もそのページコントローラによる処理の際は保証できません。そういうカスタムブロックを使っているユーザーにも書き直しを迫ることになります。
しかし作者も活動を終えてしまっていることが多いですから、リファクタリングに必須であるテストに加えて、そういったプログラムを引き取ってメンテする必要も出てきてしまいます。
それを誰がやるのか。混乱なくできるか等々もあり、
また、現行の開発者に対応をお願いするのもなかなか難しい。
リファクタリングを歓迎する人もいれば、本質的な対応を後手にして混乱を起こしているだけだと怒る人もいると思います。コアのコードは技術的観点からいけば価値はまったくありませんから、それが微細に訂正されるたびにモジュール開発者とユーザーに変更を強いる。しかし目指すべき形はそれらを何度も何度も繰り返した先にある……ということだと、あくまでこれは主観的な意見に過ぎませんが、ついてくる人はいなくなるんじゃないかという気がします。
新方式ではグローバル空間を使わずに getter を通じて取得するようにしたほうがいいかと思ってます。別空間、ということになっちゃうわけですけど。
引用：
どうでしょうか、破綻を呼ぶほどの複雑さではないと思います。
といいますのも、 global $xoopsUser もなにがしかの値を得るための手続きだと考えれば、旧方式を廃止するが deprecated とし、新方式への移行が終わるまで互換性保持のためにキープしておくというのは十分セオリーの範囲内に収まっていると感じるのです。
また、 XoopsObject クラス自体が非推奨になる（廃止計画）ことが決まっていますので、 XoopsUser 等も非推奨になります（アダプトしますけど）。そういった流れの中で新クラスのインスタンスを得るための手続き方法を追加することになると思うので、ログイン時であれば同値を取得する方法が２種類になってしまうということにはならないと思います。
後方互換のための手段を残しておくことは、あらゆるシステムに見られることであり、複雑かもしれませんが業のようなものだとも思っています。いずれにせよコードと見通しは綺麗にしておきたいですね。
引用：
はい、
自分はコア全体のリファクタリングではテスト込みで１年はかかるんじゃないかと思っていて、ＰＨＰ４ベースでそこまで時間をかけている場合ではない、１００％書き換えたほうが早いという立場を取っていますが、リファクタリングで進めるところも必ず出てくるとは思います。
また自分が取り組んでいる作業もコアの正式な作業ではありません。先の書き込みであたかも決定事項のように書いてしまいましたが、
自分も最初はリファクタリング派でした。その際、部分改編で論じていても始まらないと思って、それが累積してコア全体が改編された時の影響度と回避策をレポートできないかと作業している途中で、リファクタにせよどのみち丸ごと書き直すのだからＧＰＬから抜けるチャンスだと気づいて、フルスクラッチに切り替えたものです。
XoopsObject の後継コンテナが決まっていないことや、Cube に部分的に提唱されている DI 技術の実装面で Cube の計画と合致していない部分も多く、Cube へのフィードバック量はまだ決まってません。
でもこの作業とレポートが終われば具体的な実装に関わる議論に弾みがつくと勝手に思いこんでます。
ゲストの扱いの話でここまで話ができるのですから、それが全体量になれば具体的に 2.1 later 版への話が進んでいくと思います。
たとえば新しい方法（手段）を使うファイルでは何かのシンボル（たとえばXOOPS_NEW_FRAMEWORKとか）をdefineして、ライブラリ内部でその値に応じて条件分岐させるとかすればよいかと。
もちろん最終的にはそれらは削除されることになるんですけど。
いやー、いろいろ難しいと思います。
もちろん、おっしゃられる define に関しては、色んな方法が考えられますよ、といううちのなかの、おひとつに過ぎないと思いますけど、
これが define 値に応じて common.php 内における $xoopsUser の注入値を変えるという意味ならば、ページコントローラ特有の問題で、新方式のページに出力している旧方式のままのモジュールのブロックの動作保証ができなくなります。サードパーティ製の Smarty plugin のうち global $xoopsUser を見ているプログラムの動作もそのページコントローラによる処理の際は保証できません。そういうカスタムブロックを使っているユーザーにも書き直しを迫ることになります。
しかし作者も活動を終えてしまっていることが多いですから、リファクタリングに必須であるテストに加えて、そういったプログラムを引き取ってメンテする必要も出てきてしまいます。
それを誰がやるのか。混乱なくできるか等々もあり、
また、現行の開発者に対応をお願いするのもなかなか難しい。
リファクタリングを歓迎する人もいれば、本質的な対応を後手にして混乱を起こしているだけだと怒る人もいると思います。コアのコードは技術的観点からいけば価値はまったくありませんから、それが微細に訂正されるたびにモジュール開発者とユーザーに変更を強いる。しかし目指すべき形はそれらを何度も何度も繰り返した先にある……ということだと、あくまでこれは主観的な意見に過ぎませんが、ついてくる人はいなくなるんじゃないかという気がします。
新方式ではグローバル空間を使わずに getter を通じて取得するようにしたほうがいいかと思ってます。別空間、ということになっちゃうわけですけど。
引用：
違う名前空間でやろうとすると、全体の複雑さが増大して破綻してしまうような気がします。
どうでしょうか、破綻を呼ぶほどの複雑さではないと思います。
といいますのも、 global $xoopsUser もなにがしかの値を得るための手続きだと考えれば、旧方式を廃止するが deprecated とし、新方式への移行が終わるまで互換性保持のためにキープしておくというのは十分セオリーの範囲内に収まっていると感じるのです。
また、 XoopsObject クラス自体が非推奨になる（廃止計画）ことが決まっていますので、 XoopsUser 等も非推奨になります（アダプトしますけど）。そういった流れの中で新クラスのインスタンスを得るための手続き方法を追加することになると思うので、ログイン時であれば同値を取得する方法が２種類になってしまうということにはならないと思います。
後方互換のための手段を残しておくことは、あらゆるシステムに見られることであり、複雑かもしれませんが業のようなものだとも思っています。いずれにせよコードと見通しは綺麗にしておきたいですね。
引用：
根本的に書き換えていくのも良いと思うんですけど、リファクタリングを少しずつ進めていくのも手だと思うんですよね。
はい、
自分はコア全体のリファクタリングではテスト込みで１年はかかるんじゃないかと思っていて、ＰＨＰ４ベースでそこまで時間をかけている場合ではない、１００％書き換えたほうが早いという立場を取っていますが、リファクタリングで進めるところも必ず出てくるとは思います。
また自分が取り組んでいる作業もコアの正式な作業ではありません。先の書き込みであたかも決定事項のように書いてしまいましたが、
自分も最初はリファクタリング派でした。その際、部分改編で論じていても始まらないと思って、それが累積してコア全体が改編された時の影響度と回避策をレポートできないかと作業している途中で、リファクタにせよどのみち丸ごと書き直すのだからＧＰＬから抜けるチャンスだと気づいて、フルスクラッチに切り替えたものです。
XoopsObject の後継コンテナが決まっていないことや、Cube に部分的に提唱されている DI 技術の実装面で Cube の計画と合致していない部分も多く、Cube へのフィードバック量はまだ決まってません。
でもこの作業とレポートが終われば具体的な実装に関わる議論に弾みがつくと勝手に思いこんでます。
ゲストの扱いの話でここまで話ができるのですから、それが全体量になれば具体的に 2.1 later 版への話が進んでいくと思います。