Multi-App

A volte un progetto può essere suddiviso in più sottoprogetti, ad esempio un negozio online può essere diviso in tre sottoprogetti: il progetto principale del negozio, l'interfaccia API del negozio e il backend di gestione del negozio, tutti utilizzando la stessa configurazione del database.

Webman ti consente di pianificare la directory dell'app in questo modo:

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

Quando visiti l'indirizzo http://127.0.0.1:8787/shop/{controller}/{method}, accedi al controller e al metodo sotto app/shop/controller.

Quando visiti l'indirizzo http://127.0.0.1:8787/api/{controller}/{method}, accedi al controller e al metodo sotto app/api/controller.

Quando visiti l'indirizzo http://127.0.0.1:8787/admin/{controller}/{method}, accedi al controller e al metodo sotto app/admin/controller.

In Webman, è possibile anche pianificare la directory dell'app in questo modo.

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

In questo modo, quando visiti l'indirizzo http://127.0.0.1:8787/{controller}/{method}, accedi al controller e al metodo sotto app/controller. Quando il percorso inizia con api o admin, accedi rispettivamente al controller e al metodo della directory corrispondente.

Quando si utilizzano più applicazioni, il namespace delle classi deve essere conforme a psr4, ad esempio il file app/api/controller/FooController.php è simile al seguente:

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

Configurazione Middleware per Multi-App

A volte desideri configurare middleware diversi per applicazioni diverse, ad esempio l'applicazione api potrebbe avere bisogno di un middleware per il cross-origin, mentre admin ha bisogno di un middleware per controllare il login dell'amministratore. La configurazione di config/middleware.php potrebbe apparire simile a quanto segue:

return [
    // Middleware globale
    '' => [
        support\middleware\AuthCheck::class,
    ],
    // Middleware per l'app api
    'api' => [
         support\middleware\AccessControl::class,
     ],
    // Middleware per l'app admin
    'admin' => [
         support\middleware\AdminAuthCheck::class,
         support\middleware\SomeOtherClass::class,
    ],
];

I middleware sopra potrebbero non esistere, qui sono solo un esempio per illustrare come configurare i middleware per applicazione

L'ordine di esecuzione dei middleware è Middleware globale -> Middleware dell'applicazione.

Per lo sviluppo di middleware, fai riferimento alla sezione middleware

Configurazione Gestione Errori per Multi-App

Allo stesso modo, potresti voler configurare classi di gestione degli errori diverse per diverse applicazioni, ad esempio, se si verifica un errore nell'app shop, potresti voler fornire una pagina di avviso amichevole; se si verifica un errore nell'app api, potresti voler restituire non una pagina, ma una stringa JSON. La configurazione per diverse classi di gestione degli errori in config/exception.php è simile a quanto segue:

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

A differenza dei middleware, ogni applicazione può configurare solo una classe di gestione degli errori.

Le classi di gestione degli errori sopra potrebbero non esistere, qui sono solo un esempio per illustrare come configurare la gestione degli errori per applicazione

Per lo sviluppo della gestione degli errori, fai riferimento alla sezione gestione degli errori