Play 2.x の QueryStringBindable, PathBindable について
コメントした。それと、もっと細かい疑問というか反論(?)というかイマイチまだ懐疑的なところがあるので、あとでblogに書くか・・・ URL "Play 2.x の QueryStringBindable, PathBindable について"
2013-02-16 13:35:02 via web
まず一般的には
「独自に定義しておくと、処理まとめられて、感心事分離できていいですね」
でいいです。例えばもっと具体的に
「何回以上使うなら、独自にPathBindable定義するか？」
ですかね。1回しか使わないなら、デメリットのほうが大きそうです。そして、まとめる事自体は、PathBindableとか使わなくても、共通の関数とか「Actionを返す関数」を作っておいて、cotrollerの中でやってもそれなりにできてしまうと思います(ちょっとかっこ悪いかもしれないが)
まずは、現状2.1.0では以下のように
templateとかroutesのimportとかをBuild.scalaで設定する仕組みダサすぎるのでなんとかしてほしい。
@tototoshi TaskKeyならまだ自分で仕組み作れるのに、SettingKeyになっていて、なおかつhashの計算が適当 URL なあたりが。(そして"Yes you can also do a clean"にｲﾗｯ☆としていた)
2013-02-16 14:38:18 via web to @tototoshi
@xuwei_k あwこれさっき自分もはまったw
2013-02-16 14:40:00 via YoruFukurou to @xuwei_k
- Build.scalaを編集して
- リロードして
- cleanするか、明示的にroutesファイルいじってrecompileさせる
のがわりと面倒という話ですね。*1
「共通化」や、「単純な文字列から(例えば)日付の型へのパース処理を分離できて、コントローラー内では本質的なロジックの処理のみを記述できる」という以外のメリットとしては、「reverse routing」になると思いますが、それのメリットとデメリットが色々あって難しいというか、整理できていない。
「型安全」なメリットはあるけど、開発中で、もしPathBindableのための型や置く場所が変わってimport変えないといけない場合に、わりと面倒・・・。
あとはすでにviewやcontrollerの中で、大量に直接StringやIntを書いてしまっている状態の場合に、わざわざ独自の型を定義したものに書き換えるほどのメリットはあるのか？とか。
そのあたりが、IDEのリファクタリング機能でとても簡単に出来る状態ならいいですが、現状おそらく微妙でコンパイルやテストしないとわからないかも？とか
他には、個人的にPathBindableとりあえず使ってみたくても、他の人や、特にデザイナーにとってそれがわかりやすいのか？とか(単にStringやInt渡すのではなく、よくわからないままScalaのオブジェクト書くことになる？)
あと、どのくらいのまでの処理をPathBindableに任せるか？(内部で、DBアクセスして、userが存在するか取得してきて(ry とか、そのなかでDBアクセスまでしていいのか？など)
必ずBadRequestやNotFound返す場合はいいけど、(例えばStringから日付型に)パースする処理は同じでも、もしcontrollerというかURL毎にエラー処理を分けたい場合は、結局使えないよなぁーとか。
日付型でもUser型でもいいけど、それらを受け取るようにした場合に、(テスト時やreverse routing時などに)それらのインスタンスを"新規に"作って直接渡す機会があったとして、新規に作る構文が長かったり、そもそも作るのが面倒になる可能性がある場合は、使いづらいよなぁとか。
とまぁこのあたりの疑問が大量に浮かんだのですが、それらの指針やベストプラクティスが、全然確立されてない(公式ドキュメントにも指針は全く書かれていないはず)あたりが、まだまだ若いフレームワークだなぁと思いました。
*1: せめてTaskKeyにするか、routesの文法拡張して、routesの一番上にimport文を直接書けてもいい気がする
