Multiple Applications

Manchmal kann ein Projekt in mehrere Teilprojekte unterteilt werden, zum Beispiel kann ein Online-Shop in das Hauptprojekt, die API-Schnittstelle und das Verwaltungs-Backend des Online-Shops unterteilt werden. Alle verwenden die gleiche Datenbankkonfiguration.

Webman erlaubt Ihnen, das App-Verzeichnis wie folgt zu planen:

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

Wenn Sie die Adresse http://127.0.0.1:8787/shop/{Controller}/{Methode} aufrufen, wird der Controller und die Methode im Verzeichnis app/shop/controller aufgerufen.

Wenn Sie die Adresse http://127.0.0.1:8787/api/{Controller}/{Methode} aufrufen, wird der Controller und die Methode im Verzeichnis app/api/controller aufgerufen.

Wenn Sie die Adresse http://127.0.0.1:8787/admin/{Controller}/{Methode} aufrufen, wird der Controller und die Methode im Verzeichnis app/admin/controller aufgerufen.

In Webman können Sie sogar das App-Verzeichnis so planen.

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

Wenn die Adresse http://127.0.0.1:8787/{Controller}/{Methode} aufgerufen wird, wird der Controller und die Methode im Verzeichnis app/controller aufgerufen. Wenn der Pfad mit api oder admin beginnt, wird der entsprechende Controller und die Methode im entsprechenden Verzeichnis aufgerufen.

Bei mehreren Anwendungen muss der Namespace der Klassen psr4 entsprechen, zum Beispiel, die Datei app/api/controller/FooController.php sieht ähnlich aus wie folgt:

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

Middleware-Konfiguration für mehrere Anwendungen

Manchmal möchten Sie unterschiedliche Middleware für verschiedene Anwendungen konfigurieren. Beispielsweise benötigt die api-Anwendung möglicherweise eine CORS-Middleware, während admin eine Middleware zur Überprüfung des Administrator-Logins benötigt. Daher könnte die Konfiguration in config/middleware.php wie folgt aussehen:

return [
    // Globale Middleware
    '' => [
        support\middleware\AuthCheck::class,
    ],
    // Middleware für die api-Anwendung
    'api' => [
         support\middleware\AccessControl::class,
     ],
    // Middleware für die admin-Anwendung
    'admin' => [
         support\middleware\AdminAuthCheck::class,
         support\middleware\SomeOtherClass::class,
    ],
];

Die oben genannten Middleware-Klassen könnten nicht existieren, sie dienen hier nur als Beispiel, um zu zeigen, wie Middleware nach Anwendung konfiguriert werden kann.

Die Ausführungsreihenfolge der Middleware ist globale Middleware -> Anwendungs-Middleware.

Weitere Hinweise zur Middleware-Entwicklung finden Sie im Middleware-Kapitel.

Fehlerbehandlungs-Konfiguration für mehrere Anwendungen

Ebenso möchten Sie für verschiedene Anwendungen unterschiedliche Fehlerbehandlungs-Klassen konfigurieren. Beispielsweise möchten Sie möglicherweise für die shop-Anwendung eine benutzerfreundliche Fehlerseite bereitstellen, während Sie für die api-Anwendung bei einem Fehler nicht eine Seite zurückgeben, sondern einen JSON-String zurückgeben möchten. Die Konfigurationsdatei für unterschiedliche Fehlerbehandlungs-Klassen könnte in config/exception.php wie folgt aussehen:

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

Im Gegensatz zur Middleware kann jede Anwendung nur eine Fehlerbehandlungs-Klasse konfigurieren.

Die oben genannten Fehlerbehandlungs-Klassen könnten nicht existieren, sie dienen hier nur als Beispiel, um zu zeigen, wie Fehlerbehandlung nach Anwendung konfiguriert wird.

Weitere Hinweise zur Entwicklung der Fehlerbehandlung finden Sie im Fehlerbehandlungs-Kapitel.