Hello, Play framework

Play frameworkを使ったことがある人はどれぐらいいるんだろうか。
こんなに面白いフレームワークとは思わなかった。
いや、フレームワークというより、プラットフォームです。

まえにJava on Railsなんて宣伝を見てしまったせいでスルーしていた。
たしかに「Rails使いに媚びてDjangoをJavaにポートした」と言えないこともないけど。
ためしてから宣伝してください。迷惑です。
見所はコマンドラインなんかじゃない。まあ、Python for Windowsがついてくるのは確かに面白いけど。
なんといってもJavaの使い方が革命的に面白い。

なんと表現すればいいのか。
「コンパイルさえ通せば、あとはまかせとけ」
といったところか。
staticメソッドを積極的に使い、記述をシンプルにすることが使命であるようだ。

まずはこの三つの機能を見てみます。
1. Bind an HTTP parameter to a Java method parameter
リクエスト引数をメソッド引数に名前で結びつけちゃいます。
メソッド引数名ですよ？
アノテーションなんて不要です。
まさしく名前つき引数なのです。

routesに

GET  /show/{name}  Application.show

とあったとして、

/show/Tom?page=2

にアクセスがあったならば

public static void show(String name, Integer page)

では、nameにTomが入り、pageは2になるのです。
型や順番や偶然を使っているわけではありません。
引数名を見ているのです。

2. Redirect to an action by calling the corresponding Java method
一度でもDjangoのreverseを使ったことがあれば、URLなんて直接書きたくないと思うことでしょう。
この場合ならばControllerのメソッド名で指定したいところ。
しかし、文字列でredirect(reverse("Books.list", page))では芸がない。
redirect(Books.list, page)と書くことができればいいけど、残念ながらコンパイルエラーになるでしょう。
Javaのメソッドとフィールドの名前空間と同じであれば、もっとまともなフレームワークを作れたのですけどね。
そこでPlayは突き抜けました。
Books.list(page)
と書けば勝手にリダイレクトされます。

staticメソッドだからといって気を抜いてはいけません。
フォワードではなく、間違いなくブラウザにResponseがかえります。

3. Don’t Repeat Yourself when passing Java objects to templates
Spring MVCではデフォルトの名前というものが存在します。
User => user, List<User> => userList
というように、型から名前をつけてくれるので、テンプレートに名前をつけながら渡す必要がありません。
しかし、Playでは1と同様に型ではなくローカル変数名を取得します。
ローカル変数名ですよ。
pythonでもrender(article=article, user=user)と書かなきゃいけないってのに。
bytecode enhanceってレベルじゃないですね。
ただ、残念ながら実行時に解決なので、いっそコンパイラを作って変数名をbytecodeに埋め込んでほしいと思います。

と
以上のようにJavassistの黒魔術を駆使して理想郷を追い求めます。

だがちょっと待ってほしい。
この黒魔術
まさにDIでやっていることそのままではないか。
DIの黒魔術を許してこれを許さないなんて、なんという傲慢。
フィールドに準備しておくか、staticで呼び出すかの違いしかない。
ルールを決めておけばOKとはどの口が言ったものか。
Mockitoを見て便利だといっていたじゃないか。
staticであればコードがそのまま追えるなんて、いつまで20世紀にしがみついているんだ。
もうそんな時代じゃないんだ。
EJB2信者なんて、もういないでしょ？

DIに飼いならされた開発者たちなら、ルールだと説得すればすぐ納得するね。
賭けてもいい。
逆に、「Proxyを使って実現できるDIとは違う」と反論するような人が相手なら、
メリットを比較してあげれば、いずれは「ひでえ」といって納得するはず。

残念なところもいくつか挙げておく。

1. アプリの構造が貧弱
Djangoのアプリを引き継いでほしかった。
一定以上の規模のものを作れるのだろうか。
心配です。
2. formが貧弱
ModelとはべつにFormクラスを作ってください。
ModelべったりのFormだと画面や権限に応じてValidationや項目を変えづらい。
3. Bytecode拡張される範囲が不明
Bytecode拡張される範囲が明確でないため、自分で拡張しようとすると
なかなか恐ろしい。
たとえば、もう少し複雑で動的なFormがあって、複数のControllerで共有したいとすると、
自分で独自のクラスを作りたくなるけど、どこまで拡張してくれるのか試すまで、
いや、試してもよくわからない。
returnをなくそうとしたり、Javaの言語仕様をとことん無視しようとしているので、
なかなか機能拡張は難しそう。

まとめ

二週間以内で作るものにはちょうどいいかも。
どうしてもJavaがいい。
Javaじゃなきゃいやと根拠なく言われたときに使うことを考えてもいいかもしれない。
Springの起動が遅くて、決別したいとは常々思っているので、
こういうアプローチが流行ってくれば面白いとは思っています。
Bytecode拡張以外は使いやすく、わかりやすい機能がてんこ盛りなのでお勧めです。
Bespinとうまく連携すれば、全文検索つきのCMSが結構簡単に作れるかも。