index.phpからZendContlollerFrontController（フロントコントローラー）が呼ばれています。
ZendContlollerFrontControllerはFacade（ファサード）パターンになってます。
だから意識しなくても使える。
但し、細かい設定をするにはZendContlollerFrontControllerの内部の処理を知らないとできない。
だから結局お勉強が必要。
Facadeはカプセル化とは違うので、内部オブジェクトは呼び出すことが可能です。
というより、実際の開発では内部Object（オブジェクト）を呼び出して細かい設定をします。
最初に色々instance（インスタンス）が生成されてます。
生成を遅延してあったり、最初に呼び出されたりしてるので、
分かりにくくなってます。
生成を遅延しているのは、オーバーヘッドの軽減が目的だと思われます。
Plugin（プラグイン）はZendContlollerPluginBrokerを通じて呼ばれます。
ZendContlollerPluginBrokerは基本、全てのプラグインに対して、
同一の処理をかけるためのまとめ役です。
Chain of Responsibility（チェーンオブレスポンシビリティ）パターンですね。
同様にZendControllerRouterも複数のルーティングを設定して、
逆順に実行できます。
こちらは特に管理しているオブジェクトは存在しません。
自分自身で管理しているようです。
次にRouting（ルーティング）を行います。
デフォルトでは、mod_rewriteを利用して、
Zend_Controller/Router/Rewrite.php
が呼び出され、
/module（モジュール）名/controller（コントローラー）名/Action（アクション）名/
というURLから、
module（モジュール）名、
controller（コントローラー）名、
Action（アクション）名
を取得しています。
ちなみに
$_defaultModule=default
$_defaultController=index
$_defaultAction=index
です。
defaultモジュールは省略可能なので、
/controller（コントローラー）名/Action（アクション）名/
という名前で、
/application/[controller（コントローラー）名]Controller.php
にある、
[Action（アクション）名]Actionメソッド（method）にアクセスできます。
defaultControllerも省略可能なので、
/Action（アクション）名/
というURLで、
/application/indexController.php
にある、
[Action（アクション）名]Actionメソッド（method）にアクセスできます。
で、
/
にアクセスすると、
/application/indexController.php
にある、
indexActionメソッドにアクセスできます。
仕組みを理解してないと、ボトムアップで理解しないといけないので、
ここが難しくなります。
話を戻して、ZendControllerFrontでは、Routing（ルーティング）の前後で、
PluginのrouteStartup($request)、routeShutdown($request)メソッドが
呼び出されます。
これによって、ルーティング前後でPluginによる処理を入れることが可能になります。
その後、Action内のdispatchに入るのですが、
そのうち続きを書きます。
今日はここまで。
ZendContlollerFrontControllerはFacade（ファサード）パターンになってます。
だから意識しなくても使える。
但し、細かい設定をするにはZendContlollerFrontControllerの内部の処理を知らないとできない。
だから結局お勉強が必要。
Facadeはカプセル化とは違うので、内部オブジェクトは呼び出すことが可能です。
というより、実際の開発では内部Object（オブジェクト）を呼び出して細かい設定をします。
最初に色々instance（インスタンス）が生成されてます。
生成を遅延してあったり、最初に呼び出されたりしてるので、
分かりにくくなってます。
生成を遅延しているのは、オーバーヘッドの軽減が目的だと思われます。
Plugin（プラグイン）はZendContlollerPluginBrokerを通じて呼ばれます。
ZendContlollerPluginBrokerは基本、全てのプラグインに対して、
同一の処理をかけるためのまとめ役です。
Chain of Responsibility（チェーンオブレスポンシビリティ）パターンですね。
同様にZendControllerRouterも複数のルーティングを設定して、
逆順に実行できます。
こちらは特に管理しているオブジェクトは存在しません。
自分自身で管理しているようです。
次にRouting（ルーティング）を行います。
デフォルトでは、mod_rewriteを利用して、
Zend_Controller/Router/Rewrite.php
が呼び出され、
/module（モジュール）名/controller（コントローラー）名/Action（アクション）名/
というURLから、
module（モジュール）名、
controller（コントローラー）名、
Action（アクション）名
を取得しています。
ちなみに
$_defaultModule=default
$_defaultController=index
$_defaultAction=index
です。
defaultモジュールは省略可能なので、
/controller（コントローラー）名/Action（アクション）名/
という名前で、
/application/[controller（コントローラー）名]Controller.php
にある、
[Action（アクション）名]Actionメソッド（method）にアクセスできます。
defaultControllerも省略可能なので、
/Action（アクション）名/
というURLで、
/application/indexController.php
にある、
[Action（アクション）名]Actionメソッド（method）にアクセスできます。
で、
/
にアクセスすると、
/application/indexController.php
にある、
indexActionメソッドにアクセスできます。
仕組みを理解してないと、ボトムアップで理解しないといけないので、
ここが難しくなります。
話を戻して、ZendControllerFrontでは、Routing（ルーティング）の前後で、
PluginのrouteStartup($request)、routeShutdown($request)メソッドが
呼び出されます。
これによって、ルーティング前後でPluginによる処理を入れることが可能になります。
その後、Action内のdispatchに入るのですが、
そのうち続きを書きます。
今日はここまで。