ルーティングを使ってシンプルなアプリケーション開発を
DESCRIPTION
TRANSCRIPT
Who am I?
海老原昂輔 (Kousuke Ebihara) 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 でやりやすくなるよ！
質疑応答タイム
気軽にどうぞ！