GUIへの回帰

Seasar S2JFace

ここ最近強く思っていること。Webアプリケーションの表現力って、そろそろ限界なんじゃないか、GUIに回帰する時代が来るんじゃないか、ということ。

Flexとかでそれを突破することはできるけど、価格的に敷居が高い。Ajaxの登場で、だいぶできることは増えたけど、ふと我に返って考えると「それって、GUIなら普通にできることなんだよな・・・」と思うのです。

そもそも、なんでWebアプリケーションになったのかというと、クライアントアプリケーションの管理をしたくなかったから。つまり・・・

「クライアント管理から解放されるメリット」＞＞「Webで表現力が減るデメリット」

という式が成り立っていたわけだ。

でも、最近はお客さんの要望もどんどんリッチ化しているので、いくらAjaxで小細工しようと、いずれ限界はくるんじゃないかと思うのです。

クライアント配布技術は結構一般化してきているので、いまさらWebにこだわる必要もない。Javaだって、Java Web Start があるんだし。

特に、リッチなUIが求められる企業内システムでは、ほとんどの場合インターネットに公開するわけではないので、GUIに戻った方が良いんじゃないだろうか。で、インターネットで一般に公開するようなものは、今まで通りWebアプリ、という棲み分けになるでしょう。きっと。

じゃぁ、なぜGUIに戻らないかというと、少なくともGUIのキラーフレームワークがないからでしょう。StrutsやJSFに慣れた開発者が、いまさらGUIゴリゴリの世界に戻るのは難しい。RADツールも最近は力入れる会社が減っているし、個人的にはRADツールが吐くソースコードって、あとからメンテナンスしにくいので嫌い。


そんなわけで、簡単にGUIが作れるフレームワーク、「S2JFace」を作ってしまおうかと、画策しております。

今のところ考えているのは、以下のような要件です。

  • XMLでGUIが記述できること(基本的にはXULとかXAMLと同じ考え方)
  • 画面定義用XMLは、手で書いてもある程度の生産性が確保できるよう、できる限り簡潔にすること
  • 最終的には画面定義XMLを出力GUIエディタも提供すること
  • ボタンやメニューを選択したときなど、ロジックとの連携はS2JSFと同様にメソッドバインディング、バリューバインディングができること
  • GUIツールキットとしては Eclipse で提供されている、SWT・JFaceを利用すること

実は、今日のカンファレンスでデモした「DIでジャンケン」アプリケーションは S2JFace のプロトタイプ版で動いていました。画面はすべてXML定義、ボタンを押したときのアクションは、メソッドバインディングを使って POJO を呼び出せるようになっています。(メソッドバインディングの部分はイベントに間に合わせるため、かなりインチキ実装だけど)

Seasarとの連携がミソで、コンテナに登録したコンポーネントを呼び出せるということは、S2RMI や S2Axis、S2JMS といった Remoting 系のプロダクトと組み合わせれば、クライアント・サーバアプリも簡単に作れてしまいます。

さらに、XML部分については、デザインとロジックを分離するために、Mayaaの利用も視野に入れています。

「車輪の再発明」と言われるかもしれませんが、一つの挑戦としてやってみたいし、どちらにせよ本業の方でも必要になりそうなので、動き出そうかと思っています。（あ〜あ、書いちゃった(^^;）