.




うぇブログ2
最新エントリ

(1) 2 3 4 »

2007/10/31
カテゴリ : XOOPSメモ

執筆者: itoh (5:30 am)
前のエントリで書いたように考えると、Delegateはイベント(何かの処理が行われた)が起源となるはずだ。


ただし、私はまだDelegateの処理を一度も書いたことは無いし、コード上の理解もしてないので全くの間違いかもしれない。


それでも、
・ユーザーがログインした
・ユーザーの投稿数が1上がった
・ユーザーがログアウトした
・管理者が私の投稿を承認した
・管理者がサイトをクローズした
・誰かが、私のuserinfo.phpのページを閲覧した
などなどをひっかけて、自分の好きな処理をこれに絡ませられたら楽しそうだ。


実際はもっと細かくあっても良い。
コアに近い機能ほど、フックさせるためにイベントを細かく分けて「どんな変則的な考え方をされてもフックをさせてあげるべきだ」と考えるだろう。となると、LegacyはほとんどDelegateで書かれてることになりそうだ。




で。Delegateとは何をするためのものかを考えたところで、

「じゃあ、Delegate自身は何?」

ってことになるが、おそらくこれは処理そのものだろう。1つのデリゲートが1つのメソッドに直結している。

じゃあ、処理を行う際に(=Delegateを発動させる際に)必要なものを考えてみる。

1. 何のイベントに結びつけるか
2. そのイベントが起こった際に、このDelegateはそのイベントの前で行われるべきか、後で行われるべきか。
3. このDelegateは処理(=メソッド/関数)とすると、その関数名(クラス名/インスタンス)
4. 3.に加えて、引数


これらを考えると、Delegate群をマネージするモノが必要になりそうだ。おそらくそれが、DeleagateManagerクラスなのではないだろうか?ただ、このクラスが何をDeleagateに施してくれるかはまだ私は知らない。



逆にDelegateに関して、普通の処理とは違って不要なもの(別の言葉で言うと、「Delegateに期待してはいけないもの」)
A. 返り値・・・そもそも「いつ」「何が」行われるか分からないのに返り値を期待するのは間違っている
B. 環境変数・・・$_SERVERとかの意味ではなく、グローバル変数。Delegateがどのような状況で発動させられるか分からないのに、Delegate内部ではもっとわからない

このA.をフォローするために、引数を参照で渡して引数がその処理を受けた結果となるべきである。
このB.をフォローするために、Delegate内部では極力信頼できるものからの派生変数を使うべきだ。

PHP4における前者の要望を満たすために、XcubeではXCube_Refというクラスを用意している。
Xcubeにおいては、どこでも使えるシングルトンをXCube_Root::getInstance();で取得し使うことにしている。

前者は、PHP5移行では不要となるだろう。しかし、後者はXCubeでは数少ない「XCubeのお仕着せ」になるのではないか。



itohさんのブログを読む | コメント (0) | トラックバック数 (0) | 閲覧数 (8386)
2007/10/30
カテゴリ : XOOPSメモ

執筆者: itoh (5:04 am)
Delegateという機能がXOOPSCubeにはある。かなり中心にある。これが全てなんじゃないかと思えるほどだ。



しかし、これが全く理解できないのだ。

何のためにあるのか分からない。


一昨日、minahitoさんと話したところ

・普通にWebアプリ造ってれば、Delegateなんて要らない
・それは、自分の手の中に収まるものしか考えないから。→そりゃ当然


で、その後も色々聞いたのだけど細かいことは忘れた。


そして、さっきXCube Legacyのソースコードを見て、MarijuanaさんのXCube Legacy用のモジュールをみて、それでもさっぱり分からんわけです。



まず、どうやってコードを書いていいか分からないんだけど、それより問題なのが





「なにを実現させるために使うのかがわからない」





それはまさしく、さっき書いた通りで[普通にWebアプリ造ってるなら要らない]機能だから。

目的が無いのに、手段があるわけが無い。




ということで、まず考えたのが「何のためにDelegateが必要なのか?」ということ。しかしこれはあまりに漠然としていてわからない。


そこで、切り口を変える。
「なぜ、XCubeはDelegateを用意したのか?」
を考える。


・Delegateとは、XOOPS2の開発やハックで辛酸を嘗めた人が造った
 ↓
・なぜ辛酸を嘗めたのか?
 ↓
・それは、ono..じゃなくてHer...でもなく、X2にフックポイントが無かったから
 ↓
・だから、コアに対しては、「思い切ってハック」か「まるごと代替を造る」
 ↓
・いずれにせよ、コアのアップデートに対して極めて脆弱な立場
 ↓
・コアに対して、モジュールが気軽にフックさせたい
 ↓
・いっそ、コア自体も代替させたい


最後から二つ目の「気軽にフック」こそがDelegateの使命なんじゃないかと考えた。

ちなみに、最後の「コアも代替」は、現在の唯一の公開BaseであるLegacyは、代替がきくということにつながる。これはこれで壮大なテーマだけどひとまず脇に置く。



では、「気軽にフック」させるためには何が必要か?

それはコアが何かの処理CoreFoobarをする時に、その処理に関連づけられた処理が無いかをチェックしてくれる機構ではないか。その処理の前には、HogeというモジュールがHogeFooという処理をして欲しい・・・または、その処理の後には、UkiというモジュールがUkibarという処理をして欲しいととスタックされている必要がある。

ただし、コアの処理CoreFoobarは自分の後と前に何の処理が来るかはわかっていない。これがポイント。


繰り返すが、これは、通常のWebアプリではありえない。なぜなら、
CoreFoobarの処理を書く人 = HogeFooの処理を書く人 = Ukibarの処理を書く人
であるからだ。もしくは=は≒であるが、いずれにせよ「全く知らない」ということは通常あり得ない。仕事ができない。

しかし、XOOPSではそれが頻繁にあり、X2の時代は「モジュールの相性」という言葉で片付けられてきた。



これをスマートに片付けるのがDelegateというのではないかというのが私のDelegateを考える第一歩。
itohさんのブログを読む | コメント (0) | トラックバック数 (0) | 閲覧数 (6574)
2006/12/10
カテゴリ : XOOPSメモ

執筆者: itoh (6:48 pm)
リリース間近と言われるXOOPSCubeをちょっと見てみる。

XCubeのコーダーのminahitoさんは「お遊び」レベルのXOOPSということに拘っているようだけど、あえて商用にも使える。・・・・使い方ができる。


XOOPS2の段階では、「あ、使えるかも」という期待を抱いたマーケッター達があれこれと考えてみるも、実際にデザイナーやプログラマーのところに持ってくると
「こんなの分からない」
「(コードが汚すぎて)触る気がしない」
という感じ。

実際、私もnewbbの改造案件を受けているが、newbbをゼロから作りなおしたものを改造して納品した。結果、それに更に改造を加えて欲しいということで、「もし、最初に素のnewbbを使ってたら」と考えると恐ろしくてしょうがない・・・・。


で、XOOPSCube。

これは、いたるところにフックポイントが仕掛けられていて、XOOPS2とはまったく違うコーディングスタイルになっている。

私もどこまで理解してるかといわれると、全くなのだけど、これは使える。何が使えるというかというと、マーケティング的に
「XOOPSの一番新しいのはCubeです」
「Cube使いましょう」
となると、受けがいい。なにより、XOOPSの仕事があってもXOOPS2の汚いコードを見る必要が無い。ここ最高。


・・・・と言えるようになるのはいつの日か・・。とりあえず半年を目処に。
itohさんのブログを読む | コメント (0) | トラックバック数 (0) | 閲覧数 (5422)
2006/10/22
カテゴリ : XOOPSメモ

執筆者: itoh (2:34 am)
さて、試してみた。

私のモジュール、全然動かない・・・・というほどでもないけど、ブロックがダメ。サーチとか。

なんというか、$GLOBALS['xoops_modulehandler']とかに依存してたコード書いてたからな。書き直さないと。

というか、全体的にへっぽこなコードなのでみっともないから書き直さないトナーというところだったので、ちょうどいいや。


しかし。XOOPS_TRUST_PATHは便利この上ない。割り切りの便利さというか、配布用パッケージを自分で作ってしまえることの気楽さというか。(気楽でもないんだけど
itohさんのブログを読む | コメント (0) | トラックバック数 (0) | 閲覧数 (5421)
2006/10/13
カテゴリ : XOOPSメモ

執筆者: itoh (1:20 pm)
xoops_version.phpを読み込みたいときって、ままあるわけですが既にLoadされていることがほとんどで、簡単に

<?php
require_once XOOPS_ROOT_PATH."/modules/".$dirname.'/xoops_version.php';

とかではダメ。

んー。とか思ったけど、xoops_gethandler使って
<?php
$mod_h =& xoops_gethandler('module');
$mod = $mod_h->get($modid);
?>

ってやると、modidのモジュールオブジェクトが取れるんですよね。

なんか、「xoops_gethandler使いたくない!」っていうのが頭にあって、どーも拒否感を感じるんだけど。

でも、これはこれでちゃんとOOPしてる。
実装が中途半端だけどね。
itohさんのブログを読む | コメント (3) | トラックバック数 (0) | 閲覧数 (5070)
2006/07/21
カテゴリ : XOOPSメモ

執筆者: itoh (3:00 pm)
XOOPS検索以外に、こんなのあったの知らなかった・・・・。

http://xoopscube.jp/modules/newbb/search.php


っていうか、使いにくいし、何の意味があるんだこれ?
itohさんのブログを読む | コメント (2) | トラックバック数 (0) | 閲覧数 (5602)
2006/07/19
カテゴリ : XOOPSメモ

執筆者: itoh (9:19 pm)
XOOPSのコードは既に耐用年数を過ぎたものばかりなんだけど、Notificationのコードだけは未だにイケテルと思ってる。

モジュールのコードの中に、なんかのクリティカルイベントが起こった際に
<?
$notification_handler =& xoops_gethandler('notification');
$notification_handler->triggerEvent('forum', $forum, 'new_thread', $tags);
?>

と書くだけで所定のメールが飛ぶ。何がすごいかって、これ、どんなモジュールのコードの書き方をしても、それに依存せず、この2行だけで完結してるところ。いや、普通にObjectiveなコードの書き方をしていれば、普通なことなんだけど。


そして、このNotificationのボックスが、テンプレートに
  <{include file='db:system_notification_select.html'}>

と書くだけで現れる。設定は、xoops_version.phpだけだ。すばらしい。


ところが、この機能を積極的に使わないモジュール作者は結構いる。移植系ものほどそんな感じがする。

Xanhteで書き直してるNewbbだけど、この部分だけはそのまま使ってる。
itohさんのブログを読む | コメント (1) | トラックバック数 (0) | 閲覧数 (6484)
2006/07/13
カテゴリ : XOOPSメモ

執筆者: itoh (11:47 pm)
Newbbモジュールの手直しの仕事が入った。

あのコードを元にして手直しをする気が全くしなかったので、Xanhteを使って換装中。

ただし、今回はやや互換性を考えてviewtopics.phpとかviewforum.phpとかは残すことにした。GET変数もなるべく一緒に。


ということで、なんだかやってることはXOOPS2をXOOPSCubeに書き換えているminahitoさんと同じっぽい。イケテないコードのりファクタリングという意味でも。

でも、まぁまぁ楽しいですよ。機能的にはなんら変わってないんで、完全に自己満足の世界だけど。(その後の仕事のことは置いておくとして)
この部分までは、今回の仕事の見積もりに入れて無いんで、できれば公開したいんだけどさてさて。


とりあえず、1週間で管理側と表示させる側は7割できたんで、あとは書き込み側とブロックと検索とかのXOOPSのAPIだなぁ。書き込みは楽なんだけど、ブロックがメンドイ。。。異様に面倒・・。
itohさんのブログを読む | コメント (2) | トラックバック数 (0) | 閲覧数 (7630)
2006/05/31
カテゴリ : XOOPSメモ

執筆者: itoh (6:03 pm)
Ethna使って、CMSがなんとか形になるかも。

と言っても、ブロック表示の実装がちょぉっと目処がついただけだけど。

XOOPSみたいに、外枠のテーマHTMLとCSSを指定して、そこに各ActionをBlock的に配置していく。XOOPSって実装はアレだけど、全体の体系としては良く考えられている。

モジュールがDuplicateできるというのだって、良く良く考えてみればよくできたものだ。正直偶然の産物と、GIJOEさんの努力の賜物としか思えないが、ああいう「ディレクトリ名変えました、はい機能が増えました」なんてのはタコでもできるわかりやすさの極限だなぁ。ページコントローラの利点でもある。いわゆるPHPらしいPHPの特徴を活かしたアプリケーションのように感じられる。


でも、プログラムを書いててつまらんのだよな。これが。ページコントロールのプログラムはキツイ。
itohさんのブログを読む | コメント (6) | トラックバック数 (0) | 閲覧数 (6386)
2006/05/22
カテゴリ : XOOPSメモ

執筆者: itoh (2:15 pm)
XOOPSでいくつかのテーブルから共通のデータみたいに抜き出したい場合。

たとえば、ニュースモジュールとうぇブログモジュールとワードプレスモジュールから「最近の記事一覧を抜きたい!」という場合。

こんなSQLを考えました。
SELECT "weblog" AS dirname, blog_id AS id, "blog_id" AS id_str, title AS title, contents AS content, created AS created, "details.php" AS link
FROM xoops_weblog
uni-on SELECT "wordpress" AS dirname, ID AS id, "id" AS id_str, post_title AS title, post_content AS content, unix_timestamp( post_date ) AS created, "index.php" AS link
FROM xoops_wp_posts
uni-on SELECT "article" AS dirname, storyid AS id, "storyid" AS id_str, title AS title, home_text AS content, created AS created, "article.php" AS link
FROM xoops_story
ORDER BY created DESC
LIMIT 10
OFFSET 0 

しかし、これをやると、uni-onで定数とした部分。は、"weblog"の6文字で切り落とされてしまいます。

つまり、wordpressと出て欲しいディレクトリ名がwordprまでしか出てきません。これは困ります。


ということで、その場しのぎ的に、定数の部分は
<?php
'dirname' => sprintf('"%20s"', "wordpress"),
?>

とかしてみました。ただし、データをFetchした後に、空白は取り除く必要があります。SQL側で良い対応方法がありそうですが。
itohさんのブログを読む | コメント (0) | トラックバック数 (0) | 閲覧数 (4537)

(1) 2 3 4 »



 





メインメニュー

カテゴリ一覧

Google Adsense

うぇブログ カレンダー


XoopsCube Ring
Amethyst Blue - BULLETIN


.