Ich schlage vor, die Komponente symfony/http-foundation bei uns mit reinzunehmen.
Das ist die Symfony-Komponente mit den Basisklassen Request und Response etc.
Zum Start würde ich die Request-Klasse nutzen wollen, also man käme dann per rex::getRequest() oder ähnlich an das aktuelle Request-Objekt.
Gleichzeitig könnte man auch an verschiedenen Stellen bei uns intern schauen, ob man eigene Implementierungen ersetzen kann durch die aus dem Paket.
Es gäbe in R5 also teilweise einen Parallelbetrieb, man kann sowohl weiterhin unsere Methoden nutzen um Request-Dinge abzufragen, zukünftig könnte man aber auch direkt mit dem Symfony-Request-Objekt hantieren.
Langfristig wäre natürlich das Ziel, grundsätzlich mehr darauf aufzubauen.
Bei der Response-Klasse ist ein Parallelbetrieb wahrscheinlich schwieriger, aber könnte man schauen. Beginnen würde ich wie gesagt eher mit Request.
Wie komme ich drauf, bzw. was ist die Motivation?
Vor allem yrewrite würde davon profitieren. Aktuell vertraut yrewrite blind auf die Forwarded-Header bei Proxies etc., was nicht gut ist.
Da wollen wir zukünftig auf die TrustedProxy-Logik aus symfony/http-foundation setzen. Ein paar Links dazu habe ich hier notiert: https://github.com/yakamara/redaxo_yrewrite/issues/218#issuecomment-692135387
Zunächst war mein Plan, die betreffenden Methoden per copy-paste in yrewrite reinzuholen. Das hat sich aber als doch zu unpraktikabel herausgestellt, da hängt zu viel dran uns es werden noch weitere Helper-Klassen aus dem Paket verwendet etc.
Wir könnten jetzt nur in yrewite das ganze Paket reinnehmen. Aber da kam ich eben auf die Idee, ob es nicht sinnvoller ist, es dann gleich in den Core zu nehmen, auch wenn der Core nicht direkt den ganz großen Nutzen davon hätte, sondern eher auf längere Sicht.
Wir könnten jetzt nur in yrewite das ganze Paket reinnehmen. Aber da kam ich eben auf die Idee, ob es nicht sinnvoller ist, es dann gleich in den Core zu nehmen, auch wenn der Core nicht direkt den ganz großen Nutzen davon hätte, sondern eher auf längere Sicht.
hmm irgendwie hab ich im hinterkopf dass http-foundation auch PSR standards implementiert.. ich hab mal reingeschaut aber nix gefunden... ggf. hab ich mir geirrt.
update.. ahh was ich meinte war sowas hier: https://symfony.com/doc/current/components/psr7.html
kurzum, wenn man psr kompatibel ist, bekommt man kompatibilität zu einigen dingen was super ist.
perspektifisch kann man dann z.B. auch psr7-middlewares verwenden
wenn es vom code her nicht zu hässlich wird, bin ich definitiv dafür.
uuuund: weniger code von uns den wir pflegen müssen bedeutet mehr zeit für redaxo spezifische dinge.
Weitere idee: wenn die basis mit sf/http-foundation gelegt ist kann man redaxo auch mit bref in serverless context einsetzen bzw. Z.b. symfony/forms o.ä. Verwenden
Somit wären wir dort wo ich schonmal hin wollte: https://github.com/redaxo/redaxo/issues/2133
das ist absolut sinnvoll, vor allem weil ein haufen addons das eh über composer einbinden. Zumindest bei meinen AddOns :) .. seeehr dafür
Most helpful comment
hmm irgendwie hab ich im hinterkopf dass http-foundation auch PSR standards implementiert.. ich hab mal reingeschaut aber nix gefunden... ggf. hab ich mir geirrt.
update.. ahh was ich meinte war sowas hier: https://symfony.com/doc/current/components/psr7.html
kurzum, wenn man psr kompatibel ist, bekommt man kompatibilität zu einigen dingen was super ist.
perspektifisch kann man dann z.B. auch psr7-middlewares verwenden
wenn es vom code her nicht zu hässlich wird, bin ich definitiv dafür.
uuuund: weniger code von uns den wir pflegen müssen bedeutet mehr zeit für redaxo spezifische dinge.