Маршрутизация запросов в бекенде подчиняется жестким правилам. Эти правила могут быть переопределены только в рамках отдельных приложений.
Адресное пространство бекенда
Бекенд всех приложений находится в адресном пространстве вида http://[domain + path]/[backend_url]/*.
Здесь [domain + path] — это основной URL установки фреймворка, а [backend_url] — это путь к бекенду (стандартный путь webasyst или нестандартный, определенный в конфигурационном файле).
Примеры URL бекенда
Стандартные
http://mydomain.ru/webasyst/
http://mydomain.ru/framework/webasyst/Нестандартные
http://mydomain.ru/admin/
http://mydomain.ru/framework/admin/
Бекенд каждого приложения находится в более узком пространстве:
http://[domain + path]/[backend_url]/[app_id]/*, где app_id — это идентификатор приложения.
Примеры URL бекенда приложения
Стандартные
http://mydomain.ru/webasyst/blog/
http://mydomain.ru/framework/webasyst/blog/Нестандартные
http://mydomain.ru/admin/blog/
http://mydomain.ru/framework/admin/blog/
Все HTTP-запросы, URL которых начинаются на URL бекенда приложения, обрабатываются PHP-классами (контроллерами) этого приложения. Соответствие между URL конкретного запроса и классом и его методом, который должен обработать запрос, определяется в специальном классе — фронт-контроллере. Если в приложении не определен свой
собственный фронт-контроллер, используется системный класс фреймворка waFrontController.
Логика работы системного фронт-контроллера
Чтобы указать, какой PHP-класс должен обработать конкретный HTTP-запрос к бекенду приложения, в URL запроса должны быть GET-параметры module (модуль) и action (контроллер/экшен). В зависимости от значений этих параметров системный фронт-контроллер waFrontController запускает PHP-класс, имя которого сформировано из значений этих параметров в следующем формате (с использованием «горбатого» стиля): [app_id][Module][Action]. Пример: blogBackendDefault.
Оба параметра — module и action — необязательные. Когда не указан module, по умолчанию считается, что его значение равно backend. А если не указан action, то по умолчанию считается, что его значение — default, и фронт-контроллер ищет подходящую пару «класс + метод» в следущем порядке — пока не попадется подходящая:
[app_id][Module]Controller->execute()[app_id][Module]Action->execute()[app_id][Module]Actions->defaultAction()
Если же непустой параметр action есть в URL запроса, то порядок поиска немного уточняется с учетом указанного ID экшена:
[app_id][Module][Action]Controller->execute()[app_id][Module][Action]Action->execute()[app_id][Module]Actions->[action]Action()
Примеры соответствия URL классам контроллеров и их методам
/webasyst/myapp/ (module=backend&action=default)
myappBackendController->execute()myappBackendAction->execute()myappBackendActions->defautAction()/webasyst/myapp/?module=mail (action=default)
myappMailController->execute()myappMailAction->execute()myappMailActions->defautAction()/webasyst/myapp/?module=mail&action=test
myappMailTestController->execute()myappMailTestAction->execute()myappMailActions->testAction()
Переопределение правил маршрутизации в бекенде
Если в бекенде вашего приложения нужны другие правила поиска классов и методов для обработки HTTP-запросов, нужно переопределить фронт-контроллер для вашего приложения. Для этого создайте свой класс фронт-контроллера с именем вида [app_id][Class_name] и поместите его в директории lib/classes/ в файл с именем вида [app_id][Class_name].class.php.
Пример
Имя класса:
myappFrontController
Путь к файлу:lib/classes/myappFrontController.class.php
Класс должен наследовать системный waFrontController. Логику маршрутизации реализуйте в методе dispatch().
Пример
<?php class myappFrontController extends waFrontController { public function dispatch() { //... } }
Затем добавьте в конфигурационный файл wa-apps/[app_id]/lib/config/factories.php строку вида
'front_controller' => 'имя класса фронт-контроллера'
Если такого файла у вас нет, создайте его.
Пример
<?php return [ 'front_controller' => 'myappFrontController', ];









