Konfigurationsdateien
Seb
- php
Hi,
habe folgendes Problem.
Schreibe an einer Application, in der ich meine Konfigurationen über Dateien und Datenbank in einer Klasse verwalten möchte, dh. ich übergebe einen bestimmten Wert, die Klasse klappert Konfigurationsdateien und Datenbank ab und liefert mir dann meinen gesuchten Wert.
Nun ist das mit der Datenbank ja kein Problem, aber mit den Konfigurationsdateien, wo ja unter anderem die Datenbank Daten drinne sind, da habe ich noch keine Idee, wie ich das lösen kann.
Über das Directory kann ich ja alle Dateien einlesen, aber ich will ja nicht einfach alle Includieren.
Kennt ihr nen guten Ansatz für das Problem?
Gruß Seb
Hi,
für meinen Kram hab ich alles in einer ini-Datei
[sektion]
parameter = value
[mysql]
user = fuzzi
pass = geheim
host = lokalhorst
port = 3399
[path]
html = /home/html
cgi = /home/cgi
usw.
Ist es das, was Du suchest?
Horst
Hello,
für meinen Kram hab ich alles in einer ini-Datei
[sektion]
parameter = value[mysql]
user = fuzzi
pass = geheim
host = lokalhorst
port = 3399[path]
html = /home/html
cgi = /home/cgi
und die liest Du mit http://www.php.net/manual/en/function.parse-ini-file.php ein?
Liebe Grüße aus dem Cyberspace
Tom vom Berg
Das Problem ist nur, dass ich dort auch meine Datenbank Login Daten speichern will und ini wird doch ausgegeben, oder?
Das Problem ist nur, dass ich dort auch meine Datenbank Login Daten speichern will und ini wird doch ausgegeben, oder?
verschlüsselt ablegen?
und / oder per htacces-datei die Ausgabe von *.ini unterbinden?
»» Das Problem ist nur, dass ich dort auch meine Datenbank Login Daten speichern will und ini wird doch ausgegeben, oder?
verschlüsselt ablegen?
Ne, das ist ja quatsch. Sorry! Die Daten sollen ja von Menschenhand dort abgelegt werden.
Dann bleibt evtl. noch:
und / oder per htacces-datei die Ausgabe von *.ini unterbinden?
Gruß,
Jannes
Dann bleibt evtl. noch:
»» und / oder per htacces-datei die Ausgabe von *.ini unterbinden?
Das Problem ist nur, sollte ich das ganze, wie geplant, mal veröffentlichen, dann ist es ein Muss, dass der Nutzer sich etwas mit Apache auskennt, was ich eigentlich umgehen möchte.
Hi,
»» Dann bleibt evtl. noch:
»»
»» »» und / oder per htacces-datei die Ausgabe von *.ini unterbinden?Das Problem ist nur, sollte ich das ganze, wie geplant, mal veröffentlichen, dann ist es ein Muss, dass der Nutzer sich etwas mit Apache auskennt, was ich eigentlich umgehen möchte.
verstehe. Aber sehr wahrscheinlich wird dein Programm ja in einem eigenen Verzeichnis und evtl. Unterverzeichnissen gespeichert, so könntest Du eine .htaccess Datei mitliefern, die dann auch nicht modifiziert werden muß.
(
<Files *.ini>
deny from all
</Files>
)
Gruß,
Jannes
Ahoi,
Die Config-Klasse vom Zend Framework arbeite mit zwei Varianten, ini und xml.
Dank und Gruß,
Schreibe an einer Application, in der ich meine Konfigurationen über Dateien und Datenbank in einer Klasse verwalten möchte, dh. ich übergebe einen bestimmten Wert, die Klasse klappert Konfigurationsdateien und Datenbank ab und liefert mir dann meinen gesuchten Wert.
Nun ist das mit der Datenbank ja kein Problem, aber mit den Konfigurationsdateien, wo ja unter anderem die Datenbank Daten drinne sind, da habe ich noch keine Idee, wie ich das lösen kann.
Über das Directory kann ich ja alle Dateien einlesen, aber ich will ja nicht einfach alle Includieren.
Kennt ihr nen guten Ansatz für das Problem?
Ich habe da im Januar einen Thread gehabt zum Thema gute Configfiles.
Da es sich beider Anwendung um ein CMS handelt, kam ich aber davon gänzlich ab. Jetzt gibt es nur noch ein Configfile, das vor der Installation mit einem halben Dutzend Angaben versorgt werden muss.
Für alles andere gibt es Formulare und eine GUI.
Ach. Ich arbeite mit Perl und wurde im dortigen Thread daran erinnert, dass das Modul Storable hier der direkteste Weg ist. Hierbei werden die CMS-Betriebsdaten als komplexer Perl-Hash gespeichert. Das hat mir enorm viele Nachdenken abgenommen zum Thema Tabellen, Datenstrukturen etc... Ich muss nur noch den Hash, den ich im Verlauf des Programms definiert habe, auch am Fuss des Programms dokumentieren.
Ja und natürlich Backup/Rollback Mechanismen dieser Datenstruktur wurden auch implementiert.
Dies mal als ganz anderer Ansatz zu den üblichen SQL/Konfigfile Szenarien.
mfg Beat