Диспетчеризация — это процесс принятия объекта запроса (Zend_Controller_Request_Abstract), извлечения содержащихся в нем имени модуля, имени контроллера, имени действия и необязательных параметров, затем инстанцирования контроллера и вызова действия в нем. Если не найдены модуль, контроллер или действие, то будут использоваться значения по умолчанию. Zend_Controller_Dispatcher_Standard определяет index как значение по умолчанию для контроллера и действия, и default - для модуля, но позволяет разработчику изменять эти значения, используя setDefaultController(), setDefaultAction() и setDefaultModule(), соответственно. При создании приложения, состоящего из модулей, вы можете захотеть, чтобы для вашего модуля, используемого по умолчанию, тоже использовалось свое пространство имен (по умолчанию для этого модуля оно не используется). Начиная с версии 1.5.0, вы можете устанавливать параметр prefixDefaultModule в true, используя фронт-контроллер или диспетчер. setParam('prefixDefaultModule', true); // Через диспетчер: $dispatcher->setParam('prefixDefaultModule', true); ]]> Это позволяет повторно использовать существующий модуль в качестве используемого по умолчанию в вашем приложении. Диспетчеризация производится циклически во фронт-контроллере. До того, как будет запущен процесс диспетчеризации, фронт-контроллер выполняет маршрутизацию запроса для нахождения пользовательских значений модуля, контроллера, действия и необязательных параметров. Затем он входит в цикл диспетчеризации, обрабатывая запрос. В начале каждой итерации цикла он устанавливает флаг в объекте запроса, означающий, что действие было запущено. Если действие или методы pre/postDispatch установленного плагина сбросят этот флаг, то цикл диспетчеризации продолжится и будет произведена попытка обработать новый запрос. Изменяя контроллер и/или действие в запросе и сбрасывая флаг диспетчеризации, разработчик может задавать цепочку запросов для обработки. Метод действия в контроллере, который таким образом управляет диспетчеризацией, называется _forward(); вызывайте этот метод из любых методов pre/postDispatch() или методов действий, указывая действие, контроллер, модуль и опционально любые дополнительные параметры, которые хотите передать новому действию. _forward('bar', null, null, array('baz' => 'bogus')); } public function barAction() { // переход к действию в другом контроллере FooController::bazAction() // в текущем модуле: $this->_forward('baz', 'foo', null, array('baz' => 'bogus')); } public function bazAction() { // переход к действию в другом контроллере в другом модуле // Foo_BarController::bazAction(): $this->_forward('baz', 'bar', 'foo', array('baz' => 'bogus')); } ]]> Zend_Controller_Front сначала вызывает маршрутизатор для получения первого действия в запросе. Затем он входит в цикл диспетчеризации, в котором вызывается диспетчер для запуска действия. Диспетчеру для своей работы требуются различные данные - ему нужно "знать", как формировать имена контроллеров и действий, где искать файлы классов контроллеров, является ли допустимым или нет предоставленное имя модуля, и API для определения на основе другой доступной информации того, возможна ли диспетчеризация данного запроса. Zend_Controller_Dispatcher_Interface определяет следующие методы, которые требуется использовать во всех реализациях диспетчера: Однако в большинстве случаев вам достаточно будет только расширить абстрактный класс Zend_Controller_Dispatcher_Abstract, в котором уже определены все эти методы или класс Zend_Controller_Dispatcher_Standard для изменения функционала стандартного диспетчера. Основаниями для создания подклассов диспетчера могут быть желание использовать иную схему именования в своих контроллерах действий, либо другую парадигму диспетчеризации - например, файлы действий в директориях контроллеров вместо методов действий в классах контроллеров.