Rack に興味を持ったついでに以前からチェックだけしておいた
Horde/Routes: Elegant URL Handling
を最近読んでいた。この話を twitter と #openpear と #coderepos に振ったら反応があったのは coderepos だけだった。そこで
- Routes (Python版。Railsの routing 部分の元。）
- PEAR :: Package :: Net_URL_Mapper（上の routes.py を参考にした PHP 版）
を知った。話はそのまま RouterCon 方面へ行って完全にネタとして昇華することができた。合唱。
ま、それはともかく、
- PHP の世界はフレームワークに多少不満があっても我慢して使うし、Router に興味ある人はあんまりいないんじゃ？
- なんだかんだでみんな routes.py を参考にしている
という話は参考になったし、なかなか興味深かった。いちばん共感を覚えたのは
11:08:15 <tokuhirom__> うわー
11:08:31 <tokuhirom__> せっかくの routes.py のカッコイイDSLが
11:08:35 <tokuhirom__> array() によって台無しだー
いやまったく :-) ホント PHP はキツいっす。array() のヒドさは犯罪級です。便利なのは分かったから、もう一つ踏み込んで array に分解してくれるレイヤーを挟まないと DSL としては機能しないよな。まぁ現実的には時間とかモロモロの兼ね合いで array() むき出しって自分でもよくやるんだけどさ。
あとこの辺
11:40:35 <kazuho> ルーターの定義ってなんすか？
11:41:14 <tokuhirom__> なんだろう
11:41:27 <kazuho> HTTP::Router あたり読めばわかります？
11:41:39 <tokuhirom__> Web Application において、コントローラー and/or
アクションと URL とのマッピングを定義するもの
11:41:41 <tokuhirom__> かな。
11:41:48 <kazuho> 双方向？
11:42:00 <tokuhirom__> URL => Controller/Action
11:42:05 <tokuhirom__> ですね。
11:42:12 <tokuhirom__> 逆方向は optional な要素ではないかと。
11:42:38 <kazuho> あざーす。じゃあ、それも論点ですかね。あまり需要ないのかなー
実際 View を書くときには誰かが逆方向の部分を担当しないと意図した Routing にマッチしない URL を簡単に生成できて、アプリケーションとして管理しきれなくなってしまう。Rails 的には Helper がこの部分を担当することにしてあるのかな？ 少なくとも Rails 系の CakePHP では View の Helper で対応する方針になってるみたい。フルスタックのフレームワークではまぁどこで処理しても問題ないやね。
話は戻って Horde/Routes ともう一つ似たライブラリである Net_URL_Mapper では、Horde/Routes だけが逆方向の URL の組み立て機能も持っており、単体の routing ライブラリとして扱いやすいのではないかと思う。速度差とかは計ってないのでこれだけで一概に Horde/Routes の方が優秀とは言い切れないけど、単体の router, mapper は個人的には逆方向の変換も持っていてくれる方が安心感がある。
他に Zend Framework も見てみたけど、この routing は Rails 風のようで微妙に違う。また Zend Framework は疎結合を意識しており、Router と Dispatcher を別々に利用できそうに見えるんだけど、実際処理を追いかけて行くと PHP 5 から入ったタイプヒンティングが邪魔しており、duck type 的に別なライブラリを突っ込むのはちょっと難しそうな感じ。変なところで Java 的な考え方に振っちゃうのはちょっと勘弁してほしい。PHP って開発者の目指す方向とユーザーの目指す方向が合ってないんじゃないか。