2009/01/01

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 件のコメント: