Роутинг в бекенде

Содержание...

Маршрутизация запросов в бекенде подчиняется жестким правилам. Эти правила могут быть переопределены только в рамках отдельных приложений.

Адресное пространство бекенда

Бекенд всех приложений находится в адресном пространстве вида 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, и фронт-контроллер ищет подходящую пару «класс + метод» в следущем порядке — пока не попадется подходящая:

Если же непустой параметр action есть в URL запроса, то порядок поиска немного уточняется с учетом указанного ID экшена:

Примеры соответствия URL классам контроллеров и их методам

/webasyst/myapp/ (module=backend&action=default)

  1. myappBackendController->execute()
  2. myappBackendActions->defautAction()
  3. myappBackendAction->execute()

/webasyst/myapp/?module=mail (action=default)

  1. myappMailController->execute()
  2. myappMailActions->defautAction()
  3. myappMailAction->execute()

/webasyst/myapp/?module=mail&action=test

  1. myappMailTestController->execute()
  2. myappMailActions->testAction()
  3. myappMailTestAction->execute()

Переопределение правил маршрутизации в бекенде

Если в бекенде вашего приложения нужны другие правила поиска классов и методов для обработки 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 array(
        'front_controller' => 'myappFrontController',
    );