Много приложений

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

Webman позволяет вам планировать директорию приложения следующим образом:

app
├── shop
│   ├── controller
│   ├── model
│   └── view
├── api
│   ├── controller
│   └── model
└── admin
    ├── controller
    ├── model
    └── view

Когда вы обращаетесь по адресу http://127.0.0.1:8787/shop/{контроллер}/{метод}, то вызывается контроллер и метод из app/shop/controller.

Когда вы обращаетесь по адресу http://127.0.0.1:8787/api/{контроллер}/{метод}, то вызывается контроллер и метод из app/api/controller.

Когда вы обращаетесь по адресу http://127.0.0.1:8787/admin/{контроллер}/{метод}, то вызывается контроллер и метод из app/admin/controller.

В Webman вы также можете спланировать директорию приложения таким образом:

app
├── controller
├── model
├── view
│
├── api
│   ├── controller
│   └── model
└── admin
    ├── controller
    ├── model
    └── view

Таким образом, когда вы обращаетесь по адресу http://127.0.0.1:8787/{контроллер}/{метод}, вызывается контроллер и метод из app/controller. Когда путь начинается с api или admin, вызывается соответствующий контроллер и метод из этих директорий.

При использовании нескольких приложений пространство имен классов должно соответствовать psr4, например, файл app/api/controller/FooController.php может выглядеть следующим образом:

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

Конфигурация промежуточного ПО в многоприложениях

Иногда вы хотите настроить разные промежуточные слои для различных приложений, например, для api приложения может потребоваться промежуточный слой для контроля доступа, а для admin может потребоваться промежуточный слой для проверки входа администратора. Поэтому конфигурация в config/middleware.php может выглядеть следующим образом:

return [
    // Глобальный промежуточный слой
    '' => [
        support\middleware\AuthCheck::class,
    ],
    // Промежуточный слой для api приложения
    'api' => [
         support\middleware\AccessControl::class,
     ],
    // Промежуточный слой для admin приложения
    'admin' => [
         support\middleware\AdminAuthCheck::class,
         support\middleware\SomeOtherClass::class,
    ],
];

Указанные промежуточные слои могут не существовать, это всего лишь пример, показывающий, как настраивать промежуточное ПО для приложений

Последовательность выполнения промежуточного ПО: глобальный промежуточный слой -> промежуточный слой приложения.

Разработка промежуточного ПО см. в главе о промежуточном ПО

Конфигурация обработки исключений в многоприложениях

Аналогично, вы хотите настроить разные классы обработки исключений для различных приложений, например, если в приложении shop возникла ошибка, возможно, вы захотите предоставить дружелюбную страницу с сообщением; если в приложении api возникла ошибка, вы хотите вернуть не страницу, а строку json. Конфигурационный файл для разных классов обработки исключений config/exception.php может выглядеть следующим образом:

return [
    'shop' => support\exception\Handler::class,
    'api' => support\exception\ApiHandler::class,
];

В отличие от промежуточного ПО, для каждого приложения можно настроить только один класс обработки исключений.

Указанные классы обработки исключений могут не существовать, это всего лишь пример, показывающий, как настраивать обработку исключений для приложений

Разработка обработки исключений см. в главе о обработке исключений