Алгоритм работы движка рассмотрим на примере фронтэнда. В конце каждого пункта, кроме первого, приведен класс::метод(), в котором выполняется обозначенная работа.
- Входной скрипт подключает файл инициализации init.php (описание базового класса IPS, куда входят константы, обработчики ошибок, автозагрузчик классов и т.д.) и запускает диспетчера фронтэнда - \IPS\Dispatcher\Front::i()->run().
- Фронт-диспетчер проверяет, создан ли файл конфигурации. Если это не подтверждается, идет редирект на установку. \IPS\Dispatcher::i().
- Далее проверяется, есть ли кэш страницы, и если есть — он идет на вывод. \IPS\Dispatcher\Front::init().
- Если нет или истек, работа продолжается. В dev-режиме выполняется синхронизация данных разработки. \IPS\Dispatcher\Front::init().
- Идет подключение базовых css и js-файлов к выводу. \IPS\Dispatcher\Front::init().
- Далее идет обработка ЧПУ и присвоение свойств синглетону \IPS\Request. \IPS\Dispatcher\Front::init().
- Принудительное использование https. \IPS\Dispatcher\Standart::init().
- Установка локали пользователя. \IPS\Dispatcher\Standart::init().
- Загрузка из БД данных о текущем приложении и создание объекта приложения на их основе.Если в \IPS\Request не указано приложение (параметр app) или его не получить из БД, загружаются все приложения и выделяется выбранное в админке по-умолчанию. Если и такого нет, то первое в коллекции. Список всех приложений из БД хранится в кэше. \IPS\Dispatcher\Standart::init().
- Дальше идет инициализация выбранного приложения (подготовительные операции). \IPS\Dispatcher\Standart::init().
- Выбирается модуль приложения для работы, если он указан в запросе. Логика аналогична выбору приложения. \IPS\Dispatcher\Standart::init().
- Определяется контроллер модуля на основании запроса либо тот, что назначен модулю по-умолчанию. \IPS\Dispatcher\Standart::init().
- На основании данных о приложении, области (фронтэнд или бэкэнд), идентификатора модуля и имени контроллера формируется полное имя класса контроллера для автозагрузчика. Поскольку в данном случае у нас фронт-диспетчер, его свойство controllerLocation = 'front' , т. е. область у нас фронтэнда. Напротив, входной скрипт админки запускает бэкэнд-диспетчера и область у него 'admin'. \IPS\Dispatcher\Standart::init().
- Загружаются в память шаблоны, подключаются к выводу css и js-файлы активного приложения. \IPS\Dispatcher\Standart::init().
- Включается сайдбар, который может быть выключен контроллерами, проверяется пользователь на бан и на достаточность информации о нем (если он только зарегистрировался). Проверяются права доступа к текущему модулю. \IPS\Dispatcher\Front::init().
- Дальше идут всякие штуки для вывода: формирование базовой навигации (крошки), параметров поиска (предусмотрена ли в данном приложении функция глобального поиска). \IPS\Dispatcher\Front::init().
- Теперь уже в память загружается экземпляр класса, определенного в п.13. Это контроллер активного модуля и он должен быть потомком \IPS\Dispatcher\Controller. Далее он выполняется методом execute(). \IPS\Dispatcher::i()->run().
- После того как контроллер выполнил свою работу, диспетчер запускает уже свой метод finish(). \IPS\Dispatcher::i()->run().
- В нем подключаются к выводу виджеты сайдбара. Формируются метатеги. \IPS\Dispatcher\Front::i()->finish()
- Подключаются к выводу js-модели фреймворка javascript. \IPS\Dispatcher\Standart::finish().
- На заключительном этапе метода finish() выводится результат посредством \IPS\Output::i()->sendOutput(... Образ для вывода формирует система тем и шаблонов. \IPS\Theme::i()->getTemplate(... В зависимости от того идет ajax-запрос или нет, на вывод пойдет пустой шаблон (blankTemplate) с ajax-данными или общий шаблон (globalTemplate) соответственно. \IPS\Dispatcher::finish().
- По окончании деструктор фронт-диспетчера запускает исполнение очереди задач обслуживания. \IPS\Dispatcher\Standart::__desctruct().
Во многих местах идет проверка запроса на ajax - if ( !\IPS\Request::i()->isAjax() ).... От этого зависит логика вывода шаблонов, css и js.