Suche: Parser/Rewriter für Konfigurationsdatei .php-Skript

[mario]

(Disclaimer: Ja, ich hab vorher Google und Sourceforge bemüht.)

Hi,

Ich möchte eine PHP-Datei als Konfigurationsdatei für ein
Projekt behalten. Ich will die aber über eine Oberfläche
bearbeiten können.
Für INI-Dateien gibt es fertige Lösungen und Skripte die so
eine formularmäßige Bearbeitung erlauben. Auch wenn das mehr
Arbeit macht, find ich eine .PHP-config-Datei eleganter.

Auslesen und Neuschreiben sind auch nicht ernsthaft aufwendiger
als bei einer INI, weil die zu bearbeitenden Zeilen alle eine
etwas schlichtere Syntax verwenden. Mal als Beispiel:

  
<?php  
# Konfig-Datei  
  
$conf_var_1 = 1111;  
$setting2 = "zwei";  
define("SETTING3", 3);  
include("plugin1.php");  // evtl mit Kommentar  
#include("disabled.php");  
include("plugin3.php");  
  
...  
App::Run();  
?>  

Das ganze sollte aber nicht-destruktiv funktionieren, d.h.
alle Kommentare und echte Anweisungen die drumherum stehen
müssen erhalten bleiben. Die Konfigurations-Befehle selbst
sind nur $var=VALUE, define() und include() - und stehen in
einem Block, der abgesehen von Kommentar- und Leerzeilen
zusammenhängend sein sollte.

Ok, sieht vielleicht etwas aufwendiger aus. Aber zeilenweise
Analysierung mit regulären Ausdrücken ist hier recht einfach
machbar. Eine Admin/Konfigurationsoberfläche dafür sollte
einfach nur zusätzliche include()-Plugins oder neue Variablen
einfügen können, oder bestehende entfernen.

Selberschreiben ist sicher kein Problem, dauert halt nur
ein wenig - deswegen frag ich hier mal, ob irgendwer sowas
schonmal gesehen hat.
Gibt's für sowas keine Fertiglösungen in Opensource-CMS/Blogs?
(die können ja nicht alle nur so umständliche SQL- oder XML-
Konfigurationstools verwenden)

G,
mario

[Felix Riesterer]

Lieber mario,

Ich möchte eine PHP-Datei als Konfigurationsdatei für ein
Projekt behalten.

nach meiner Beobachtung speichern anscheinend immer mehr Desktop-Applikationen ihre Settings in einer Art XML-Datei. Dieses Vorgehen ist auf der einen Seite sinnvoll, da man im Klartext (ohne programmiersprachliche Unterschiede) alles lesen kann, als auch robust, da es zum Parsen von XML erprobte Parser gibt.

Schreibst Du Deine Settings aber in Form von Programm-Code, dann wäre es möglich, dass sich Syntaxfehler einschleichen, wenn einmal die Settings per Hand "nachbearbeitet" werden, die durchaus heftigerere Programmfehler provozieren, als das bei einem missglückten XML-Parsing passieren würde.

Stimmt die Syntax Deiner PHP-Datei nicht, wird Dein Script garantiert abbrechen! Stimmt die Syntax der XML-Datei nicht, wird für die fehlerhaften Einstellungen eben der dafür vorgegebene Default-Wert verwendet.

Wo siehst Du hier das kleinere Potenzial für Konflikte/Fehler/Programmversagen?

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[mario]

Hey Felix,

Wenn ein Desktopprogramm "nur" seine Einstellungen abspeichert,
spielt es eher keine Rolle wie gut die Datei lesbar ist. XML oder
Registry tun's da sicher gleichermaßen. - Ich nenn mal als Beispiel
die GNOME-Registry - das Schlechteste aus beiden Welten *hihi*

Weil mein Script jedoch auf dem Webserver läuft, kommts auch
ein wenig auf Geschwindigkeit an. Das Script wird ja recht häufig
aufgerufen und muß jedesmal beim Start die Einstellungen lesen.
Von daher sind SQL-Tabelle und XML-Parser meiner Meinung nach
schon zu viel des Guten. PHP-Skript oder INI-Datei oder ein
serialize()-Blob nehmen sich IMO hingegen nicht viel.

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.
Ich muss da eigentlich nur beim Ausschneiden aufpassen, denn die
eingefügten Werte sind recht simpel aufgebaut:

  
   $cfg_line = '$'.$varname.' = "'.addslashes($value).'";';  
 // oder  
   $cfg_line = preg_replace("/^include.+?;/", "", $cfg_line);  
   $cfg_line = "include_once(\"$filename\");" . $cfg_line;  

Bei $filename müßte ich zB nichtmal sonderlich aufpassen,
weil die mögliche Auswahl eher statisch ist, und dort schon
keine Sonderzeichen vorkommen können.

Wenn auch unwarscheinlich, so würde ein Syntax-Fehler aber die
selben Folgen haben wie ein vergessenes xmlentities() bei der
XML-Konfigurationsdatei. Der Unterschied mit PHP wäre daß /ich/
'nen Fehler evtl. schneller rauseditieren kann ;-)

Ich will mich damit auch nicht rausreden *g*, aber es ist ja
andererseits auch oft gewollt, daß ein Programm mit falschen
Einstellungen den Dienst verweigert.
Wenn Sicherheitseinstellungen, Passwörter oder dergleichen
fehlen, wärs zumindest besser. Und wenn //irgendetwas// fehlt,
läßt sich sowieso immer schlecht sagen was es war.

Danke & Beste Grüße!
mario

[wahsaga]

hi,

Weil mein Script jedoch auf dem Webserver läuft, kommts auch
ein wenig auf Geschwindigkeit an. Das Script wird ja recht häufig
aufgerufen und muß jedesmal beim Start die Einstellungen lesen.
Von daher sind SQL-Tabelle und XML-Parser meiner Meinung nach
schon zu viel des Guten. PHP-Skript oder INI-Datei oder ein
serialize()-Blob nehmen sich IMO hingegen nicht viel.

Implementiere doch ein Caching.
Die einmal aus einem "vernünftigen" Format eingelesenen und geparsten Daten kannst du dir ja in PHP-Format (var_export) oder einem PHP-nahen Format (serialized) ablegen, und per require o.ä. einbinden.

Erneutes Parsen des "komplizierteren" Originalformats nur dann, wenn sich an den Daten etwas geändert hat.

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.

Wenn auch unwarscheinlich, so würde ein Syntax-Fehler aber die
selben Folgen haben wie ein vergessenes xmlentities() bei der
XML-Konfigurationsdatei.

Nö.
Wenn das XML-Parsen fehlschlägt, kann deine Fehlerbehandlung im Script darauf reagieren.
Wenn ein PHP-Syntaxfehler in einer per require eingebundenen Konfigurationsdatei vorliegt - dann ist sofort Ende, der Parser steigt dir aus, und Tschüss.

Ich will mich damit auch nicht rausreden *g*, aber es ist ja
andererseits auch oft gewollt, daß ein Programm mit falschen
Einstellungen den Dienst verweigert.

Aber idR. nicht mit "parse_error in xyz on line 4711" ...

Wenn Sicherheitseinstellungen, Passwörter oder dergleichen
fehlen, wärs zumindest besser. Und wenn //irgendetwas// fehlt,
läßt sich sowieso immer schlecht sagen was es war.

Da ist ja dann deine Fehlerbehandlungsroutine für verantwortlich.

gruß,
wahsaga

[mario]

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

[Tom]

Hello,

php bietet sogar eine Funktion für das Parsen einfacher Konfigurationsdateien an

http://www.php.net/manual/en/function.parse-ini-file.php

Das sollte doch schon mal genügen für den Anfang, ist leicht lesbar, mit jedem normalen Editor herzustellen und auch übersichtlich.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom