[dev] Конфигурация сайта на Alto CMS - некоторые нюансы и особенности

Это очередная статься для разработчиков, которые хотели бы досконально разобраться во всех нюансах работы Alto CMS. И сегодня речь – о том, как устроен и работает конфигуратор. Статья рассчитана на читателей, которые уже имеют представление о том, как конфигурируется движок, но хотели бы заглянуть «под капот». Поэтому я не буду рассказывать здесь про структуру конфиг-файлов вообще или про то, что делают вызовы Config::Get() и Config::Set(), предполагая, что читатель и так это знает, а перейду сразу к сути статьи.

С чего начинается конфиг

Загрузка всего приложения начинается с «предзагрузчика», который обычно находится по адресу /engine/loader.php (при желании его можно и в другое место положить, но для этого придется уже корневой файл index.php править).

В той же папке с предзагрузчиком лежит самый первый подключаемый конфигурационный файл config.php, в котором определяются самые важные пути для загрузки компонентов движка:

$config['path']['dir']['engine'] = __DIR__;           // Путь к папке движка
$config['path']['dir']['libs']   = ALTO_DIR . '/engine/libs/';   // Путь к библиотекам движка 
$config['path']['dir']['common'] = ALTO_DIR . '/common/';        // Путь к общим компонентам 
$config['path']['dir']['config'] = ALTO_DIR . '/common/config/'; // Путь к папке конфигурации 
$config['path']['dir']['app']    = ALTO_DIR . '/app/';           // Путь к папке приложения 

Здесь хочу акцентировать внимание на том, как именуются конфиг-параметры: настоятельно рекомендуется во всех дисковых путях использовать подключ 'dir', а во всех веб-путях использовать подключ 'url'. Например:

$config['path']['static']['url'] = '___path.root.url___'; // Полный URL до static-сервера
$config['path']['static']['dir'] = '___path.root.dir___'; // Полный путь до static-сервера в файловой системе

При таком подходе, встретив в коде вызов Config::Get('path.static.dir'), сразу ясно, о каком пути идет речь.

После того, как предзагрузчик получил представление о том, что откуда загружать, вызывается уже основной загрузчик (класс Loader), который и выполняет львиную долю работ по конфигурированию всего приложения.

Описывать сейчас весь процесс загрузки конфиг-файлов (что из каких именно файлов и в каком порядке грузится в конфиг) я не буду. Ибо детальное описание этого процесса – это приличный объем текста, который, пожалуй, стоит позже отдельной статьей дать. Сейчас я опишу некоторые существенные нюансы этого процесса.

Шесть уровней конфига

Во-первых, предусмотрено аж шесть уровней конфигурации. Эти уровни накладываются один на другой, как в слоеном пироге. Вот они, от низшего к высшему:

1. Основной (базовый) уровень (LEVEL_MAIN) – это то, что задано в папках /common/config и /common/config/modules/, т.е. это основной конфигуратор движка.
   
2. Уровень приложения (LEVEL_APP) – это конфигурации, заданные в файлах, лежащих в /app/config и /app/config/modules/. Именно здесь (и только здесь) нужно менять параметры конфигурации своего сайта, если это делается вручную.
   
3. Пользовательский уровень (LEVEL_CUSTOM) – конфигурации, заданные через админку, тут, думаю, все ясно.
   
4. Уровень контроллера (LEVEL_ACTION) – да, в Альто можно задавать конфигурации аж для каждого экшена. Они последовательно берутся из файлов /common/config/actions/имя_экшена.php и /app/config/actions/имя_экшена.php. Например, для экшена admin задается свой собственный скин.
   
5. Уровень скина (LEVEL_SKIN) – конфигурации используемого скина
6. Пользовательский уровень скина (LEVEL_SKIN_CUSTOM) – этот уровень пока не используется, но можно догадаться, для чего его можно будет задействовать в будущем.

По умолчанию все операции Config::Get() и Config::Set() производятся с текущим уровнем. Но, при желании, всегда можно получить (и установить) конфиг-параметры для конкретного уровня.

Дополнительные секции

Чем более навороченным становится движок и веб-приложение, тем навороченнее становятся и конфиг-файлы. С одной стороны, это придает гибкости. С другой – чем больше настроек лежит в одном файле, тем труднее с ним работать. Поэтому возникает желание вынести некоторые настройки в отдельные конфиг файлы и подключать их в процессе работы.

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

В основном конфиг-файле есть такой параметр:

$config['config_load'] = array(
    'assets',       // Наборы подключаемых css- и js-файлов
    'classes',      // Определения классов
    'jevix',        // Настройки типографа текста Jevix
    'widgets',      // Виджеты
);

При конфигурировании приложения загрузчик получает параметр Config::Get('config_load') и перебирает значения из полученного массива. Если есть файл assets.php, то он загружается в секцию конфига assets. И в дальнейшем мы можем получить набор конфигурации вызовом Config::Get('assets'). То же самое касается и остальных значений – classes, jevix и т.д.

Причем, такие включения дополнительных конфиг-файлов выполняются как на основном уровне конфига, так и на уровне приложения.