ルーティングを使って
シンプルなアプリケーション開発を
株式会社手嶋屋海老原昂輔
<ebihara@tejimaya.com>

Who am I?
 海老原昂輔 (KousukeEbihara)
 21歳
 17歳（高校2年）の冬より有限会社手嶋屋
（当時）にアルバイトとして勤務し、
OpenPNEと出会う
 私立日本大学芸術学部演劇学科を中退、
2008年10月に株式会社手嶋屋に入社し、
今に至る

OSS 活動
 OpenPNE3 Platform の生みの親
 OpenPNE2, OpenPNE3 の lead developer
 (OpenPNE3) opCommunityTopicPluginの臨時
lead developer
 関連する OSS プロジェクトへのパッチ提供
 symfony
 Doctrine
 PHP Shindig
 Chiara_PEAR_Server

それでは本題
 今日はみなさんにsymfonyのルーティング
の素晴らしさを訴えかける人として来ま
した
 ただし OpenPNE3 では全然使いこなしてい
ないところも残ってるけど……＞＜
 基本的にはsymfony 1.2 を前提に解説しま
す

ところでみなさん、こんな
アクションを書いてませんか？

ところでみなさん、こんな
アクションを書いてませんか？

ところでみなさん、こんな
アクションを書いてませんか？

みなさんのアクションは
統一が取れてますか？
 member モジュールのメンバー追加用アク
ションは create なのに、 diary モジュー
ルだと対応するアクションが insert に
なっている
 member モジュールと diary モジュールの
表示用アクション show は同じパラメータ
を取るにもかかわらずバリデーション
ルールが統一されていない

ルーティングをうまく使うと
 特定のリクエストパラメータからデータベー
スのレコードを取得する処理や、レコードの
存在チェックをアクション側でおこなわなく
て済む
 リクエストパラメータに関するバリデーショ
ンをアクション側でおこなわなくて済む
 リクエストメソッドのチェックをアクション
側でおこなわなくて済む
 アクション名やバリデーション処理を共通化
しやすくなる

レコード取得をアクション側で
おこなわないようにする
 apps/frontend/config/routing.ymlでルー
ティングルールの設定をおこなう
 ルール処理用のクラスとしてsfObjectRouteを
使うよう設定
 ここでは Doctrine に特化したsfDoctrineRouteとい
うsfObjectRouteの派生クラスを例に取ります
 対象となるモデルの設定等もおこなう

レコード取得をアクション側で
おこなわないようにする
 こんな感じの設定になるはず

レコード取得をアクション側で
おこなわないようにする
 アクション側で簡単アクセス
 これすら面倒であればpreExecute() に書
いたってよい
 アクション毎のパラメータの違いとかモデル
の違いとかは全部ルーティング側で吸収して
くれているので扱いやすいはず

レコード取得をアクション側で
おこなわないようにする
 いろんなリクエストパラメータを組み合
わせてレコードを取得したい場合
 指定したモデルに実在するフィールド名と同
じ名前のリクエストパラメータを指定した場
合、そのパラメータの値でレコードが絞り込
まれる
e.g. /member/birthday/1988-04-23
 ただし別モデルへの問い合わせが必要になる
など、場合によってはsfObjectRouteクラスの
派生クラスの作成が必要になる

レコードの存在チェックを
アクション側でおこなわないようにする
 実はもうできています
 sfObjectRouteは、デフォルトではレコードが
取得できなかった場合に sfError404Exception
をスローします

レコードの存在チェックを
アクション側でおこなわないようにする
 ということは最初の show アクションはこ
うすることも可能ですね！

レコードの存在チェックを
おこなわないようにする
 レコードが取得できなくてもよい場合は
以下のように設定すればOK

リクエストパラメータのバリデーションを
アクション側でおこなわないようにする
 簡単なバリデーションなら正規表現を
使って設定に書ける

リクエストパラメータのバリデーションを
アクション側でおこなわないようにする
 複雑なバリデーションなら独自のsfRoute
クラスの派生クラスが必要
 型チェックとか
 正規表現とかじゃなくてis_int使ったりとか
 日付の妥当性チェックとか

リクエストメソッドのチェックを
アクション側でおこなわないようにする
 またもや apps/frontend/config/routing.yml
でルーティングルールの設定
 クラスにsfRequestRouteを指定すればできま
す

アクション名やバリデーション処理
の共通化
 sfRouteCollectionを使う
 ルーティングの設定類をまとめたクラス
 これを apps/frontend/config/routing.ymlで指定すること
で、一気に複数のルーティング設定がおこなわれる
 ORM 毎にsf****RouteCollection的なクラスが用意
されているのでそれを使うのが手っ取り早い
 list
 new
 create
 edit
 update
 delete
 show

アクション名やバリデーション処理
の共通化
 これだけ
 有効にするルールを指定することも

最後に注意事項
 今まで紹介してきたようにルーティングの設定をおこ
なってアクションへのアクセス制御をおこなう場合、
必ず「symfonyデフォルトのルーティング設定を無効
化」してください
 ルーティングルールにマッチしなかった場合、
symfonyは別のルールにマッチするかどうかチェック
して……ということを繰り返していきます。最終的に
どのルールにもマッチしなければ無事 404 になります
が、symfonyデフォルトの設定が残っている場合、
/:module/:action などのURLにより予期しない形でア
クセスされてしまいます
 ですので、指定したルーティングルール経由でしかア
クションのアクセスを認めない場合symfonyデフォル
トのルーティング設定を無効にしなければなりません

まとめ
 リクエストからレコードを取得
 それsfObjectRouteでできるよ！
 レコードの存在チェック
 それsfObjectRouteでできるよ！
 リクエストのバリデーション
 sfRouteの正規表現などでできるよ！
 独自のルーティングクラスでもできるよ！
 リクエストメソッドのチェック
 それsfRequestRouteでできるよ！
 アクション名やバリデーション処理の共通化
 sfRouteCollectionでやりやすくなるよ！

質疑応答タイム
気軽に
どうぞ！