Eine Frage des Designs

[breaker]

Moin :)

Mich quält gerade eine Frage, wo ich mich einfach nicht entscheiden kann:

Ich bin gerade dabei ein Script zu bauen, welches rund 100 Variablen für die Konfiguration bereit hält...wie soll ich diese Speichern? In eine Datei ist klar, weil ich für sowas keine DB brauche, bzw es total unsinnig wäre.

Die 1. Möglichkeit, woran ich gedacht habe, wäre ein Array...dann müsste ich die benötigen Variablen aber in den Funktionen bekannt geben (über eine Request-Class)

Oder soll ich sie als Konstanten speichern? Dann brauche ich die nicht in den Funktionen bekannt geben und kann sie sofort einsetzen, was den Programmier-Aufwand natürlich kleiner hält

Wie soll ich es also nun machen?

[Gremlin]

Wenn du doch

$config['foo'] = 'bar';
$config['foo2'] = 'bar';
usw machst dann müsste doch ein

global $config in den FUnktionen reichen

[breaker]

Wenn du doch

$config['foo'] = 'bar';
$config['foo2'] = 'bar';
usw machst dann müsste doch ein

global $config in den FUnktionen reichen

Genau davon will ich ja weg ;)

[jpwfour]

Dann benutzt doch $GLOBALS.

Define() kann man benutzen, wird nur problematisch, wenn die Konfigurationswerte später im Script nochmal verändert werden sollen, weil es ja dann Konstanten sind.

In jedem normalen Script wird ja meist eine
Default-Konfig
vorgegeben, welche der User dann überschreiben kann, um volle Update Kompatibilität und Konsitenz zu gewährleisten.

$GLOBALS find ich persönlich unschön, und da man Konfig Werte an sich nicht in jeder Funktion braucht/brauchen sollte, kann das explizite importieren via global nicht schaden.

[breaker]

Dann benutzt doch $GLOBALS.

Define() kann man benutzen, wird nur problematisch, wenn die Konfigurationswerte später im Script nochmal verändert werden sollen, weil es ja dann Konstanten sind.

In jedem normalen Script wird ja meist eine
Default-Konfig
vorgegeben, welche der User dann überschreiben kann, um volle Update Kompatibilität und Konsitenz zu gewährleisten.

$GLOBALS find ich persönlich unschön, und da man Konfig Werte an sich nicht in jeder Funktion braucht/brauchen sollte, kann das explizite importieren via global nicht schaden.


Die Werte der Konstanten kann ich auch per Laufzeit ändern, das ist nicht das Problem.

Ich will so wenig wie möglich auf den Globalen Scope zurück greifen (also das Manuelle) und von den PHP4-Sünden wie "global" usw. und diverese Request-Vars weg kommen.

Ich glaube ich werde mir dafür eine Klasse bauen, wo ich Strings, Integer und Arrays holen und absetzen kann:

wRequest::getVar
wRequest::setVar
wRequest::getInt
wRequest::setInt

usw..dann habe ich das Problem wohl gelöst und brauche mich danach auch nicht mehr daraum zu kümmern, ob eine Var jetzt per _GET angefordert werden muss oder per _POST verfügbar ist...._REQUEST sollte man ja nicht blind einsetzen, was das natürlich leichter machen sollte ;)

[jpwfour]

"Scoping" ist doch eher eine Neuerung, dacht ich jedenfalls, besonders da Dinge wie private,protected,public, usw. doch eher ein OOP Merkmal sind.

Das beste ist tatsächlich, Konfigurationsvariablen in eine extra Klasse zu packen, dort kann man diese ja bei edarf auch als const deklarieren.

Bzw. Zugriffe/Änderungen besser steuern, und der ganz große Vorteil ist, dass die meisten PHP Optimierungspozesse mit extra Klassen und const Vars ganz gut klarkommen, define() ist da nicht so optimal.

Spielt natürlich nur Performancemäßig eine Rolle, wenn Optimizer überhaupt eingesetzt werden.

Die Methode mit der Klasse erlaubt auch eine logische Aufteilung, bspw. in Layout/Design, User, Extern usw.

Sprich man muss beim Aufruf eines Crons nur die Extern Konfig Klasse laden, bei Seiten, die nur reinen Text ausgeben, kann man die Layout Klasse weglassen etc. und im Script ist sofort ersichtlich, wozu eine Variable gehört.

EDIT: was mir noch einfällt, am sinnvollsten und logischten wärs an sich ja, eine .ini Datei parsen zu lassen, nur ist das Performancehalber eher suboptimal (außer man cached das Ganze dann)

[breaker]

was mir noch einfällt, am sinnvollsten und logischten wärs an sich ja, eine .ini Datei parsen zu lassen, nur ist das Performancehalber eher suboptimal (außer man cached das Ganze dann)



Darüber habe ich mir auch schon gedanken gemacht...aber diese ini-Files sind ja gewöhnliche Text-Dateien...die kann man im Browser aufrufen und die Inhalte sehen, ist also nichts, um sensible Daten (Interface-Login von den Netzwerken o.ä.) abzulegen. Das einzige, womit man den Zugriff sperren kann, sind CHmod...aber wer setzt die schon?