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

Beitrag lesen

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

--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }