Routing のお勉強

Rack に興味を持ったついでに以前からチェックだけしておいた

Horde/Routes: Elegant URL Handling

を最近読んでいた。この話を twitter と #openpear と #coderepos に振ったら反応があったのは coderepos だけだった。そこで

を知った。話はそのまま 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 って開発者の目指す方向とユーザーの目指す方向が合ってないんじゃないか。

More