前のエントリからの続きなんですが・・・、

HTMLと動的コードの連携ですが、データソースの文字列なりオブジェクトだけサーバサイド生成のJavaScript経由で渡して、すべての動的レンダリング制御をJavaScript + DOMでやるようなフレームワークの方法論って取れないんでしょうか？

って書いてみて、そういえば自分も昔からそういうアプローチで作っているものがありました。UIが高機能で独立性の高いプレーヤー,Viewerのようなものです。

少なくとも今、現在のMVCの理想系は、このアプローチなんじゃないかなと。View = HTMLがスタンドアローンで動くのが一番わかりやすいなら、HTMLはHTMLのままであるべきだとは思うので、bodyのonLoadでせっせと書き換える。そのかわりエンジニアにJavaScript、DOMの知識は必須ね・・・と。

でもベタに作るなら、　prototype.js使えば「$('id名').プロパティ名= なんとか」で書き換えられますから、そんなに大変じゃないですよ。フォーム要素も一貫したapiでアクセスできるようになっているし。DreamWeaverでデザイン見えるし、良いことづくめ。とにかくフレームワークがHTML壊すのは嫌ですね。

Flashみたいなバイナリだと必然的にこの方法しか取れないんですが、ただFlashも、Flexというエンタープライズ向けのプロダクトで、MXMLというXML言語をJSPみたいに生成して、それが動的にswfにコンパイルされるアプローチがあって、それだとColdFusionやJSPからHTMLを作るみたいなもんですから、現実的には、なんとも言えないのかなぁ。何せ時間、設計、スキル的な面がありますからね。だからこそ僕はWebエンジニアにJavaScript , CSSのスキルは必須だと思ってるんですけど。

FlexのMXMLという言語は、パーツの組み合わせ言語という側面があります。つまりベースはUI Componentsという組み込みパーツをどう表示するか？という言語で、VBとActiveXコンポーネントの関係に近いんですが、ActiveXコンポーネントは、割とVC++で作りますし、凄いFlash MovieをMXMLで書く奴いないでしょってのと同じく、Ajaxに伴う複雑なUIをJSPなどの動的コードとDBのデータを組み合わせないとデバッグ一つできませんってのもどうかと思うので、JavaScript + HTMLはサーバサイドからの独立性は高くあるべきだと思うんですよね。

まぁどっちにしろ今まではHTMLを直で変更しても問題ないレベルの「表示だけで機能がないHTML」しか書いてなかったから不要だったとも言え、よりコンポーネント指向が高まってくれば、HTMLを書き換えて制御するのは不可能になってくるので、必然的にこういう流れは進んでいくのかなと。

例えば、テーブルの幅をドラッグで変更できて、クリックしたら編集するテキストフィールドが表示されるようなExcelライクなセルコンポーネントを使えば、自然とデータソースを配列or オブジェクト渡しになるのは免れないでしょう。先のプレーヤーもHTMLそのものをコンポーネントとしてあつかっていたからこそ、中のコードはできるだけ壊したくなかったわけで。

要するにASP.NETのサーバサイドコントロールみたいな奴のJavaScript版を普通に使うようになれば自然とJavaScriptのオブジェクト渡しになっていく。
ただ、デザインサイドでFlashのUI Componentsでスキンなど戸惑っている人って沢山いると思うんですけど、それと似たようは問題は出てくるのかなぁ。MTやXOOPSのテンプレを作る経験があって「決められたHTML設計にデザインをあわせこむ」ことに慣れている人なら大丈夫かな？

とにかく、それにコミットして時間コストをかけることが明日の幸せに繋がるという普及こそが鍵ですね。これ、もうRuby on railsあたりで普通にメジャーになりそうな実装があったら無知でごめんなさい。もしあったら教えてください(w