nicht angemeldet
Hi wahsaga,
KISS my config.php ;->
Ihr habt natürlich Recht mit der höheren Zuverlässigkeit
von XML. Und messbar langsamer als INI ist es unter Garantie
auch nicht. Für meine Zwecke find ich es nixdesto Overkill.
Der eigentliche Grund das bestehende PHP-script als einzige
Konfigdatei zu behalten, ist daß man dort auch von Hand
'drin Rumändern kann. Und mein ganzes Anliegen dreht sich darum
eine graphische Änderungsoberfläche dafür zu bekommen, die aber
keinesfalls persönliche Kommentare oder Notizen beim
Neuschreiben verliert.
Eben das würde aber gerade mit jedem XML-Konfigparser/Rewriter
passieren. Hab mich gerade z.B. auf PEAR::Config hinweisen
lassen - das beherrscht verschiedene Formate: INI, XML und
einfache PHP $conf[] arrays - aber killt beim Zurückschreiben
alle ursprüngliche Struktur und Kommentare.
Der Einwand mit der Fehlertoleranz ist natürlich gut und berechtigt.
Aber ich denke die Gefahr hält sich -zumindest bei mir- noch in
Grenzen."Hinterher - weiss man immer mehr ..."
Kommt aber auf die Bedeutung der Applikation an, ob ich mir dieses Motto erlauben würde.
Erwischt.
Schlauerweise werd ich -nach dem Hinweis von Felix- zumindest
ein Backup der überschriebenen .php-Konfig-Datei anlegen. Sicher
ist sicher!
Die Befürchtung mit den Syntaxproblemen find ich aber trotzdem
etwas großgeredet.
Für eine ernsthaft wichtige Applikation (Kundendaten o.ä.) ist
ein garantiert-robustes System gefragt, aber bei mir gehts echt
nur um ein simples CMS-Script auf nem 08/15-nicht-redundanten-
2€/Monat-shared-hosting-Server mit hundert anderen möglichen
Fehlerquellen...
Wenn ein PHP-Syntaxfehler in einer per require eingebundenen Konfigurationsdatei vorliegt - dann ist sofort Ende, der Parser steigt dir aus, und Tschüss.
Bisher hatte ich tatsächlich include("config.php") verwendet,
und wannimmer ich beim Hand-Editieren einen Fehler reingetippt
hatte, brach das Script mit "Fatal error: function so_und_so()
undefined." ab.
Die Idee mit Fehlerbehandlung == Abbruch gefällt mir aber
zusehends besser. Also werd ich in Zukunft einfach require()
nehmen. (Nicht daß es nicht aufs selbe hinauskäme ;-)
Nette Grüße,
mario