Applications multiples

Parfois, un projet peut être divisé en plusieurs sous-projets, par exemple, une boutique en ligne peut être divisée en trois sous-projets : le projet principal de la boutique, l'interface API de la boutique et le backend d'administration de la boutique, qui utilisent tous la même configuration de base de données.

Webman vous permet de planifier le répertoire des applications ainsi :

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

Lorsque vous accédez à l'adresse http://127.0.0.1:8787/shop/{contrôleur}/{méthode}, vous accédez aux contrôleurs et méthodes dans app/shop/controller.

Lorsque vous accédez à l'adresse http://127.0.0.1:8787/api/{contrôleur}/{méthode}, vous accédez aux contrôleurs et méthodes dans app/api/controller.

Lorsque vous accédez à l'adresse http://127.0.0.1:8787/admin/{contrôleur}/{méthode}, vous accédez aux contrôleurs et méthodes dans app/admin/controller.

Dans Webman, vous pouvez même planifier le répertoire des applications ainsi :

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

Ainsi, lorsque l'adresse http://127.0.0.1:8787/{contrôleur}/{méthode} est accédée, cela accède aux contrôleurs et méthodes dans app/controller. Lorsque le chemin commence par api ou admin, cela accède aux contrôleurs et méthodes dans les répertoires correspondants.

Lors de l'utilisation de plusieurs applications, l'espace de noms des classes doit respecter psr4, par exemple, le fichier app/api/controller/FooController.php peut ressembler à ceci :

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

Configuration des middleware pour plusieurs applications

Parfois, vous souhaitez configurer des middleware différents pour différentes applications, par exemple, l'application api peut nécessiter un middleware de contrôle d'accès, l'admin peut nécessiter un middleware pour vérifier la connexion de l'administrateur. Ainsi, la configuration du fichier config/midlleware.php peut ressembler à ceci :

return [
    // Middleware global
    '' => [
        support\middleware\AuthCheck::class,
    ],
    // Middleware de l'application api
    'api' => [
         support\middleware\AccessControl::class,
     ],
    // Middleware de l'application admin
    'admin' => [
         support\middleware\AdminAuthCheck::class,
         support\middleware\SomeOtherClass::class,
    ],
];

Les middleware ci-dessus peuvent ne pas exister, ceci est seulement un exemple pour illustrer comment configurer des middleware par application.

L'ordre d'exécution des middleware est middleware global -> middleware d'application.

Pour le développement de middleware, consultez le chapitre middleware.

Configuration de gestion des exceptions pour plusieurs applications

De la même manière, vous souhaitez configurer des classes de gestion des exceptions différentes pour différentes applications, par exemple, dans l'application shop, vous pouvez vouloir fournir une page d'information conviviale en cas d'exception ; dans l'application api, lorsque l'exception se produit, vous ne souhaitez pas renvoyer une page, mais plutôt une chaîne json. La configuration des classes de gestion des exceptions pour différentes applications dans le fichier config/exception.php peut ressembler à ceci :

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

Contrairement aux middleware, chaque application ne peut configurer qu'une seule classe de gestion des exceptions.

Les classes de gestion des exceptions ci-dessus peuvent ne pas exister, ceci est seulement un exemple pour illustrer comment configurer la gestion des exceptions par application.

Pour le développement de la gestion des exceptions, consultez le chapitre gestion des exceptions.