Большинство компонентов Zend Framework, используемых на вашем сайте, требуют конфигурации (тонкой настройки). Например, в файле конфигурации вы можете установить настройки подключения для базы данных, определить, какие модули присутствуют в вашем приложении и добавить некоторые пользовательские параметры.
Вы можете определить параметры конфигурации на двух уровнях: либо на уровне приложения, либо на уровне модуля. На уровне приложения обычно определяются параметры, которые контролируют всю программу и являются общими для всех модулей приложения. На уровне модуля определяются параметры, которые затрагивают только этот модуль.
Некоторые PHP-фреймворки предпочитают принцип соглашения превыше конфигурации (Сonvention over Сonfiguration), при котором большинство параметров жестко закодированы и не требуют конфигурации. Это ускоряет разработку приложения, но делает его менее настраиваемым. В Zend Framework 3 используется принцип конфигурация превыше соглашений, то есть, вы можете настроить каждый аспект вашего приложения, но вам придется потратить немного времени прежде, чем вы научитесь это делать.
Подкаталог APP_DIR/config содержит файлы конфигурации, действующие для всего приложения. Рассмотрим этот подкаталог более детально (рисунок 3.4).
Файл APP_DIR/config/application.config.php - это основной файл конфигурации. Он используется приложением при запуске для определения, какие модули приложения должны быть загружены и какие сервисы созданы по умолчанию.
Ниже представлено содержимое файла application.config.file. Как видите, файл конфигурации является обычным вложенным ассоциативным массивом, и каждый компонент этого массива может иметь особый ключ. Вы можете оставить комментарии к этим ключам, чтобы другим было проще понять, что означает каждый из них.
Принято давать ключам имена в нижнем регистре, и, если имя ключа состоит из нескольких слов, их следует разделять нижним подчеркиванием ('_').
return [
// Извлекаем список модулей, используемых в этом приложении.
'modules' => require __DIR__ . '/modules.config.php',
// Существует несколько вариантов для обработчиков, прикрепленных к ModuleManager
'module_listener_options' => [
// Это должен быть массив путей, в которых находятся модули.
// Если есть строка с ключом, обработчик посчитает ее пространством имен модуля,
// значение этого ключа - путем к классу
// Module этого модуля.
'module_paths' => [
'./module',
'./vendor',
],
// Массив путей, для которых используется функция glob (поиск пути к файлам) после
// загрузки модуля. Таким образом, настройки, предоставляемые модулем, переопределяются.
// Пути могут иметь флаг GLOB_BRACE.
'config_glob_paths' => [
realpath(__DIR__) . '/autoload/{{,*.}global,{,*.}local}.php',
],
// Включать или нет кэш конфигурации.
// Если он включен, файлы конфигурации после слияния будут кэшированы
// и использованы при последующих запросах.
'config_cache_enabled' => true,
// Ключ, используемый для создания имени файла кэша конфигурации.
'config_cache_key' => 'application.config.cache',
// Включать или нет кэш карты классов модуля.
// Если он включен, создается кэш карты классов модуля, который будет использоваться
// при последующих запросах для сокращения времени автозагрузки.
'module_map_cache_enabled' => true,
// Ключ, используемый для создания имени файла кэша карты классов.
'module_map_cache_key' => 'application.module.cache',
// Путь, в который кэшируется конфигурация после слияния.
'cache_dir' => 'data/cache/',
// Включать или нет проверку зависимостей модулей (включена по умолчанию).
// Это предотвращает использование модулей, который зависит от других, не
// загруженных модулей.
// 'check_dependencies' => true,
],
// Используется для создания собственного менеджера сервисов. Может содержать один или несколько дочерних массивов.
//'service_listener_options' => [
// [
// 'service_manager' => $stringServiceManagerName,
// 'config_key' => $stringConfigKey,
// 'interface' => $stringOptionalInterface,
// 'method' => $stringRequiredMethodName,
// ],
// ],
// Начальная конфигурация, которая подается ServiceManager'у.
// Должна быть совместима с Zend\ServiceManager\Config.
// 'service_manager' => [],
];
В строке 3 у нас есть ключ modules, определяющий, какие модули будут загружены при запуске. Как вы видите,
имена модулей хранятся внутри другого файла конфигурации modules.config.php
, который содержит список
всех модулей вашего сайта.
В строке 11 находится ключ module_paths
, который сообщает ZF3 о
каталогах, в которых нужно искать файлы источников, принадлежащие модулям. Модули приложения,
разрабатываемые вами, находятся в каталоге APP_DIR/module, а сторонние модули -
в каталоге APP_DIR/vendor.
Наконец, строка 19 содержит ключ config_glob_paths
, который сообщает ZF3, где искать
дополнительные файлы конфигурации. Как видите, файлы из каталога APP_DIR/config/autoload
с суффиксами global.php или local.php загружаются автоматически.
Итак, как правило, вы используете главный файл настроек application.config.php для хранения информации
о том, какие модули должны быть загружены, а также их местоположение и способ загрузки (здесь, например, вы
можете управлять настройками кэширования). В этом файле вы помимо этого можете настроить менеджер сервисов.
Не рекомендуется добавлять дополнительные ключи в этот файл. Для этой цели лучше использовать файл autoload/global.php
.
Давайте также заглянем внутрь файла modules.config.php
. На данный момент у вас
установлены следующие модули:
return [
'Zend\Session',
'Zend\Mvc\Plugin\Prg',
'Zend\Mvc\Plugin\Identity',
'Zend\Mvc\Plugin\FlashMessenger',
'Zend\Mvc\Plugin\FilePrg',
'Zend\Form',
'Zend\Router',
'Zend\Validator',
'Application',
];
Модуль Application
- это модуль, содержащий файлы вашего приложения. Все остальные перечисленные модули - это
компоненты Zend Framework 3.
В ZF3 был представлен специальный плагин Composer'a, называемый установщиком компонентов. Если помните, в главе Zend Skeleton Application, мы отвечали на несколько вопросов об установщике, определяя, какие компоненты устанавливать. И установщик вставил имена этих модулей здесь, в файле
modules.config.php
"Дополнительные" файлы конфигурации, APP_DIR/config/autoload/global.php и APP_DIR/config/autoload/local.php определяют соответственно не зависимые и зависимые от окружения настройки, применимые для всего приложения. Эти файлы конфигурации загружаются автоматически и рекурсивно сливаются с файлами конфигурации, предоставляемыми модулями, поэтому их каталог называется autoload.
Имея несколько файлов конфигурации в каталоге APP_DIR/config/autoload, вы, возможно, запутаетесь с тем, какие параметры в какой файл поместить. Вот несколько советов:
Используйте файл autoload/global.php для хранения параметров, которые не зависят от окружения конкретной машины: например, тех, что переопределяют параметры по умолчанию некоторого модуля. Не храните здесь чувствительную информацию (такую как учетные данные базы данных), для этой цели лучше использовать autoload/local.php.
Используйте файл autoload/local.php для хранения параметров, специфичных для
конкретного окружения: например, учетные данные базы данных.
У каждого разработчика обычно есть локальная база данных для разработки и тестирования веб-сайта.
Таким образом, разработчик будет изменять файл учетные данные базы данных и вводить туда учетные данные
своей БД. При установке сайта на "боевой" сервер (production server) файл local.php
вновь изменяется,
и в него записываются учетные данные "реальной" базы.
Так как файл autoload/local.php содержит зависимые от окружения параметры, в системе контроля версий вы храните его "шаблон распределения" local.php.dist. Каждый разработчик вашей команды затем переименовывает файл local.php.dist в local.php и вводит свои собственные параметры. Файл local.php не следует хранить под системой контроля версий, потому что он может хранить чувствительную информацию вроде учетных данных БД (логины и пароли), и вы, скорее всего, не захотите, чтобы их увидели другие.
С файлом конфигурации разработки (APP_DIR/config/development.config.php
) вы столкнетесь при включении
режима разработки. Если помните, мы включали этот режим ранее в главе Zend Skeleton Application.
Режим разработки включается следующей командой:
php composer.phar development-enable
Файл development.config.php
сливается с главным файлом application.config.php
. Это позволяет вам
переопределить некоторые параметры. Например, вы можете:
Если вы выключите режим разработки, файл development.config.php
будет удален. Поэтому хранить этот
файл под системой контроля версий не стоит. Вместо этого храните таким образом его вариант распределения, development.config.php.dist
.
Дополнительный файл конфигурации приложения в режиме разработки (APP_DIR/config/autoload/development.local.php
) присутствует только тогда,
когда вы включаете режим разработки.
Файл development.local.php
сливается с другими файлами конфигурации уровня модуля. Это позволяет вам
переопределить некоторые параметры конфигурации в режиме разработки.
Если вы выключите режим разработки, файл development.local.php
будет удален. Поэтому хранить этот
файл под системой контроля версий не стоит. Вместо этого храните таким образом его вариант распределения, development.local.php.dist
.
Как видно из рисунка 3.4, у модуля Application есть файл module.config.php, в котором
хранятся параметры, специфичные для этого модуля. Взглянем на
файл module.config.php
модуля Application
:
<?php
namespace Application;
use Zend\Router\Http\Literal;
use Zend\Router\Http\Segment;
use Zend\ServiceManager\Factory\InvokableFactory;
return [
'router' => [
'routes' => [
'home' => [
'type' => Literal::class,
'options' => [
'route' => '/',
'defaults' => [
'controller' => Controller\IndexController::class,
'action' => 'index',
],
],
],
'application' => [
'type' => Segment::class,
'options' => [
'route' => '/application[/:action]',
'defaults' => [
'controller' => Controller\IndexController::class,
'action' => 'index',
],
],
],
],
],
'controllers' => [
'factories' => [
Controller\IndexController::class => InvokableFactory::class,
],
],
'view_manager' => [
'display_not_found_reason' => true,
'display_exceptions' => true,
'doctype' => 'HTML5',
'not_found_template' => 'error/404',
'exception_template' => 'error/index',
'template_map' => [
'layout/layout' => __DIR__ . '/../view/layout/layout.phtml',
'application/index/index' => __DIR__ . '/../view/application/index/index.phtml',
'error/404' => __DIR__ . '/../view/error/404.phtml',
'error/index' => __DIR__ . '/../view/error/index.phtml',
],
'template_path_stack' => [
__DIR__ . '/../view',
],
],
];
В этом файле вы регистрируете контроллеры модуля, помещаете в него информацию о правилах маршрутизации для определения соответствия между URL и вашими контроллерами, регистрируете плагины контроллеров, а также регистрируете шаблоны представления и помощники представления (мы узнаем больше об этих терминах в этой и следующих главах).
При создании приложения, файлы конфигурации, предоставляемые модулем, и дополнительные файлы конфигурации из каталога APP_DIR/config/autoload соединяются в один большой вложенный массив, так что каждый параметр конфигурации становится доступным для каждой детали вашего сайта. Таким образом, у вас есть возможность переопределить любые параметры, заданные модулями.
Возможно, вы видели "объединенный" файл конфигурации при установке PHP, где есть главный файл php.ini и несколько дополнительных файлов конфигурации, включенных в него. Такое разделение делает настройку вашего приложения многогранной и гибкой, потому что вам не нужно помещать все ваши параметры в один файл и изменять его каждый раз, когда необходимо внести какие-то изменения.
Файлы конфигурации загружаются в следующем порядке:
Главный файл application.config.php загружается первым. Он используется для инициализации менеджера сервисов и загрузки модулей приложения. Данные, загруженные из этого файла, хранятся отдельно и не сливаются с другими файлами конфигурации.
Затем загружаются и объединяются файлы конфигурации для каждого модуля приложения. Модули загружаются в том же порядке, в котором они перечислены в файле application.config.php. Если два модуля хранят параметры в ключах с одинаковыми названиями (либо намеренно, либо по ошибке), эти параметры могут быть перезаписаны.
Затем загружаются и объединяются в один массив дополнительный файлы конфигурации из каталога APP_DIR/config/autoload. Этот массив затем сливается с массивом конфигурации модуля, созданным на предыдущем этапе. Конфигурация на уровне приложения имеет более высокий приоритет, чем конфигурация модуля, поэтому здесь вы при желании можете переопределить ключи модулей.