Wie am besten Konfigurationsparameter Übergeben?

[Sven Rautenberg]

Moin!

Wie ich gestern bereits gepostet habe, hat das Responseobjekt Vollzugriff auf die gesamte Konfiguration. Das ist wichtig, damit Attribute auch persistent geändert werden können (Content Management).

Lieber nicht! Geht in einem 300-Zeilen-Miniskript vielleicht noch einigermaßen, aber der Response hat absolut nichts mit Konfiguration oder Persistierung zu tun.

PHP: PSR-7: HTTP Message Interfaces

Damit eng zusammenhängend das Konzept der Middleware, siehe z.B. M.W. O'Phinney: On HTTP, Middleware, and PSR-7

Zitat:

The basic concept of middleware can be summed up in a single method signature:
function (request, response) { }

Wenn aber das Responseobjekt als Parameter in die Transformationsfunktion zusammen mit dem Request hineingeht, muss es eine Schicht außerhalb geben, die sowohl diese beiden Objekte instanziiert, als auch diese Funktion hostet und aufruft.

Nun kommt wieder OOP ins Spiel und so haben wir: Sämtliche Konfigurationsdaten stecken in einer Instanz der Klasse Config (soweit bist Du ja auch schon). Ergo müssen wir über die Config-Instanz nur die Methode write() aufrufen und wohin die dann die Daten schreibt ist in der Methode slebst definiert.

Konfiguration wird in meiner Welt vom Admin einmalig festgelegt und gilt dann für die Lebensdauer der Applikation, bzw. bis es einen Änderungsbedarf gibt. Da die Konfiguration auf eine Serverfarm ausgerollt werden können sollte, wäre es unpraktisch, wenn man sie lokal auf einem Server geändert wegschreiben würde.

Sprich: Das Ändern der Konfiguration ist zwar grundsätzlich ein Usecase, aber dieser ist zum einen viel seltener, und erfordert zum anderen keine schreibfähige Konfigurationsleseklasse, sondern eine schreibfähige Konfigurationsverteilungsklasse.

Config lesen $config = include('config.php');
Config schreiben file_put_contents('<?php return '.var_export($config, true)', 'config.php');
ist kein Akt, aber man sollte sich über die verwendeten Datenstrukturen im Klaren sein und dies in irgendeiner Weise auch verifizieren. Deshalb sollten diese Zeilen keine fertige Konfiguration ergeben, sondern intern von der Konfigurationsklasse genutzt werden.

Aber wie gesagt: Konfiguration lesen ist der Standard-Usecase, und ich würde einer schreibbaren Konfigurationsklasse sehr kritisch gegenüber stehen. Damit erzeugt man sich im Zweifel nur Zustandsprobleme.

Moment mal, es gibt noch mehr zu schrieben, 3. Kommt hinzu, die Sessiondaten. Kein Problem wir machen das wie bei 1. u. 2. nur nennen wir die Methoten um damit wir die nicht verwechslen:

2. write_config()
3. write_session()

Session-Daten schreiben hat NICHTS mit dem Response zu tun. Das ist Applikationslogik und gehört in die Persistenzschicht.

Und wenn wir das so gemacht heben, sehen wir, wie kluch das alles ist, weil wir nur noch in den Destructor der Responseklasse greifen müssen um solche einfachen Sachen zu regeln.

Das Ende des Responses bedeutet nicht zwingend das Ende der Codeausführung, und insbesondere nicht das Ende der Konfiguration. Man denke nur an asynchron aufgerufene Hintergrundtätigkeiten: Mailen, Garbage Collection, DB-Zeugs, Bildbearbeitung etc. - sowas tut man natürlich lieber in eine Queue und arbeitet unabhängig vom Webserver, aber auch dieser Code braucht ja Konfiguration, mithin ist diese im Responseobjekt eher falsch, weil es gar keinen Response gibt in diesen Fällen.

Grüße Sven