WebとGUI
最近Google Calendar的なWebアプリケーションを書いているが、Ajaxというのは開発が面倒だ。
なぜ、こんなに面倒なのかを考えていたのだけど、GUIアプリケーションを書くパラダイムになっていないからだと思い至った。
GoogleCalendarのようなWebアプリケーションは、Webではなく、GUIアプリケーションなのだ。
設計はどちらも同じMVCを用いるのだが、Webアプリケーションの場合、難点が2つある。
- 1つはプレゼンテーション層が貧弱であること。
- 2つ目はController層がサーバサイドにあること。
まず1つ目の問題点はプレゼンテーション層の貧弱さである。
そもそもHTMLというのは文章を表現するためのものであって、アプリケーション向きではない。そこにJavaScriptという言語で動的にしたもののあくまで文書なのだ。
貧弱とはいえ、タブを作ったり、カレンダーを作ったり、CSSとJSでがりがり書くことはできる。これによってだいぶリッチなものになってきた。
しかし、Webを意識しすぎたつくりになってしまうことが多い。Webということを忘れて、GUIアプリケーションのコンポーネントを作るという感じで書くべきだと思う。
コンポーネントとして用意しプロパティやイベントをハンドルできるObserverを登録メソッドを提供する。GUIビルダが提供するようなイメージだ。
標準化されたコンポーネントの形がないのが問題だと思う。
2つ目の問題はコントローラ層がサーバサイドにあることだ。
GUIプログラミングの場合、一般的にはイベントドリブンを用いる。 例えば、ボタンが押されたというイベントに応じてデータ処理など何らかの動作を行う。
イベントハンドリングは本来Controllerで行うが、Controller層がサーバサイドにあることにより、非常に扱いにくいものになっている。
JSFやASP等イベントドリブンを提供するWebフレームワークもあるが、あくまでControllerはサーバ側にある。
サーバ側にあることで、次のような問題点がある。
- いちいちサーバへイベントを送らなければならないため、レスポンスが遅い。
→AJAXで一部解消 - クライアントだけで処理する変更をハンドリングできないため、処理が分散する。
AJAXでサーバへのイベント送信を非同期にできるようになったが、Viewの更新が面倒すぎる。
ページ上の複数コンポーネントを処理するのが煩雑である。
プレゼンテーションの貧弱さの原因の一つが、このクライアント側コントローラがないこと、そしてコントローラを作りにくいことにあると考えられる。
Railsやその他のフレームワークで大分Webアプリケーションが作りやすくなったとはいえ、プレゼンテーションがいまだにJSPライクなHTML埋め込みスクリプトなので、いまだに古典Webを抜けられていない。
我々が書いているのはもはや単なるHTMLベースのWebではない。我々が書いているのはGUIアプリケーションなんだ、という意識で書いてみたらどうだろう。
ということで、HTML版AIR見たいな形で統合されたプレゼンテーションとコントローラを提供してくれるWebのフレームワークが欲しいなと思いました。
もうコントローラはクライアント側でよくね?Webの先はストレージだけでよくね?と思うんだけど。
どうも古きよきWebをいじるためのフレームワークはあるけど、GUIのためのフレームワークってないんだよね。(いいのがあったら教えてください。)
いや、みんな気付いててRIAなんだろうけど。 何でHTML大好きなんだろう。
GWTとかEclipseとか、使ってみようかなぁ。
0 件のコメント:
コメントを投稿