うそーんな仕様。というかバグ。

http://php.net/serialize
引用：

Marek Soldt
21-Nov-2007 09:50
serialize() and unserialize() behave a bit crazy if you try to work with bigger strings (100kb of size). It helps to divide the string parts to array:

とりあえず、手元のWindows用PHP4.3.11とFHEL4のPHP4では再現した。

つーか、100Kどころか60Kそこそこで発露。ありえねー。

でも単純に100Kほど文字列をシリアライズしてもならないんだよ。
CSVで60Kほどのをセッションに保とうとして失敗した。途中でブツっと切れるんです。あー

ちがった。

セッションに保存できないのは、DB使っててセッション用のField定義がtextだからだ。だから60K=textの65000文字付近で切れるんだ・・・。すんません＞PHP

最近、金融の本を読むようにしているんだけど、なんだか現状が「明らかに幻想の上に成り立っている」に過ぎない気がしてくる。


金融上の会計資産と、実体資産が3倍も違うなんて、おかしい。


誰かが「これ、そんなにお金回収できないんじゃない？」って思ったらつぶれるんじゃないだろうか？世界が。

本宮ひろしの「雲にのる」って神の世界を舞台にしたエロマンガを高校生くらいの時に読んだんだけど、そこに
引用：
という台詞があって全然理解できなくて（というか、このマンガ自体が全然理解できてなかった。また読もうかな）、この台詞をずっと忘れてないんですが、なんか金融界にも同じニオイを感じます。

金融界の評価が、実体にシュリンクされた時、世界の時価総額は三分の一になるんだけど、人口も3分の1になるんだろうか・・・・・

自動車マスメディアでいえば、クルマ＝新車なのはもうモータリゼーションが日本に来てからの話。まぁ、変といえば変なのだけど。


でも
http://wkwk.tv/chou/entries/2007/10/post_1097.html
のコメント数見てると、嫌いになったわけじゃないんだなーってのが分かる。様な気がする。


それはそれとして、私もクルマは好きなんだけど都内で1年使った結果「要らない」と分かったので実家に塩漬けにしてある。HondaのBEAT。また乗りたい。


敬愛する白洲次郎は、クルマ好きで有名なんだけどその中でも「これはカッコいい！」というエピソードは、晩年に、三菱ミラージュを運転手つきのクルマとして使っていたこと。「人が一人乗るんだから、この程度の大きさでいい」という考え。ものすごい合理的、かつ知的に感じる。これを20年前にやってたというところがすごすぎ。


また、白洲は2代目トヨタソアラの開発にアドバイスしてたのだけど、完成を見ずに逝ってしまった。そして、開発陣は、完成したソアラをもって岡山の墓の前に行って
引用：
と報告したという。しびれる話だ。

この開発には、開発者の元に白洲が自分の愛車のポルシェで乗り付けて「これ、開発に使ってくれ」と分解用に差し出したエピソードがあったりとか、おっさんかっこよすぎなんだよな。



死ぬ直前にも、ポルシェで銀座の「きよ田」にあらわれて、
引用：といって、ポルシェで飛び立っていった・・・。という。

私はホームページ製作業者ではあるけど、SEO業者ではない。しかし、「SEO業者」と「電解還元水の販売員」の共通点というエントリがあがっているので少々。


SEOの世間一般の認識というと、Aというサイトのページ順位をあげるために
引用：
などの行為を取ることだと思う。


私もそう思っていた。そしてSEO業者を忌み嫌っていた。


しかし、それは大いなる誤解である。SEOとはもともとそのような技術ではない。GoogleやYahoo!という検索エンジンにいかに適切にクローリングしてもらうかの技術である。技術というか、戦略に近い。

前のエントリで書いたように考えると、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のお仕着せ」になるのではないか。

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を考える第一歩。

正確には自分だけじゃないんですが、Ethna_Loggerを拡張してIPでログ出力先を限定してしまいます。

やり方は、自前のログクラスを作成します。

で、コントローラに追加

あとは、Configファイルに

と書く。


なんか、ダサ目の実装なんですが、とりあえずこんな感じ。
123.456.789.123のIPからアクセスしてる人だけにログが出力される。

# 本当ならもっとログConfigを丁寧に処理しないとね。

チェックボックスで、あると思います。
ユーザーに「これは必ずチェックしてるよー」って注意を促したいチェックボックス。

だけど、disabledを指定してしまうと、送信そのものがされません。


んー、それは困るっていうか意味がない。


で、すげー「なるほど」って思ったのは、
http://chaichan.web.infoseek.co.jp/qa5500/qa5629.htm
の回答。

引用：
いやー、その発想はなかった。Hiddenで併記は確かにカタいんだけどね。

メタ文字を正規表現として、エスケープするときにPHPの感覚で
引用：
とかやってたら、ぜんぜん[にヒットしなくて？？？？って感じだったのだけど、
http://m035.blog61.fc2.com/blog-entry-13.html

みたら、
引用：
ってやらないといけないのかもとか思い、成功。

http://d.hatena.ne.jp/riaf/20070914/1189747693
引用：

Ethna_AppManager::getObjectPropList/getObjectListにて、JOINするかどうかを判定しているコードはここです。Ethna_AppObject::_getSQL_SearchProp

この_isAdditionalFIeldメソッドに渡されているのが、$filter/$orderなので、Ethna_AppManager::getObjectPropListの第2引数の$fieldに_SQLPlugin_SearchPropDef()で定義したものを追加してもJOINしてくれません。私も昔ハマッタ。

Ethna_AppManager::getObjectListが$fieldをとらないので、当然といえば当然なのですが。


だから、JOINさせたいときは、$filterか$orderの配列のキーに_SQLPlugin_SearchPropDef()で定義した「JOINされる側のPropDefのキー」を持っていないとダメです。

バッドノウハウかもしれないですが、私の場合は検索に影響を与えないように

って追加してます。(この場合は、join_nameってのがJOINされるテーブルのフィールドにあるもので、
かつ、_SQLPlugin_SearchPropDefでも定義してるもの。かつ、絶対に空文字列がデータに入ってないもの。


あと、これはAppObjectのダサイところでJOINするときはテーブルに同じフィールド名があると
filter/orderに指定できません。なのでEthnaアプリを作る時は基本的にテーブルのフィールドがかぶらないようにフィールドプレフィクスを付けてます。


AppObejctというよりは、CriteriaであるEthna_AppSearchObjectも実は微妙な振る舞いがあって、それは、ひとつのフィールドに複数の条件をORでつけたい場合。また機会があれば書きますが。

でも、結構何とかなります。

あと、SQL関数を使った条件の場合は、AppSearchObjectは受け付けないのですが。



このブログってTB投げられるけど、受けられないんだよね。