ICallbackEventHandler

さて、この流れを受けてhttpsysやAtlasの話をここで始めるのは、地上に生きる人っぽく無い。

だからといってこの話を受けてasmxの話をするのもつまらない。

DataSourceControlに行くのが筋なのでしょうけれど、私はあれ、嫌いなのでパス（ぉぃ）

 

偏屈な地上のプラグマティックプログラマとしては、何故かここからICallbackEventHandlerに話をつなげるのだ。

 

クライアントサイドでどう表現されているかはITemplateのみが知るのだけれど、そこで何かが起こればサーバーサイドと通信する。

この捉え方はかなり本質に近い（と私は勝手に思う）。

その例としてICallbackEventHandlerは手ごろだと思うのだ。

 

ITemplateはこのコンテキストではhtmlだ。

もちろんITemplateもそのContainerもControlなのだけれど、分かりやすさを優先する。

 

htmlであるITemplateがControlと通信をするには二種類の道がある。

一つがDataBinder.Eval。これはコントロールの「インスタンス」がhtmlを触る所。

インスタンスが触るってのは他になかなか無くて、エキサイティングで面白いのだけれど、この話をするにはリンク相手は本質を知りすぎている（少なくとも私よりも）。

 

なので本質からは少し外れてもう一つの道、html「が」コントロール「を」触る向きの話をする。

これがICallbackEventHandler。

 

ICallbackEventHandlerは口が二つ、JS側で呼ぶ関数名と、それが呼ばれた時に呼ばれるコントロールのコールバック。

本当はもうちょっと細かいけれど気にしない。

jsで関数を呼ぶとXML Http Requestが飛ぶ。でもそれは関数を呼んだら飛ぶのがUDPかってくらいにはどうでもいい（嘘。本当はもうちょっと重いので新しく考えなきゃいけない事も本当はある。でもここでは見ない）

 

コントロールがEvalを通じてhtmlをさわり、htmlがICallbackEventHandlerを通じてコントロールと通信をする。

コントロールはまさにコントロール単位でどうサーバーとクライアントが通信するかを決める事が出来る。

コントロールを置くとコントロールがユーザーと相互作用をする。

htmlをどう使うか、サーバーサイドをどう使うか、置く側はどうでもいい。

だから置く側はどんなhtmlが生成されてるのかもしらないし、何を使って何と通信するかもしらない。

 

少なくともそのWebControlを使う側からすれば、知っている事はelementのattribute（C#のではなくxmlの方の）を通して伝えるプロパティであり、イベントとしてくる通知である。

これはhtcの時代から何も変わっていない。

 

ICallbackEventHandlerを実装していればXML Http Requestになる。なければpost backになるかもしれない。

それはそのコントロールだけの事情であり、その実装の話だ。auto post backがonかもしれないし自分でraiseするかもしれない。

もっと違う仕組みでは、例えば非同期にnotifyを送るだけかもしれない。Callbackも非同期に来て、それらの間には対応なんて無くてもっと違う形かもしれない。

現時点で二つ、PostBackとICallbackEventHandlerあるんだ。今後は違う方向もあるだろう。

 

でもそんな事は本当は重要じゃない。

 

コントロールがあり、その宣言時のattributeとeventというインターフェースがある。

作る側はコントロールとして物を作る。どんなインターフェースを作るか？という考えと、どう作るか？という考えは大きく異なる。

向こう側とこちら側だ。なんの？IUnkwon？違う。でも違わない。

誰が、どうホストするか？そんな事は知らない。

 

さて、使う側から考えて見よう。

WebControlを置こう、と思った。

その中がMVCで作られているか？そんな事はどうでもいい。

置く側はそんな事は気にしない。ITempalte化されていればちょっと話は違うが、でも根元の根元はやっぱり違くない。

 

大切なのはそのWebControlが何をしてくれて、自分はそれを使って何をするかだ。

して欲しいように振舞う為にattributeを指定する。Eventをくっつける。

中のことなんて知らない。外の事も知らない。

でも自分がやる事をやって、また自分はEventを公開する。

 

使う側はページだろうか？

そうとも限らないコントロールだったりする。コントロールはどちらにもなる。

使う時の視点と使われる時の視点で同じ人がどちらになるかが変わるのでテキストで書くとややこしい。

でもそれって新しい事じゃない。本当に知ってる人なら良く分かるはずだ。

表面は変わったけど、あれは変わってない。あれが何なのかはうまくいえないけれど、たぶんあちらでは感覚といっている物だ（たぶん）

 

もちろんWebControlをどう作るかも大切だ。

これはまさに、IUnknownの向こう側とこちら側と同じ話だ。

だからどうでもいいと言ったけれど、ICallbackEventReferenceを実装しているかどうかが重要だったりもする。

 

もう既にICallbackEventReferenceやDataBinder.Evalはあるのだ。

たまにどういうJSが呼ばれるか、とか気にしなくちゃいけない点で不完全ではあるけれど、コントロールを使う側は既に完成されている。

中は変わるかもしれない、でもそれは分からない。

 

コントロールをホストする側も変わるかもしれない。

変なタグで囲まれていればpost backじゃなくなるかもしれない。

だからコンテナはどうでもいいっていったけれどどうでも良く無いかもしれない。

ICallbackEventReferenceがどうでも良く無いのと同じように良く無い。

 

でも本当の所はそこらへんは小さな事だ。

コントロールがあってインターフェースがある。

コントロールを作っていくのが大切な事で、使っていくのが大切な事だ。

 

本当は今回の本題はICallbackEventHandlerでもうちょっと先に今回書いたような事を結論としてもってこようとしていたのだけれど、向こうの反応を見るとちょっと遠回り過ぎたよう。

 

内容的に向こうに書いてある事をくどく書いただけになってしまったけれど、ローカルで書いていたのは向こうup前なんだ、とか言い訳をしてますますかっこ悪くなる。

upせずに消そうとも思ったけれどまあいい。

ここらへんのやりとりは、楽しめる人もいると思うので消さずにupしておく。