Zend_Controller_Router_Route はフレームワークの標準のルートです。 簡単に利用でき、柔軟なルート定義が可能です。各ルートには、まず (静的および動的な) URL のマッピングが含まれ、 そしてデフォルト値および変数についての制限を指定して初期化します。

とある架空のアプリケーションで、コンテンツの作者情報のページが必要になったとしましょう。 ブラウザで http://domain.com/author/martel にアクセスした際に、"martel" とかいう人についての情報を見たいわけです。 この機能を実現するためのルートは、次のようになります。

Zend_Controller_Router_Route のコンストラクタの最初のパラメータは、ルートの定義です。 これを URL にマッチさせます。ルート定義は静的な部分と動的な部分で構成され、 それをスラッシュ ('/') で連結します。 静的な部分は単なるテキスト (例. author) です。 動的な部分を変数と呼び、変数名の前にコロンをつけて (例. :username) 表します。

注意: 文字の使用法
現在の実装では、(スラッシュ以外の) 任意の文字を変数名として使用できます。しかし、 PHP の変数名として使用できる文字だけを用いることを強く推奨します。 このようにしておくことで、 将来実装が変更されたときにバグを引き起こす可能性を抑えられます。

この例のルートは、ブラウザで 'http://domain.com/author/martel' を指した際にマッチします。 この場合、すべての変数の値が Zend_Controller_Request オブジェクトに注入され、ProfileController からアクセスできるようになります。 この例が返す変数は、以下のようなキーと値のペアを持つ配列となります。

その後、Zend_Controller_Dispatcher は (デフォルトモジュールの) ProfileController クラスにある userinfoAction() メソッドを実行します。変数にアクセスするには、 Zend_Controller_Action::_getParam() あるいは Zend_Controller_Request::getParam() メソッドを使用します。

ルート定義には、特殊文字 (ワイルドカード) を含めることができます。これは '*' 記号で表します。 これを使用して、Module ルートと同様にパラメータを扱う (変数名 => 値 のペアを URI で定義する) ことができます。 次のルートは、Module ルートの挙動をまねたものです。

これまでの例では、すべて動的なルートを使用していました。 つまり、特定のパターンにマッチするものについてのルートです。 しかし、時には特定のルートを固定してしまい、 わざわざ正規表現エンジンを動かしたくない場合もあるでしょう。 そんなときには静的なルートを使用します。

上のルートは http://domain.com/login という URL にマッチし、 AuthController::loginAction() にディスパッチされます。

注意: 警告: 静的なルートにはまともなデフォルトが必須
静的なルートは、URL の一部をリクエストオブジェクトへのパラメータとして渡すことはありません。 したがって、リクエストのディスパッチに必要なパラメータは すべてデフォルトでルートに渡すようにしておかなければなりません。 "controller" や "action" のデフォルト値を省略してしまうと予期せぬ結果を引き起こし、 リクエストがディスパッチ不能になってしまうでしょう。
一般に、以下のデフォルト値は常に渡すようにしておきましょう。

• controller

• action

• module (デフォルト以外の場合)

オプションで、起動時に "useDefaultControllerAlways" パラメータをフロントコントローラに渡すこともできます。

1. $front->setParam('useDefaultControllerAlways', true);

しかし、これはあくまでも次善策であり、 デフォルトを明記しておくほうがおすすめです。

デフォルトのルートや静的なルートに加えて、正規表現によるルートも使用可能です。 このルートは他のものに比べてより強力で柔軟なものですが、 多少複雑になってしまいます。そして、より高速になります。

標準のルートと同様、このルートを初期化する際にはルートの定義とデフォルトを指定する必要があります。 サンプルとして、archive ルートを作成してみましょう。 これは先ほど定義したものとほぼ同じですが、今回は Regex ルートを使用しています。

定義された正規表現のパターンが、リクエストオブジェクトに注入されます。 上の例では、http://domain.com/archive/2006 がマッチした後の結果の値は次のような配列になります。

注意: ルータとのマッチングを行う前に、URL の先頭と最後のスラッシュは取り除かれます。 結果として、URL http://domain.com/foo/bar/ は正規表現 foo/bar にマッチすることになります。 /foo/bar にはマッチしません。

注意: 行頭と行末を表す文字 (それぞれ '^' および '$') が、すべての式の前後に自動的に付加されます。 したがって、これらは正規表現で指定する必要はありません。

注意: このルートクラスは、区切り文字として '#' を使用します。 つまり、ルート定義の中にハッシュ文字 ('#') がある場合は、それをエスケープする必要があるということです。 スラッシュ ('/') をエスケープする必要はありません。 '#' (アンカー) は通常はウェブサーバに渡されることはないので、 エスケープが必要になることはまずないでしょう。

定義されたサブパターンの内容は、通常通りの方法で取得できます。

注意: このキーは、文字列 ('1') ではなく数値の 1 であることに注意しましょう。

このルートは、標準のルートとまったく同様に動作するわけではありません。 'year' のデフォルトが設定されていないからです。 また、year のデフォルトを設定してこれをオプション扱いにしたとしても、 最後のスラッシュをどうするかという問題が残ります。 これを解決するには、year 部をスラッシュを含めてオプションにし、 その数値部のみを取得するようにします。

まだ問題が残っていることにおそらくお気づきでしょう。 パラメータとして数値のキーを使用するのはなかなか難しく、 長い目で見れば問題を引き起こす可能性が高くなります。 そこで三番目のパラメータの登場です。 このパラメータは、正規表現サブパターンとパラメータ名のキーを関連付けます。 簡単な例を見てみましょう。

この結果は次のようになり、これがリクエストオブジェクトに格納されます。

関連付けは両方の方法で定義でき、任意の環境 (例. Zend_Config) で動作します。 キーには変数名あるいはサブパターン番号のいずれかを含めることができます。

注意: サブパターンのキーは整数値でなければなりません。

リクエストの値から数値キーが消え、代わりに名前がつけられたことに注目しましょう。 もちろん、お望みなら数値での指定と名前での指定を共用することもできます。

この結果、リクエスト内には数値キーと名前つきキーが共存することになります。 たとえば、URL http://domain.com/archive/2006/page/10 は次のような値になります。

正規表現を簡単に反転させることはできないので、 URL ヘルパーやこのクラスのメソッドを使用するには 逆の URL を準備しておく必要があります。 逆方向のパスは sprintf() 形式の文字列で表し、 コンストラクタの四番目のパラメータとして指定します。

これまで説明してきたことは、すべて標準のルートオブジェクトでも可能なことです。 それでは、Regex ルートを使用するメリットはいったい何なのでしょう? これを使用すると、あらゆる形式の URL を制約なしに定義することができます。 仮に、あなたが blog を持っており http://domain.com/blog/archive/01-Using_the_Regex_Router.html のような URL を作成したいと考えたとしましょう。 このパスの最後の要素 01-Using_the_Regex_Router.html から記事の ID とタイトル/説明 を取得するにはどうしたらいいでしょうか？ 標準のルートでは不可能でしょう。Regex ルートを使用した場合は、 次のようにすることができます。

regex ルートは標準のルートよりはるかに柔軟性があるということが、 ここからもわかります。

Zend_Controller_Router_Route_Hostname はホスト名によるルートです。標準のルートと同じように動作しますが、 パスではなくコールされた URL のホスト名に基づいて動作します。

標準のルートの例を使用して、 ホスト名に基づいた動作がどのようなものになるのかを見ていきましょう。 パスを利用してユーザをコールするのではなく、たとえば http://martel.users.example.com でユーザ "martel" の情報を見られるようにしたいものとします。

Zend_Controller_Router_Route_Hostname のコンストラクタの最初のパラメータはルートの定義で、 これがホスト名にマッチします。 ルート定義には静的な部分と動的な部分があり、両者はドット ('.') で区切られています。動的な部分 (変数) は、変数名の先頭にコロンをつけて :username のように表します。静的な部分は、user のように単純なテキストで表します。

hostname ルートを単独で使うこともできますが、決してしてはいけません。 その理由は、hostname ルートはそれ単体だと任意のパスにマッチすることになるからです。 hostname ルートの後には path ルートをつなげなければなりません。 例に示したように、$hostnameRoute->chain($pathRoute); のようにコールすることになります。こうすると、 $hostnameRoute には何も変更は加えられませんが、新たなルート (Zend_Controller_Router_Route_Chain) が返されます。 そして、これをルータに渡します。

Zend_Controller_Router_Route_Chain は、 複数のルートを一緒にチェーンできるルートです。 これは、たとえばホスト名とルート、パスとルート、または複数のパスとルートをチェーンできます。 チェーンは、プログラム的に、または、構成ファイルの範囲内で行なえます。

注意: パラメータ優先度
ルートを一緒にチェーンするとき、 外側のルートのパラメータは内側のルートのパラメータより高い優先度を持ちます。 そういうわけで、外側のもので、そして、内側のルートでコントローラを定義するなら、 外側のルートのコントローラが選ばれます。

プログラム的にチェーンするとき、これを達成する2つの方法があります。 最初の1つは、 Zend_Controller_Router_Route_Chain インスタンスを新規作成して、 そして、一緒にチェーンでつながなければならないルートすべてで chain() メソッドを複数回呼ぶことです。 他の方法は、最初のルート（例えばホスト名のルート）を受け取って、 それに付加されなければならないルートとともに、 そのルート上で chain() メソッドを呼ぶことです。 これはホスト名ルートを修正せずとも、 Zend_Controller_Router_Route_Chain の新規インスタンスを返します。 そして、両方のルートは一緒につながれます。

ルートを一緒にチェーンするとき、それらの分離記号はデフォルトでスラッシュです。 異なる分離記号にしたい場合があるかもしれません。

Zend_Restコンポーネントは、 Zend_Controller_Router_RewriteのためにRESTfulなルートを含みます。 このルートは、HTTPメソッド及びURIをモジュール、 コントローラ及びアクションに変換することにより、 リクエストを割り振る標準化されたルーティング機構を提供します。 下表では、リクエスト・メソッドとURIを割り振る方法の概要を提示します。