Источник: Quick Start to Zend_Application_Bootstrap
Автор: Matthew Weier O'Phinney

Мы добавили Zend_Application в Zend Framework начиная с версии 1.8.0. Намерением, лежащим в основе компонента, была формализация процесса загрузки приложений, а также обеспечение упрощенного, основанного на файле конфигураций, механизма для него.
Zend_Application работает в связке с Zend_Application_Bootstrap, который, как можно догадаться из названия, является тем, что на самом деле выполняет большую часть работы по загрузке вашего приложения. Это позволяет вам использовать подключаемые ресурсы загрузчика, либо определить локальные ресурсы загрузчика как методы класса. Разработчик получает возможность повторного использования, а в последующем специфическую для приложения инициализацию и конфигурацию.

Кроме того, Zend_Application_Bootstrap обеспечивает отслеживание зависимостей (например, если один из ресурсов зависит от другого, вы можете гарантировать выполнение другого ресурса первым), а также выступает в качестве хранилища для инициализированных ресурсов. Это означает, что если ресурс прошел начальную загрузку, вы можете извлечь его позднее из самого загрузчика.
Как это работает

Теперь, когда вы знаете, что он делает, давайте окунемся в основы.

Если вы используете утилиту командной строки zf, предоставляемую Zend Framework для создания своих проектов («zf create project»), вы получите загрузчик и настройки по умолчанию прямо «из коробки». Это включает в себя следующие файлы в файловой структуре:


Файл Bootstrap.php будет содержать класс Bootstrap, который расширяет Zend_Application_Bootstrap_Bootstrap; этот класс изначально будет пустой. Файл application.ini будет содержать следующее:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
appnamespace = "Application"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.frontController.params.displayExceptions = 0

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.frontController.params.displayExceptions = 1

Zend_Application проходит в три этапа. Во-первых, оно инициализирует среду PHP, используя INI параметры вашей конфигурации, если они заданы, а также настройку include_path и автозагрузку. Во-вторых, оно инициализирует и выполняет класс начальной загрузки. Наконец, «выполняется» приложение (вызовом метода run () загрузчика).
Параметры конфигурации

Мы видим, что приведенный выше листинг представляет собой набор:

* Параметры инициализации PHP (в данном случае они свидетельствуют о том, следует ли отображать ошибки)
* Настройки include_path
* Настройки, которые указывают название и место нахождения класса начальной загрузки
* Настройки ресурсов приложения

Ключ phpSettings принимает любые ключи из php.ini как подразделы, и эти пары ключ/значение будут переданы ini_set. Это может быть полезно, когда вам нужно быть уверенным в том, что установлены особые INI параметры, особенно если вы хотите, чтобы они зависели от окружения. (В приведенном выше примере, display_errors включен в тестовом окружении и в окружении для разработки, но отключен в остальных)

Когда дело доходит до include_path и автозагрузки, вероятно, наиболее часто задаваемый вопрос: «Как я могу добавить в автозагрузчик префиксы пространств имен для кода, отличного от ZF?». Это можно легко сделать в конфигурационном файле, воспользовавшись ключом autoloaderNamespaces и префиксом пространства имен в качестве его значения:

autoloaderNamespaces[] = "Phly_"

Что касается класса загрузчика и местоположения файла, как правило, вариант по умолчанию будет наилучшим. Однако, если вы хотите задать пользовательское наименование — например, чтобы указать префикс класса — или, возможно, если ваш модуль по умолчанию находится в подкаталоге, вы можете уведомить Zend_Application об этом через настройки bootstrap.class и boostrap.path:

bootstrap.class = "Application_Bootstrap"
bootstrap.path = APPLICATION_PATH "/modules/application/Bootstrap.php"

Начало работы с ресурсами загрузчика

Теперь мы, наконец, займемся самым интересным: непосредственно ресурсами загрузчика.

Да, я знаю, что я умалчиваю о ключе «appnamespace»; я расскажу об этом в другое время.

Ресурсы загрузчика могут быть одной из двух вещей:

* Защищенный метод в классе начальной загрузки с префиксом «_init» (например, protected function _initFoo())
* Класс, реализующий Zend_Application_Resource_Resource_Resource

В первом случае, _init*() методы, каждый из них будет выполняться в каждом запросе. В последнем, будут выполнены только те, которые вы укажете в вашем конфигурационном файле, что позволяет вам выбирать, какие из различных поставляемых плагинов ресурсов (или написанных вами самим!) будут использованы.

В случае с конфигурацией по умолчанию, только плагин ресурса «frontController» будет использоваться, соответствуя Zend_Application_Resource_Frontcontroller. По состоянию на предстоящий релиз 1.10, вы можете выбрать один из следующих дополнительных плагинов ресурсов, таких как:

* Cachemanager
* Db
* Dojo
* Layout
* Locale
* Log
* Mail
* Modules
* Multidb
* Navigation
* Router
* Session
* Translate
* View

Каждый из них имеет собственные параметры конфигурации, описанные в руководстве.
Написание методов ресурсов

Написание ваших собственных методов ресурсов тривиально: вы просто создаете метод, и выполняете какую-то работу. Затем вы имеете возможность вернуть значение. Если вы это сделаете, оно будет храниться в загрузчике и вы сможете получить его позже. К примеру:

class Bootstrap
          extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initRegistry()
    {
        $registry = new Zend_Registry();
        return $registry;
    }
}

Если бы мы хотели получить реестр позже, мы могли бы сделать это, используя метод загрузчика getResource ():

$registry = $bootstrap->getResource('Registry');

Обратите внимание, что мы передаем имя метода без префикса «_init», это «краткое имя» показывает как ресурс упоминается в загрузчике, и как вы будете ссылаться на него позже.

Теперь, допустим, у вас есть ресурс, который зависит от вашего ресурса «Реестр». Например, вы хотите создать объект Zend_Currency и передать его в реестр. Zend_Application_Bootstrap был спроектирован для обработки этой ситуации, и включает в себя отслеживание зависимостей (это, на самом деле, истинная причина создания методов инициализации защищенными, что предотвращает их прямой вызов). Просто вызовите метод bootstrap() с названием ресурса для его инициализации. Кроме того, метод getResource () может быть использован для получения значений, зарегистрированных этим ресурсом. К примеру:

class Bootstrap
          extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initCurrency()
    {
        $this->bootstrap('Registry');
        $registry = $this->getResource('Registry');

        $currency = new Zend_Currency('$');
        $registry['Zend_Currency'] = $currency;
        return $currency;
    }
    protected function _initRegistry()
    {
        $registry = new Zend_Registry();
        return $registry;
    }
}

Вот что произойдет:

* Zend_Application вызовет bootstrap() без аргументов, который сначала перебирает внутренние методы ресурсов, а затем любые настраиваемые плагины ресурсов.
* этот загрузчик выполнит метод _initCurrency ()
* он встречает метод bootstrap() и выполняет его
* вызов bootstrap() выполняет метод _initRegistry (), сохраняя по завершению экземпляр Zend_Registry (который был возвращен из метода)
* выполнение _initCurrency () продолжается вызовом getResource (); он возвращает экземпляр Zend_Registry, хранящемуся в загрузчике по этому ключу.
* выполнение _initCurrency () завершается, и загрузчик сохраняет возвращенный экземпляр Zend_Currency.
* метод bootstrap() затем пытается вызвать метод _initRegistry (), но при этом отмечает, что он уже был выполнен, и поэтому переходит к выполнению плагинов ресурсов.

Как вы можете теперь видеть, загрузчик функционально достаточно гибкий и мощный, и предоставляет целый ряд преимуществ сразу «из коробки».
До следующей встречи…

На данный момент, вы должны знать достаточно для того, чтобы начать писать собственные инициализационные ресурсы начальной загрузки. В ближайшие недели я собираюсь написать о том, как написать повторно используемые плагины ресурсов, а также обсудить, каким образом процесс начальной загрузки вписывается в модульные приложения.

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•