にっき

** まえおき
てきとうに思いついたことなどを文章にして垂れ流して見よう。
あまり自分が考えていることを表現することが得意ではないので、ちょっとした練習も兼ねて。

** background
(今まで、これまでのjsの経験はというと以下のような感じ。
jsをあまり突っ込んだ使い方をしたことがない。jqueryを使ってちょっと仕掛けを作ったことがある程度)

** ここ何日かはjsのmockupをscrap&build

最近はずっとjsを書いていた。
すぐにコードが思い浮かばなかったので、とりあえず、mockupのアプリを作っては壊しを繰り返すなどしていた。
そんなわけで、ここ最近、色々な試行錯誤が続いた日々だった。
おかげである程度js関連のライブラリの知識が付いてきたように思う。

*** ここ何日かで気づいたこと

underscore.jsはとても楽で便利。だいたいrubyでコードを書く時のイメージで必要だと感じるような操作はほとんど行うことができる。
jqueryのDeferredのbind,live,delegateの違いがだいたい分かった。*1
また、jquery.toolsのコードを少しだけ読んだ。
(やっぱり、個人的にはドキュメントとデモだけでは、提供されている機能を思い通りに使うことができないなーと思った。
overlayのイベントがトリガーをくっつける要素のdata($(foo).data("overlay"))に入っているなんて気づかない。)

*** クライアントサイドのMVCが欲しくなってきた。

そして、この何日かでひとつだけ面白いことがあった。それはjsでのMVC*2ライブラリの必要性についての話。
正直なところ、今までjsでMVCのライブラリが必要だと思ったことが無くて、Backborn.jsが話題に上がった場合も、
とりあえず調べるキューには入れるもののペンディング状態であまり食指が動くというようなことは無かった。

ところが、ここ何日かの試行錯誤の過程で、今書いているコードがごくごく自然にMVCへの道を歩んでいるように感じた。
最初は処理を直接記述するようなコードを書いていた。しかし、途中で、モデルに対応する概念が無しにコードを書くのが辛くなってきた。
まだ、ただしく理解できてはいないけれど、少し面白いと思ったので文章にしてみることにする。

** MVCが欲しくなってくる状況(特にM)
MVCという言葉は良くないのかもしれないけれど。

*** 1機能1ページ
1つの機能を持ったサービス。これにはMVCは必要ない。
(具体的には、○×診断のような。1ページ1機能のサービス)
それは、「誰が何をするかという意図を考える必要がないから」だと思う。全ての処理について、それを行うのは単一の「それ」と考えれば支障がない。
ということで、機能がひとつだけのサービスではMVCは不要。

*** 1機能Nページ
1ページ1機能の画面遷移を持つwebサービスの場合にも、おそらくMVCは必要ない。
(具体的には、登録フォーム -> 確認画面 と進んでいくようなページの遷移をするwebサービス)

*** N機能Nページ(各機能が独立)
また、この種のサービスが複数の機能を持った場合もある。
しかし、機能の分岐が読み込むページのレベルで行われている場合には、サーバサイドでは必要になってもクライアントサイドでは必要にならない。

それは提供されている機能を利用するフローが一通りしかないから。
どのような機能を利用するかという点においては、実行する「誰が」が変わることがあるかもしれないけれど、それはサーバ側で吸収される。
1ページ上の処理については、やっぱり、自動的に決まる単一の「それ」で十分。
機能の利用に何ステップかの段階が必要になったとしてもそれは、時間(stage)ごとに区切ってしまえば同じ話。
「誰」が何をするかということをかんがえる必要はやっぱりない。

とここまで書いてきたけれど、実際のところMが必要になるのはこれに当てはまらない処理が必要になった場合。
必要になるのは

- 1ページ中で提供される機能(動作)が複数存在する
- そしてあるひとつの機能が他の複数の機能に影響を及ぼす

(というような状況。言葉で表すとよく見聞きしたありふれた内容になってしまうなー。)
これに実感が伴ったというのが大きいのかもしれない。

*** ここから口調変えよう

書きにくかったので、ここから口調を変える。

1ページ上での操作を以下のようなことがで表現することにする。
|page|webページのこと|
|gadget|page上のある程度視覚的にまとまった部分のこと。特にフォームやボタン/スイッチを持つ操作可能な部分を持つもの*3|
|function|機能/処理のこと。サービスが提供する機能は、page上の複数の機能で構成され、その機能もまたいくつかの機能で構成されているかもしれない|
|stage|page中でgadgetの操作により、変化した状態を表すもの|
|object|複数の状態/機能を持った主体。入力としてガジェット上の操作をとる。|
|anaphoric|文脈上自然に決まる何か。指示語で「それ」と言って上手く内容が汲み取れる状態(e.g. anaphoric macroのaifのit)|

上に書いた内容を別の言い方で表現すると、

1. 1page 1functionのアプリケーションにMは必要ない。それは、anaphoricにfunctionを提供するobuject(it)が決まるため。
2. Npage 1functionのアプリケーションにMは必要ない。それは、以下略
3. Npage Nfunctionのアプリケーションでも、各functionがページレベルで独立*4なら、functionの分岐はページを選定する段階(あるいはURL)で行われているはずであり、クライアント側では、anaphoricにfunctionを提供するobject(it)が決まる。
4. Npage Nfunctionのアプリケーションでも、各functionを時間的/段階的に区切ることができるの*5なら、(ある段階(stage)上のitと言うことによって)、anaphoricにfunctionを提供するobject(it)が決まる。

以上のように、objectという言葉を使わず、あるfunctionを実行する主体(object)を表現することができるのであればMVCのMは必要ない。
逆に、MVCのうちのMが必要な状況を言い換えると、以下のようになる。

5. あるひとつのpage上であるひとつの機能を利用したいと言った時に、その機能を提供するobjectがanaphoricに決まることがない状況。具体的には、1つのpage中に、複数のgadgetが存在し、ひとつのgadget上での操作が操作を行ったgadgetとは別のgadgetに影響を及ぼす状況。また、ひとつのgadgetを操作することによる影響の範囲は段階的/時間的にひとつに定まることが無い。(gadgetに対応したobjectがあるかもしれないし。gadgetの数より多いobjectがあるかもしれない)

というような感じになる。このように、functionを提供するobjectがanphoricに決まらない場合に、「誰が」を明示したい。このような時にMが必要になる。

(ここから下はまだ考慮不足)
** MVCのCが必要になる時。
** MVCのVが必要になるとき。

Cというか関係性のdispatch。Mによって「誰が」ということは分かった。
ただ、gadget上での操作は他のgadgetに影響を及ぼす。その関連性をどこかで表したい。
どのような段階でのどのgadgetでの操作かなどで表したい。

どんな操作すんの?
などなど。