利便性 - 細部は機能と同様に重要

おそらく、Play フレームワークに関するもっとも衝撃的な事実は、他の Java web アプリケーション開発フレームワークに対する最大の利点がきちんとした機能リストに当てはまらないということであり、Play フレームワークを使って何かを作って初めてその最大の利点が明らかになるということです。その利点とは、利便性です。

利便性は機能と切り離されることに注意してください。以下において、他のフレームワークではこれを達成できないと示唆するわけではありません: ただ、Play においては、より簡単に、快適に達成できると主張するだけです。ギークたちは、難解な事柄を解決することを楽しみ、ただ動くだけのものの価値を正当に評価せず、しばしば利便性について完全に盲目的になってしまうので、このことを強調する必要があります。

web デベロッパによる web デベロッパのためのフレームワーク

Play フレームワークが ‘web デベロッパによる web デベロッパのためのフレームワーク’ であること、web の原則を優先して Java のそれを二の次にするという型破りな立ち位置にあることを初めて耳にしたとき、それはここから始まる何か変わったことの最初のヒントになります。特に、Play フレームワークは Java エンタープライズエディション (Java EE) の規約と共にあることよりも、W3C の World Wide Web アーキテクチャ に沿うことを優先します。

完全主義者のための URL

例えば他のモダンな web フレームワークのように、Play フレームワークは Servlet API には常に欠けている任意の ‘清潔な’ URL のためのファーストクラスサポートを提供します。これを書いている時点で 完全主義者のための Struts URL という Servlet API ベースである Struts 1.x web フレームワークのための回避策一式が、前世代 Java web テクノロジーについての 2005 年の記事であるにも関わらず、www.lunatech-research.com にある 160 の記事から人気記事トップ 3 に残り続けているのは偶然ではありません。

Servlet ベースのフレームワークにおいて、Servlet API は有用な URL ルーティングサポートを提供しません; Servlet ベースのフレームワークは、全てのリクエストをひとつのコントローラ Servlet へ転送するよう web.xml を構成し、さらなる追加設定と共に、フレームワーク内に URL ルーティングをじっそうします。この段階では、Servlet API が充分に強力でなかったために URL ルーティング問題を解決しようとして失敗してきたことや、web アプリケーションを直接作らなくて済むような低レベル API を目指してきたことは重要ではありません。いずれにせよ、結果は同じです: web フレームワークはそれ自身が HTTP の上のレイヤであり、Servlet API の上にレイヤを追加します。

Play は web フレームワーク、HTTP API そして HTTP サーバを結合し、同じことをより少ないレイヤと単一の URL ルーティング構成行えるようにします。Groovy や Cake PHP のようなこの構成は、HTTP リクエスト - HTTP メソッド、URL パスを反映し、マッピングを行います:

# Play 'routes' configuration file…
 
# Method   URL path         Controller
 
GET        /                Application.index
GET        /about           Application.about
POST       /item            Item.addItem
GET        /item/{id}       Item.getItem
GET        /item/{id}.pdf   Item.getItemPdf

この例には、ひとつ以上のコントローラがあります。最後のふたつの URL において id という URL パラメータを使っていることも確認できます。

より良いユーザビリティは普通の人々だけのためのものではありません

Play が web デベロッパによる web デベロッパのためのフレームワークであるという考えのもうひとつの見方は、web デベロッパのソフトウェアデザインに対するアプローチが Java EE デベロッパとどのように異なり得るのかを考えることです。ソフトウェアを書くとき、なにを主要なインタフェースとするでしょうか? web デベロッパの場合、主要なインタフェースは、HTML, CSS そして (どんどん増えている) JavaScript によって構築された web ベースのユーザインタフェースです。一方、Java EE デベロッパは、システム内の他のレイヤから使用される Java API や、もしかしたら web サービス API を主要なインタフェースとして考えるかもしれません。

Java インタフェースは他のプログラマによって使われることを意図している一方、web のユーザインタフェースはプログラマでない人々によって使われることを意図しているため、この違いは大事です。どちらの場合も、良いデザインは利便性を含んでいますが、普通の人々のための利便性はプログラマのための利便性とは同じではありません。ソフトウェアのこととなるとプログラマは貧弱な利便性にもよく対処してしまうので、プログラマ向けの利便性よりも一般の人向けの利便性の方が、ある意味では高い水準となります。これは Good Grips という台所用品に少し似ています: これは、元は関節炎を患う高齢者向けのよい利便性を持つように設計されていましたが、より持ち易いように道具を作ることは全てのユーザにとって良いことであることが分かりました。

フレームワークそれ自身の中に web アプリケーションにおいて達成したい利便性が含まれているため、Play フレームワークは違います。例えば、ブラウザに表示されるこのフレームワークのドキュメントやエラーメッセージのような web インタフェースは、ただただ有用です。同様に、エラーが発生した際は、ページいっぱいの無関係な情報やスタックトレースが出力されることを避け、web デベロッパのための、より注目すべき、より有用な情報を残します。

この短いスタックトレースを提供する JSF web アプリケーションを想像してみてください。実際のところ、Play はさらに先へ行きます: スタックトレースを表示する替わりに、web アプリケーションはスタックトレースの中に見られるアプリケーションコードの最終行を示します。結局のところ、本当に知りたいのは自身のコードにおいて最初におかしくなったのはどこかということです。

この類いの利便性は、それ自身では起こりません; Play フレームワークは、重複し、無関係な情報を取り除き、何が重要かということに注目するよう、かなりの努力をします。

品質は細部に宿る

Play フレームワークにおいて、多くの品質は細部に宿ることが分かります: それらひとつひとつは大きく重要な機能と比べると小さなものかもしれませんが、結果として開発体験をより快適かつ生産的なものにします。Play を使って何かを作るときに感じる温かみは、通常、フレームワークとの格闘の結果として生じるフラストレーションの不在なのです。

オリジナルは Peter Hilton による Lunatech Research ブログで公開されました。