XCat 共有カテゴリ管理モジュール
氷川 霧霞
2月ごろにここでご相談させていただいた共有カテゴリ管理モジュール XCat がようやく形になってきました。
http://xoops.trpg-labo.com/modules/wiki/?Menu%2FXCat
に、ダウンロードファイルと、概要を記した資料を掲載しています。
※以前の投稿はこちら。
http://groups.google.com/group/xcube-dev-ja/browse_thread/thread/d0a91e7f1e81e0ac
また、同サイトにデモ的にインストールしてあります。
が、使っているテーマと相性が良くないようで、正しく表示できていない部分があります。
今回は delegate を使っていまして、伊藤さんからリクエストのあった
$kili_cat[0]->checkAuth();
的な書き方ができます。 ↓
$kili_cat->checkGroupPermitByUid($uid, 'edit');
まだまだな部分が多いのですが、よろしくお願いします。
「こんな機能がカテゴリモジュールにあるといい」というのがありましたらご提案ください m(__)m。
ITOH Takashi
インストールしてみました。
カテゴリーとか、各モジュールごとにって割とうっとうしいのでいいですね。
http://xoops.trpg-labo.com/modules/wiki/?Menu%2FXCat
見てました。
下記、色々書いた後に過去ログ
[xcube-dev-ja:230] Re: 共通カテゴリモジュール
見たら私が
> で、これを
> XCube_DelegateUtils::call($kili_cat, 'as_array')
> とかで簡単に呼べるといいですねー。
とか書いてて大汗なんですが・・・・・書いたので投稿します。
//デリゲートで Xcat_Cat オブジェクトを取得
XCube_DelegateUtils::call('Module.xcat.Event.GetCatManager',
new XCube_Ref($cat),
$this->mObject->get('cat_id')
);
# 'Module.xcat.Event.GetCatManager'のxcatって dirname ですか？
# ってPreloadみたらそうでもないような。でもHandlerみると xcat 以外のdirnameを
# 意識してたり・・・。
#
# 管理系なので、Duplicateにはしないのかなー？と思ったり。
# でも、管理系なのにユーザー側にEditがあるのは何故？とか :-)
で、他モジュールから呼ばれる時、Delegateを使うことを想定されてますが、
Delegateって「デフォルトの動作が気に入らないから変更してやる！」っていう
感じがあって「この処理系をお願いね～」っていう依頼系の処理はServiceぽいなぁと。
なんとなくですが、権限チェックが
$xcat_dirname = 'xcat';
$xcat_id = intval($_GET['xcat_id']);
$uid = $GLOBALS['xoopsUser']->uid();
$privilege_type = 'VIEW';
$xcat_service =& XCat_Service::getSingleton($xcat_dirname);
if ($xcat_service->getCategory($xcat_id)->checkPermUser($privilege_type, $uid)){
// ここにO.Kの場合の処理
}
見たいな感じの方が「使わせてもらってる側プログラマ」としては分かりやすいかなぁと。
多分、'Module.xcat.Event.GetCatManager'の処理が気に入らないから変える！って人は
あまりいないような。もしいたとしても、checkPermUserメソッド内にDelegateを忍ばせておけば
やる人は勝手にやる・・・みたいな。
すんません、勝手言ってホンマすみません。
伊藤
氷川霧霞
■なぜ service ではなく delegate か？
これは簡単で、僕が service を分かっていないからです(^ ^;。
delegate はまだサンプルが user モジュールとかにあるので、
今回それらを見ながら作ったのですが、service はまるで
馴染みがないので（一つサンプルを知ってはいるけど）。
service のことが分かってきたら、service版もつくろうかな、
とは思っています。
今のところ、service は XoopsCubeの隠し機能(^ ^; だと
思っていたのですが、どっか良いサンプルがありましたら
教えていただけますでしょうか。
＃っていま検索してみたら Search と PM で使っている
#部分がありますね。見てみます。意外と簡単？
■>管理系なので、Duplicateにはしないのかなー？と思ったり。
はい、Duplicateは要らないかな～と思っています。もっともD3化の
手順をまだ知らないというのもあるのですが。
xcatが落ち着いたら別件でd3対応モジュールを作ろうかと思って
いますので、それでDuplicateについて学んだら、要望があれば
考えます。
■>でも、管理系なのにユーザー側にEditがあるのは何故？とか :-)
これは僕が管理画面あまり好きじゃないからです（使う側として）。
Preference 的なもの以外は、極力ユーザ側に作る傾向があります。
あとちょっと脱線しますが、将来的に（つまりまったく未定ですが）、
あちこちのモジュールから「カテゴリ」を軸にして情報を見せれるよう
にすると面白いかも、つまりあるカテゴリの「掲示板」「ブログ」「静的
コンテンツ」を集めて表示すると面白いかな、と思って、Edit含めて
ユーザ側に置いてあります。
のぶのぶ
「共有カテゴリ管理モジュール」 まだ、ページの説明を斜め読みした程度ですが・・・
Delegateを使用されているなど、XCubeならではのモジュール大歓迎です。
で、Delegateなんですが、「共有カテゴリー」って考えた場合に小生が思い浮かぶ
Delegateの使用シーンっていうのは、今回のようにXCatの機能がが呼ばれる形ではなく、
XCat側が呼ぶ形だと思うんですよね。
具体的には、XCatが管理しているカテゴリーを削除した場合に、XCatを使用している
モジュール側のコンテンツで、削除されたカテゴリーに属している場合、
たとえば、Module.xcat.Event.DeleteCategoryなんて名前の、
Delegateのインターフェースを公開しておいて、XCatでカテゴリー削除が
されたタイミングで、このDelegateで使用モジュールに対してマルチキャストして
やれば、各モジュールでは、カテゴリーに属するコンテンツを削除するなり、
カテゴリーに属さないコンテンツにするなりの個別のコンテンツレコードの
変更処理を実行できるなんて事が簡単に実現できると思います。
ご検討いただければ、幸いです。
ITOH Takashi
のぶのぶ さんは書きました:
> で、Delegateなんですが、「共有カテゴリー」って考えた場合に小生が思い浮かぶ
> Delegateの使用シーンっていうのは、今回のようにXCatの機能がが呼ばれる形ではなく、
> XCat側が呼ぶ形だと思うんですよね。
>
> 具体的には、XCatが管理しているカテゴリーを削除した場合に、XCatを使用している
> モジュール側のコンテンツで、削除されたカテゴリーに属している場合、
> たとえば、Module.xcat.Event.DeleteCategoryなんて名前の、
> Delegateのインターフェースを公開しておいて、XCatでカテゴリー削除が
> されたタイミングで、このDelegateで使用モジュールに対してマルチキャストして
> やれば、各モジュールでは、カテゴリーに属するコンテンツを削除するなり、
> カテゴリーに属さないコンテンツにするなりの個別のコンテンツレコードの
> 変更処理を実行できるなんて事が簡単に実現できると思います。
なるほど。他のモジュールからXCatのデータを利用したい時は、XCatのServiceを使う。
XCatがなんか処理する時に乗っかかりたい時は、XCatの方でDelegateを用意してあるのに
乗っかかるという感じですね。
[用意しておく側] [メインの処理側]
XCat(Service) ← 他のモジュール
他のモジュール → (Delegate)XCat
逆に言うと、わざわざDelegateでCallするという処理は、汎用的なモジュール
UserやLegacyなどのBASEじゃないと意味が無いという気がします。
本格的にDelegate/Serviceでモジュール間通信をしようとすると、
Preloadってこれらの登録だけを第3引数を使って行って、
実行コードは別ファイルにしておかないと実行時に使いもしないコードが読み込まれて
メモリ大量消費になっちゃいますね。今、結構Preload内にガッツリ処理を
書いちゃってます。
# 独り言になってしまった
伊藤
氷川 霧霞
のぶのぶさん、アドバイスありがとうございます。
やはり delegate だと本来の使い方とはちょっと違うわけですね。
service ベースで機能を提供できるよう、作ってみます。
というわけで、もうしばらくお待ちください＞利用をお考えの皆様
のぶのぶ
> やはり delegate だと本来の使い方とはちょっと違うわけですね。
> service ベースで機能を提供できるよう、作ってみます。
>
> というわけで、もうしばらくお待ちください＞利用をお考えの皆様
delegateにせよ、serviceにせよ、何らかの機能を提供する側から見た場合に、
XCatでいうと、「共有カテゴリーオブジェクトの提供」とか「共有カテゴリー一覧の提供」
といったの機能自体が、
「換装の可能性があるか？」
「拡張の可能性があるか？」（自分が機能を持っていない場合も含む）
という問いかけに対して、YESという答えが返ってくる場合にのみ実装すべきだと思うわけです。
No.であれば直接にHandler生成してObjectをgetするAPIの提供だけでも支障は無いと
考えるのですが・・・・・
ただし、Serviceについてはサイト間連携を考える前提で、サイト間共通のカテゴリー管理などの
可能性を考えるのであれば、Serviceとして実装するってことで可能になってきます。
（ただしこの場合には、サイト間で同一のカテゴリーを持つコンテンツを共有するために、
サイト間マルチキャストのような要請が別途出てくる可能性がありますね。）
zanjibar
サービス実装いいですね。
さらにデータ構造の課題があります。
On 5月31日, 午前11:33, "のぶのぶ" <nobun...@nobunobu.com> wrote:
> のぶのぶです
略
> （ただしこの場合には、サイト間で同一のカテゴリーを持つコンテンツを共有するために、
> サイト間マルチキャストのような要請が別途出てくる可能性がありますね。）
将来的にはコンテンツ共有にも発展します。
データポータビリティをあげておけば、CMS間のデータ移動も楽になります。
ここらへんは参考になるデータ構造の理論というのはあるんでしょうか？
zanjibar
ピンポイントですみません。
On 5月30日, 午後6:08, ITOH Takashi <tohokua...@gmail.com> wrote:
> 伊藤です。
略
> 本格的にDelegate/Serviceでモジュール間通信をしようとすると、
> Preloadってこれらの登録だけを第3引数を使って行って、
> 実行コードは別ファイルにしておかないと実行時に使いもしないコードが読み込まれて
> メモリ大量消費になっちゃいますね。今、結構Preload内にガッツリ処理を
> 書いちゃってます。
>
新ベースをつくるときには、どの実コードを実行したらいいのかの表だけが
メモリ食わない格好になるといいｋなあと思います。
私も独り言ですみません。
氷川霧霞
最初このモジュールを作ろうとしたときは、他のモジュールからは
xoops_getmodulehandler('cat', 'xcat') でハンドラ作って取って
もらえばいいかな、と手抜きなことを考えていたのですが、2月ごろ
ここで相談したところ、delegate や service での機能提供の話が出て、
やはりその辺を使うのが作法なのかなと思い直たところでした。
本当は、nobunobuさんが指摘されているようなことを作る前に考え
抜いてから実際に作り始められると格好いいのですが、delegate も
service も分かっていないので、作りながら「なるほど、こう動くのか」
と理解しているところだったりします(^ ^;。
（delegateで作っていて、他と使い方が反対だな、とは確かに思った）
で、まとまりがないのですが、もうしばらくあれこれやってみます。
＃異なるサイト間でカテゴリを共有したい、という要望は出るような
＃気がするので、Service での機能提供を考えます。
**
ところで、本件について、Service を推されている伊藤さん（や他の
皆さん）のご意見もよろしければお聞かせください m(__)m。
tohokuaiki
On 6月2日, 午後1:45, "氷川霧霞" <kilica.hik...@gmail.com> wrote:
> 本当は、nobunobuさんが指摘されているようなことを作る前に考え
> 抜いてから実際に作り始められると格好いいのですが、delegate も
> service も分かっていないので、作りながら「なるほど、こう動くのか」
> と理解しているところだったりします(^ ^;。
> （delegateで作っていて、他と使い方が反対だな、とは確かに思った）
でもこの辺は経験ある人とかならともかく、初心者は作りながら理解するって
感じでもいいのかなって思います。
> ところで、本件について、Service を推されている伊藤さん（や他の
> 皆さん）のご意見もよろしければお聞かせください m(__)m。
> ＃気がするので、Service での機能提供を考えます。
もちろん、リアルタイムな処理は無理でしょうけど、cronとかないしは
1時間に1回だけユーザーにババを引いてもらって通信とか。
一つ面白そうだなーって考えているのは、XOOPS Cubeで構築しているサイトなら
どこでも投票できるっていうServiceとか(もちろんモジュインスコは必要で)。
お題自体をServiceで通信して参加しているサイト自体もServiceで回してっていう。
もちろん２重投票とかできますが、そこはあまり厳しめに見ないっていう緩めポリシーで。とか。
伊藤
minahito
> 本当は、nobunobuさんが指摘されているようなことを作る前に考え
> 抜いてから実際に作り始められると格好いいのですが、delegate も
> service も分かっていないので、作りながら「なるほど、こう動くのか」
> と理解しているところだったりします(^ ^;。
> （delegateで作っていて、他と使い方が反対だな、とは確かに思った）
今件と直接絡んでという事でもないのですが、
まだ図など入れてないものの、デリゲートの技術的バックボーンなどまとめてみました。
サービスとデリゲートの違いというより、デリゲートとオーバーライドの本質的な類似性と
相違点を低レベルな視点でまとめたものです。
http://xoopscube.wiki.sourceforge.net/The_background_of_XCube_Delegate_mechanism%3Bja
現在これの DelegateManager 版も通勤時間を使ってしこしこと作成中です。;;
すみません、このMLの中には、
「ははあ、お前の取りたい説明アプローチは分かった。しかしこの書き方はどうよ」
という方もいらっしゃると思います。nobunobuさんとか (^▽^) ←名指し期待
適当に編集願います m(__)m
デリゲートに関するドキュメントは他にも未完のものがひとつありますが、
こちらはディープ版としてオモシロ読み物として置いておければと思ってます。
--
minahito (mina...@gmail.com)
HIKAWA Kilica
> 今件と直接絡んでという事でもないのですが、
> まだ図など入れてないものの、デリゲートの技術的バックボーンなどまとめ
てみました。
> サービスとデリゲートの違いというより、デリゲートとオーバーライドの本
質的な類似性と
> 相違点を低レベルな視点でまとめたものです。
>
> http://xoopscube.wiki.sourceforge.net/The_background_of_XCube_
> Delegate_mechanism%3Bja
わわ、またえらい分かりやすいドキュメントをありがとうございます（あ、名
古屋弁か）。
これはお金を払ってもいいくらいの分かりやすい説明ですね～。
代わりに今後モジュールを作ることでお返しとさせていただきます m(__)m。
XCat は nobunobuさんや伊藤さんのアドバイスをいただいていちおう順調に進
んで
おりまして、Service を使ったモジュール間連携の実装が完了し、テストモ
ジュール
を作って機能を確かめているところです。
ここで作ってるテストモジュールもちょっと変わっているのでついでにご紹介
します。
http://d.hatena.ne.jp/kilica/20080614
opCal （Open Calendar） という、Google Calendar と連携したイベントカレ
ンダ
モジュールで、ひとつのカレンダをあちこちのサイトで共有できるのが特長で
す。
このカレンダで使っている、都道府県、カテゴリ、施設の情報を、XCat から
取得して
います。
以上です。