Маршрутизация запросов в бекенде подчиняется жестким правилам. Эти правила могут быть переопределены только в рамках отдельных приложений.
Адресное пространство бекенда
Бекенд всех приложений находится в адресном пространстве вида 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', ];