nicht angemeldet
Hey jobo,
bei den vielen Beiträgen ist mir Deine Antwort irgendwie "durch die Lappen gegangen".
- Wenn man tatsächlich ein "Framework" programmiert, dann muss man die möglichen Anforderungen aller möglichen User abdecken und benötigt dafür ein entsprechend breit gefächertes Angebot an Features. Das Zend Framework erlaubt das Lesen von INI, XML, YAML und JSON-Konfigurationsdateien - das sollte alles mögliche abdecken.
Genau deshalb dachte ich bei den Versuchen, mich da einzuarbeiten immer wieder: wieso gibts kein ZF-light. Das kann dann eben nur INI zB. und das wars. Diese ganzen Konfigurationsmöglichkeiten machen es für einen Anfänger halt recht komplex. Mir ist so, als wenn ich das Argument auch schon mal hie und da viell. sogar aus den eigenen Reihen in Bezug auf ZF 2.0 gelesen hätte. Klar aber auch, dass man bei einem solchen Framework natürlich gerade schaut, möglichst viele Anwendungsfälle bzw. Konfigurationen zu ermöglichen.
Ich finde das Anbieten mehrerer Formate schon sinnig und gar nicht so komplex. Vor allem (wie Du ja schon erwähnt hast), weil man ja auch (in vielen Fällen) nur einzelne Komponenten verwenden kann.
Was mich vielmehr stört ist, dass so viele "Komfort-Methoden" verwendet werden. Damit meine ich, dass eine Methode als Parameter beispielsweise einen String, ein Array oder ein Objekt akzeptiert. Das finde ich unübersichtlich. Besser wäre meiner Meinung nach hier nur eine Möglichkeit anzubieten und das (nach Möglichkeit) konsequent.
Und einige der Wrapper-Methoden für andere Klassen-Methoden gehören für mich auch weg.
Das Konfigurationsproblem lässt sich also entweder aufwendig, komplex und fehleranfällig mit viel "universellem" Code lösen, oder sehr banal, einfach und performant mit sehr konkretem Code: Man kann einfach eine Liste von Konstantendefinitionen in PHP-Code tun und zu Beginn ausführen. Man kann auch eine "Konfigurationsklasse" mit einem statischen internen Array für die Werte befüllen und mit statischen Methoden auslesen. INI-oder gar XML-Dateien veredeln Konfigurationsparameter nicht.
Je nachdem, wer auf die Konfigurationen zugreifen können sollte, wäre eine Liste innerhalb einer Klasse vielleicht nicht so sinnig? Was ich mal probiert hatte war ein globales Array als PHP-Code a la:
config/config.php
$GLOBALS["config"]["allowedCategories"] = array("abc","abd","abf");
$GLOBALS["config"]["titles"]["kuerzel"] = "ein richtiger Titel";
$GLOBALS["config"]["titles"]["kuerzel2"] = "ein richtiger zweiter Titel";
Die Globals finde ich persönlich unübersichtlich. Da finde ich es schon besser, das in eine Klasse auszulagern. Die kann ja auch von überall aus erreichbar (also "quasi-Globals") sein. Aber ich habe zumindest eine Trennung von Anwendungs- und Allgemein-Konfigurationen.
Gruß, Dennis