トップ 差分 一覧 ソース ヘルプ RSS ログイン

WhyClick

なぜClickなのか

このトピックではClickのデザイン哲学と背景について述べます。そしてなぜ新たなWebアプリケーションフレームワークを作ろうとしたのかを説明します。

Clickは近代的なJEE Webアプリケーションフレームワークです。自然なリッチクライアントスタイルのプログラミングモデルを提供します。Clickの鍵となる特徴には以下のものがあります:

 学習の容易さ

Clickは学習が容易になるようデザインされており、新しい開発者でも1日のうちに覚えることができます。これは様々なスキルレベル、モチベーションを持った開発者が集まる業務開発チームではとても重要なことです。

以前、私はTapestry (2.3) を開発チームに導入したことがありました。しかし、それは平均的な開発者にとっては複雑すぎで、学習は難しいものでした。私がTapestryを導入した2つの開発チームは結局Tapestryを捨ててStrutsに戻りました。

また、ClickはStrutsよりも学習が容易です。Strutsは本質的にはシンプルなコマンドパターンデザインに基づいたものですが、とても複雑で紛らわしいデザインになっています。

業務での開発で採用しやすいよう、Clickにはオープンソースのフレームワークの中でも最も充実したドキュメントがあり、実際に動作する豊富なサンプルも含まれています。

 コンポーネント、ページ指向

もしあなたがSwingやVB、Delphiなどで伝統的なGUIプログラミングを経験したことがあるのであれば、JEEにおけるWeb開発には非常に問題があることがわかるでしょう。JEEにおけるWeb開発は痛々しいほど鈍重で、複雑で、そして間違いやすいのです。

JEE Webフレームワークの第一世代であるStrutsはコマンドパターンデザインとJSPのtaglibのセットを提供します。しかし残念なことにStrutsを使っても原始的なアクションフォームと共に動作するアクションをURLにマッピングする作業に忙殺されることでしょう。Strutsを使ってもほとんど作業は楽にならないのです。

Tapestryはコンポーネント指向に基づいた最初のJEE Webフレームワークであり、コンポーネント階層、ページ、イベントベースのプログラミングモデルを導入しました。これは遥かに生産的な方法であり、デスクトップのGUIアプリケーション開発と同じスタイルでの開発を期待させるものでした。

Clickはこのページとコンポーネントに基づいたアプローチを採用しています。そしてより簡単で使いやすくなっています。

Clickはコントロールコンポーネントとイベントベースのプログラミングモデルをフィーチャしたページ指向のデザインを提供します。ClickはHTMLの主な要素に対応する40以上のコントロールが含まれています。これはプログラミングをずっとシンプルにします。

Clickの入力フォームとコントロールは自動バリデーション、レンダリング機能を提供します。入力フォームの開発がとても迅速かつ堅牢になります。

 JSP & MVC フリー

ClickはJSPやMVCモデルに縛られていません。これはとても良いことです!

JSPとMVCパターンの誤った適用によってJEEにおけるWeb開発は何年も阻害されてきました。これはとても踏み込んだ見解であることは私も理解していますので詳しく説明させてください。

MVCはデスクトップGUIのデザインパターンで、UIデザインにおける役割を分離します。モデルはデータ、ビューは描画、そしてコントロールはデータを変更するためのものです。現在、MVCは同じデータを共有する複数のビューとコントロールの問題を解決するためのかなり洗練されたUIパターンとなっています。

しかしながらほとんどのUI開発においてMVCは過剰なものです。コントロールとビューは通常同じものです。例えばセレクトボックスはビューでありコントロールでもあります。そしてまたモデルを保持しています。幸いSwingではほとんどのMVCデザインは背後に隠されています。VBやDelphiにはそもそもMVCという概念がありません。

JEEにおけるWeb開発ではデザインパターンが大いに転用され、MVCは脇に置かれて、初期のServlet/JSPデザインがMVCと呼ばれるようになりました。この分析ではモデルは通常DAOであり、ビューはJSP、そしてコントロールはServletでした。

この影響でUI MVCの役割を厳密に分離するというデザインコンセプトにロックされることになりました。これはレイヤを分離するという一般的な構造上の原則、そしてJSPは出力のレンダリングのみに適しているという事実にフィットします。

残念なことにこの厳密な分離の代価はカプセル化でした。ほとんどのリッチクライアントUIコンポーネントはレンダリングとコントロールの機能をカプセル化しています。Clickにコンポーネント(Controls)は自分自身のレンダリング(ビュー)と、何を意図するかを理解すること(コントロール)の両方について責任を持ちます。

実際にこのコンセプトを確認するために、ActionLinkコントロールを持つシンプルなClickページを見てみましょう。

次にmyLinkというActionLinkコントロールをHTMLページテンプレートに配置します。

実行時にhref属性を以下のように描画します。

ユーザがリンクをクリックした場合、ActionLinkコントロールはページのonClick()メソッドを呼び出します。

これとは逆にJSP MVCアーキテクチャではJSPを参照することはできます。しかしそれが何を言いたいのか理解することはできないでしょう。少し考えてみてください。自分自身の動作について責任を取らないUIコンポーネントは1つもありません。もしあったとしたら、その責任はいったい誰が取るのでしょうか...

あなたが数々の断片をつなぎ合わせてそれが動作するよう責任を負うのです。Strutsの場合は以下のようになります。

  • カスタムアクションクラスを書く
  • カスタムアクションフォームクラスを書く
  • struts-config.xmlファイルにaction要素を記述する
  • struts-config.xmlファイルにform-bean要素を記述する
  • validation.xmlファイルにform要素を記述する
  • validation.xmlファイルにfieldバリデーション要素を記述する
  • action、form-bean、form、field要素のバインディングを確実にする
  • JSPファイルでtaglibを記述する
  • JSPファイルで<htm:form>と<html>フィールドタグのXML要素、属性を正しく記述する

大規模なアプリケーションの開発ではこれは膨大な量の、退屈で誤りを引き起こしやすい作業です。

これらのデザインの別の側面としてロジックの形態がJavaからXML設定ファイルに移動したという点があります。TapestryやSpringMVCではXMLが非常に多くなります。問題はコンパイル時に検出可能なエラーが実行時にならないとわからないという点です。また、大量のXMLの作成とメンテナンスはJavaコードと比べて難しいものです。Java IDEのリファクタリングツールは利用可能なXMLツールよりもかなり洗練されています。

Clickは他のコントロールを継承して新たなコントロールを作成したり、より洗練されたUIコンポーネントを構築するために複数のコントロールを集合させたりといったような、オブジェクト指向のデザインを適用することを可能にします。たとえばClickのCreditCardFieldコントロールはTextFieldのサブクラスであり、カードの種類を指定するためにSelectコントロールを含んでいます。

 Velocity

ClickはHTMLのレンダリングのためにVelocityテンプレートエンジンを使用します。Velocityはシンプルで学習と利用の容易な命令セットを持っています。例として以下のテンプレートを見てください。

このコードが何をするか、taglibドキュメントを参照しなくても理解できるはずです。Velocityの使いやすさはClickにとって理想的な選択でした。

Velocityのトリッキーな点の1つであるconfigurationはClickによって自動的にハンドリングされます。

ClickではレンダリングにJSPを利用することもできます。最近はJSP 2.0とJSPの式言語によってJSPの使い勝手が改善されているという点については触れておかなければならないでしょう。