Objekt-orientiertes Request-Processing auf Basis von PSR-7

Hallo,

nachdem wir die technische Basis unserer WoltLab Suite in den letzten Versionen stückweise modernisiert haben, indem beispielsweise eigene Lösungen durch bekannte Bibliotheken (Guzzle in 5.3) ersetzt, das Session-System auf den aktuellen Stand der Technik gebracht (5.4), JavaScript durch TypeScript ersetzt (5.4) und auch das Event-System an die Konzepte gängiger Frameworks und andere Programmiersprachen angeglichen wurde (5.5) möchten wir mit WoltLab Suite 5.5 einen weiteren Schritt der Modernisierung angehen.

Beginnend mit WoltLab Suite 5.5 möchten wir Unterstützung für die objekt-orientierte Verarbeitung von Anfragen auf Basis von PSR-7 integrieren. Diese Integration soll stückweise im Rahmen der kommenden WoltLab Suite-Versionen erfolgen und nach und nach erweitert werden. Bekannt ist das ganze Konzept aus Symfony und Laravel, dort in Form von Symfonys HttpFoundation. Die HttpFoundation hat gegenüber PSR-7 einige Unterschiede im Detail, die generelle Funktionsweise ist aber die gleiche.

In WoltLab Suite 5.5 beginnen wir damit, dass die Suite Unterstützung dafür bekommt, dass die HTTP-Antwort optional in Form eines Objekts, das das ResponseInterface-Interface implementiert, zurückgegeben werden kann.

Alle Details finden sich in den WoltLab/WCF PRs #4437 (als Meta-PR, der andere PRs sammelt) und #4436 als PoC der Implementierung:

Meta: PSR-7 by TimWolla · Pull Request #4437 · WoltLab/WCF

WoltLab Suite 5.5 will ship with basic support for object-oriented response generation and processing based off the PSR-7 standard. It is planned that this…

github.com

Add initial support for sending PSR-7 responses by TimWolla · Pull Request #4436 · WoltLab/WCF

see #4437

github.com

Die weitere Evolution in den Versionen nach WoltLab Suite 5.5 hängt davon ab, wie gut sich dieser erste Schritt in der Praxis bewährt und wie gut das ganze in Plugins angenommen wird.

Wir freuen uns auf euer Feedback, präferiert zentral als Antworten und Review am Pull Request auf GitHub, und beantworten gerne eure Fragen bezüglich des Vorgehens.

Hallo,

Quote from Hanashi

habt ihr schon ein Beispiel in der WoltLab Suite 5.5?

#4436 mal angeklickt?

Hallo,

Quote from Hanashi

Edit: ich habe mir den Code jetzt mal genauer angeschaut und finde es an sich ziemlich nice. Ich werde es sicherlich mal testen wenn die 5.5 da ist. Allerdings sehe ich jetzt für mich persönlich weder Vor- noch Nachteile wenn ich es nutze/nicht nutze.

Quote from MysteryCode

Es mag vielleicht an etwas Schlafmangel liegen, aber ich sehe null Vorteil, der sich daraus ergibt. Eher eine Abhängigkeit von einer externen Library und einem Event vor der Ausgabe (show) weniger.

SoftCreatR hat es prinzipiell schon erklärt, aber ich frage hier noch einmal ganz explizit: Habt ihr beide berücksichtigt, dass die Integration schrittweise in den kommenden Versionen erfolgen soll?

Die Unterstützung in WoltLab Suite 5.5 fokussiert sich erst einmal auf die grundsätzliche Unterstützung, indem die notwendigen Bibliotheken mitgeliefert werden und die Erzeugung von Antworten auf Basis von PSR-7 möglich ist. Pakete können (und sollen!) dann die Antworten für AbstractActions als PSR-7 ResponseInterface zurückgeben. Das allein sorgt erst einmal nicht für eine funktionale Änderung und erlaubt es durch die Freiwilligkeit noch nicht darauf aufzubauen. Irgendwo muss man aber anfangen und die Unterstützung für Responses ist minimalinvasiv (wie man sicherlich auch an der Größe vom #4437 sehen kann).

#4437 erklärt das ganze (im technischen Kontext der WoltLab Suite) weiter im Detail. Die grundsätzlichen Vorteile eines Middleware-Frameworks muss ich an dieser Stelle hoffentlich nicht weiter erklären.

Wie die Verwendung der Request-Klassen (außerhalb des Frameworks) aussehen kann, kann auch in #4440 gesehen werden. Dort auf Basis der PSR-7-Klassen von Guzzle und mit etwas mehr Handarbeit.

Quote from Throwholics

[…]

Ich würde darum bitten, dass dieses Thema für Fragen von Entwicklern genutzt wird und werden kann, ohne, dass die Diskussion in Richtungen abschweift, die damit nichts zu tun haben.

Hallo,

Quote from Cyperghost

Jetzt mal eine ganz andere Sache. Ist es und wird es möglich sein, mit einem Plugin über ein Event die Rückgabe zu ändern, sprich ein ResponseInterface zurück zu geben?

In WoltLab Suite 5.5 ist das Etappenziel, dass die AbstractAction-Klassen auf PSR-7-Antworten umgebaut werden und auf diese Weise so viel exit wie möglich verschwindet. Die Antwort ist da typischerweise entweder ein Redirect + exit oder JSON + exit. Das ganze wird ersetzt durch ein return + ResponseInterface. Für die Actions hast du auch aktuell schon keine sinnvolle Möglichkeit die Rückgabe zu ändern (auch bedingt durch das exit).

Bei AbstractPage und AbstractForm existiert auch eine Unterstützung für PSR-7-Antworten, die ist in WoltLab Suite 5.5 aber als experimentell zu betrachten, weil dort die Gefahr durch Inkompatibilitäten mit den bestehenden Events und Event-Listenern größer ist.

Weil man sich in WoltLab Suite 5.5 noch nicht darauf verlassen kann, dass Pakete überhaupt eine Unterstützung für PSR-7-Antworten haben, gibt es hier auch noch keine Funktionalität, die auf den PSR-7-Antworten aufbaut (dazu gehört auch die Modifikation durch Events). Um das zuverlässig zu ermöglichen, ist es wichtig, dass Plugins hier mitziehen und versuchen die entsprechenden Etappenziele ebenfalls umzusetzen.

Das weitere Vorgehen hängt dann davon ab, wie gut das jeweilige Etappenziel erreicht wurde und ob die aktuelle Situation etwas ist, auf dem man zuverlässig weiter aufbauen kann.

Quote from Cyperghost

Bei dem neuen Event System stellt sich bei mir echt die Frage 🤔 hab ich damit überhaupt die gleichen Möglichkeiten wie mit dem „alten“? Weil ich habe ja nicht mehr das Klassen Objekt wo durch sehr sehr viele information verloren gehen.

Siehe:

Post

RE: Verwendung von veraltetem Code

Hallo,
[…]

ich hätte in meiner ersten Antwort vermutlich noch ein wenig mehr ausführen sollen, weil sich in der Praxis eigentlich gar nichts ändert (bzw. die Flexibilität sogar steigt).

1. Die Klassen sind ein sauberer Ersatz für das $parameters-Array, weil du komplette IDE-Unterstützung hast. Auch bei den $parameters bekommst du nur das, was der Entwickler dir bereitstellt.
2. Die „alten“ Events waren nie als Freifahrtschein dafür gedacht an beliebigen Properties vom „feuernden“ Objekt

…

Tim Düsterhus

Jun 30th 2021

Hallo,

auf GitHub gibt es jetzt einen weiteren PR, der weitere Actions auf PSR-7 umbaut:

Use PSR-7 responses in additional actions by TimWolla · Pull Request #4447 · WoltLab/WCF

Blocked on #4436

github.com

Ganz besonders interessant ist da vielleicht die neue Methode im HeaderUtil. Diese demonstriert wie man bei PSR-7-Responses die Header modifizieren kann: https://github.com/WoltLab/WCF…17cecf5e501d76013ce91a116

Zum Einsatz kommt sie in diesem Commit: https://github.com/WoltLab/WCF…829f782358d5f7bf6f154183e

Hallo,

und als ein weiteres Beispiel noch ein PR, der in allen Antworten den private-Wert zum cache-control-Antwort-Header hinzufügt:

Add `cache-control: private` to PSR-7 responses by TimWolla · Pull Request #4454 · WoltLab/WCF

While we cannot rely on every controller returning a PSR-7 response, we are also unable to reliably set cache-control: private without these PSR-7 responses.…

github.com

Dieser demonstriert konzeptionell, wie mit den PSR-7-Antworten die Rückgabe an zentraler Stelle modifiziert werden kann. In einer geplanten zukünftigen Versionen – mit Unterstützung für Anfragen auf Basis von PSR-7 könnte die Logik dann in eine richtige Middleware verschoben werden. Das könnte dann etwa so aussehen:

<?php

namespace Psr\Http\Server;

use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;

final class PrivateCacheControlEnforcer implements MiddlewareInterface
{
    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    {
        $response = $handler->handle($request);

        // Cache-Control-Logik hier.
        $cacheControl = ['private'];

        return $response->withHeader(
            'cache-control',
            \implode(', ', $cacheControl)
        );
    }
}