Configuration Auslagern

[.MB]

Hallo Community,

das klassenbasierende PHP Programm mit PDO Schnittstelle ist zunehmend komplexer geworden was zu erwarten war. Ich habe Klassen Parameter in eine Config PHP ausgelagert. Diese Config PHP ist an String Variablen immer mehr geworden.

Frage 1: Ist es Sinvoll semantisch zusammengehöriger Variablen in einem definierendem Objekt zu fokusieren (oder in einem Array wie einBenutzer dieses Forums mir vorgeschlagen hat)?

Frage 2: Der selbe Benutzer hat vorgeschlagen diese Config Daten in eine INI-Datei zu schreiben. Ist es nicht egal woher die Klassen die Daten beziehen?

Herzliche Grüße, MB

[dedlfix]

Tach!

Frage 1: Ist es Sinvoll semantisch zusammengehöriger Variablen in einem definierendem Objekt zu fokusieren (oder in einem Array wie einBenutzer dieses Forums mir vorgeschlagen hat)?

Das kannst du machen, wie du es für richtig hältst.

Frage 2: Der selbe Benutzer hat vorgeschlagen diese Config Daten in eine INI-Datei zu schreiben. Ist es nicht egal woher die Klassen die Daten beziehen?

Ja, ist egal. Eine ini- oder sonstwie-Datei ist aufwendiger einzulesen, aber einfacher zu pflegen, besonders wenn das programmierunkundiges Personal übernehmen soll (oder solches, dem man die korrekte PHP-Syntax nicht beibringen kann).

Die Daten brauchst du am Ende im Programm in irgendeiner Struktur. Das kann ein Array oder ein Objekt oder zur Not einzelne Variablen sein. Du kannst das also gleich so in deine config.php als Programmcode einfügen. Es sei denn, du brauchst unbedingt eine ini-Datei.

dedlfix.

[MB]

Hallo Dedlfix,

Ja, ist egal. Eine ini- oder sonstwie-Datei ist aufwendiger einzulesen, aber einfacher zu pflegen, besonders wenn das programmierunkundiges Personal übernehmen soll (oder solches, dem man die korrekte PHP-Syntax nicht beibringen kann).

stimmt da kann ich mit arbeitet besten dank

Die Daten brauchst du am Ende im Programm in irgendeiner Struktur. Das kann ein Array oder ein Objekt oder zur Not einzelne Variablen sein. Du kannst das also gleich so in deine config.php als Programmcode einfügen. Es sei denn, du brauchst unbedingt eine ini-Datei.

Ok, Gut Danke

[Der Martin]

Mahlzeit,

eins vorweg: Ich glaube, auf diesen Komplex an Fragen gibt es keine einfache, klare Antwort.

Frage 1: Ist es Sinvoll semantisch zusammengehöriger Variablen in einem definierendem Objekt zu fokusieren (oder in einem Array wie einBenutzer dieses Forums mir vorgeschlagen hat)?

Ich denke schon. Daten, die thematisch oder von ihrem Zweck her zusammengehören, würde ich, soweit möglich, auch in einer gruppierenden Struktur zusammenfassen. Ob nun ein Objekt (eine Klasse) oder einfach ein assoziatives Array günstiger ist, müsste man von Fall zu Fall abwägen.

Frage 2: Der selbe Benutzer hat vorgeschlagen diese Config Daten in eine INI-Datei zu schreiben. Ist es nicht egal woher die Klassen die Daten beziehen?

Radio Eriwan: Im Prinzip ja. ;-)
Die gewählte Lösung soll einerseits gut überschaubar und leicht zu pflegen sein, andererseits schnell und effizient arbeiten, und nach Möglichkeit auch noch universell, so dass man sie als Modul leicht in ein anderes Projekt übernehmen kann.
Das ini-Dateiformat ist textbasiert und menschenlesbar; es bietet sich daher an, wenn auch Laien die Konfiguration editieren sollen. Andererseits braucht das Parsen einer ini-Datei bestimmt ein wenig mehr Rechenleistung, als wenn die Parameter direkt als PHP-Variablen im Code stehen.

Du siehst: Keine einfache Entscheidung ...

So long,
 Martin

[MB]

Mahlzeit Martin,

eins vorweg: Ich glaube, auf diesen Komplex an Fragen gibt es keine einfache, klare Antwort.

Ja das hab ich beführchtet.

Das ini-Dateiformat ist textbasiert und menschenlesbar; es bietet sich daher an, wenn auch Laien die Konfiguration editieren sollen. Andererseits braucht das Parsen einer ini-Datei bestimmt ein wenig mehr Rechenleistung, als wenn die Parameter direkt als PHP-Variablen im Code stehen.

Frage zu dem: Beides sind Klartext Dateien. Warum also braucht ini fürs aulesen mehr rechenleistung? Ok. Wenn ich etwas in eine php-datei auslagere, sind die Variable direkt in php vorhanden. Ich nehme mal an, dass das öffnen und laden von variablen von einer ini über fopen() einwenig rechenkapazität benötigt. aber ist das den soviel das man da spürbar n unterschied merkt?

Grüße MB

[Auge]

Hallo

Das ini-Dateiformat ist textbasiert und menschenlesbar; es bietet sich daher an, wenn auch Laien die Konfiguration editieren sollen. Andererseits braucht das Parsen einer ini-Datei bestimmt ein wenig mehr Rechenleistung, als wenn die Parameter direkt als PHP-Variablen im Code stehen.

Frage zu dem: Beides sind Klartext Dateien. Warum also braucht ini fürs aulesen mehr rechenleistung? Ok. Wenn ich etwas in eine php-datei auslagere, sind die Variable direkt in php vorhanden. Ich nehme mal an, dass das öffnen und laden von variablen von einer ini über fopen() einwenig rechenkapazität benötigt.

Womit du dir die Frage schon selbst beantwortet hast. Für das Einlesen von INI-Dateien aber auch anderweitig vorhandenen Strings im INI-Format gibt es übrigens Funktionen, die die Anweisungen gleich parsen. Den Umweg über fopen braucht man also nicht zu gehen.

aber ist das den soviel das man da spürbar n unterschied merkt?

Wenn du da nicht eine -zig Mebabyte große Datei an den Start bringst, ist das wohl nicht erheblich.

Tschö, Auge

[MB]

Hallo Auge,

Womit du dir die Frage schon selbst beantwortet hast.

Gut, das wäre geklärt

Für das Einlesen von INI-Dateien aber auch anderweitig vorhandenen Strings im INI-Format gibt es übrigens Funktionen, die die Anweisungen gleich parsen. Den Umweg über fopen braucht man also nicht zu gehen.

klingt gut. würd mich sehr gern damit befassen wenn die zeit nicht so drängt :/.

aber ist das den soviel das man da spürbar n unterschied merkt?

Wenn du da nicht eine -zig Mebabyte große Datei an den Start bringst, ist das wohl nicht erheblich.

Besten Dank. MB

[Jörg Reinholz]

Moin!

klingt gut. würd mich sehr gern damit befassen wenn die zeit nicht so drängt :/.

Hehe. Das sind nur wenige Zeilen und es gibt da nicht viel zu murksen:

<?php
$GLOBALS['config'] = parse_ini_file('test.ini', true);

echo $config['foo']['bar'], "\n";
globalTest();

function globalTest() {
  echo "In Funktion: ", $GLOBALS['config']['bar']['test'], "\n";
}

Variante:

<?php
$GLOBALS['config'] = parse_ini_file('test.ini', false);

echo $config['bar'], "\n";
globalTest();

function globalTest() {
  echo "In Funktion: ", $GLOBALS['config']['test'], "\n";
}

Die test.ini

[foo]
bar = "Nicht Barfuß"
;weitere Einträge ...

[bar]
test = "Funktioniert!"
;weitere Einträge ...

Jörg Reinholz

[Sven Rautenberg]

Moin!

Das ini-Dateiformat ist textbasiert und menschenlesbar; es bietet sich daher an, wenn auch Laien die Konfiguration editieren sollen. Andererseits braucht das Parsen einer ini-Datei bestimmt ein wenig mehr Rechenleistung, als wenn die Parameter direkt als PHP-Variablen im Code stehen.

Frage zu dem: Beides sind Klartext Dateien. Warum also braucht ini fürs aulesen mehr rechenleistung? Ok. Wenn ich etwas in eine php-datei auslagere, sind die Variable direkt in php vorhanden. Ich nehme mal an, dass das öffnen und laden von variablen von einer ini über fopen() einwenig rechenkapazität benötigt. aber ist das den soviel das man da spürbar n unterschied merkt?

PHP-Code landet im Opcode-Cache. Dort steht er als vorkompilierter Bytecode zur Verfügung und kann direkt in Variablenerzeugungsaktion treten. Muss man hingegen eine INI-Datei einlesen, steht nix im Cache, man muss die Datei öffnen, einlesen, parsen - dann noch die Variablen erzeugen, wie im PHP-Code auch. Das ist in der Regel langsamer.

Kniff: Man kann das Ergebnis des INI-Parsens mit var_export() auch als PHP-Code wieder in eine Datei schreiben und alternativ benutzen. Allerdings ist das Erzeugen solch eines File-Caches nicht trivial, vor allem im Hinblick auf die Neuerzeugung bei Änderungen.

Grüße Sven

[pl]

Richtig, überlege dir eine bestimmte Datenstruktur für deine Konfiguration, denn du willst ja wahlfreien Zugriff un gelegentlich auch mal einen Dump im Browser ausgeben (zum prüfen ob die Konfiguration stimmt). Also Array oder associative Array und guck dass du das nicht mehr als nötig tief verschachteln tust.

Hast du die Datenstruktur (so flach wie möglich, so tief wie nötig) gefunden, guckst Du nach einer geeigneten Verpackung. Beispielsweise hast du eine Datenstruktur nach dem Schema Entity => { Attribute => Value } eine Solche passt sehr gut in eine ini-Datei:

[Entity]
Attibute=Value

Und natürlich passen da auch weitere EAV's rein. Das EAV-Schema is wirklich gut, da wurden schon Doktorarbeiten darüber geschriebn ;)

Und die Magento-Shop Entwickler behaupten, sie hättens erfunden.

[MB]

Hallo pl,

Richtig, überlege dir eine bestimmte Datenstruktur für deine Konfiguration, denn du willst ja wahlfreien Zugriff un gelegentlich auch mal einen Dump im Browser ausgeben (zum prüfen ob die Konfiguration stimmt). Also Array oder associative Array und guck dass du das nicht mehr als nötig tief verschachteln tust.

Gut. Mein Progrämmche ist mitlerweile ein wenig komplexer geworden, daher ist es gut das du das aufgezeigt hast. Wäre da mit fopen() ran gegangen wenn du nicht eingeleenkt hättest ;-).

Hast du die Datenstruktur (so flach wie möglich, so tief wie nötig) gefunden, guckst Du nach einer geeigneten Verpackung. Beispielsweise hast du eine Datenstruktur nach dem Schema Entity => { Attribute => Value } eine Solche passt sehr gut in eine ini-Datei:

Besten Dank, für die Richtung der Vorgehensweise.

MB

[Der Martin]

Hallo,

ich bin mir nicht sicher, ob du gerade noch den Überblick hast.

Richtig, überlege dir eine bestimmte Datenstruktur für deine Konfiguration, denn du willst ja wahlfreien Zugriff un gelegentlich auch mal einen Dump im Browser ausgeben (zum prüfen ob die Konfiguration stimmt). Also Array oder associative Array und guck dass du das nicht mehr als nötig tief verschachteln tust.

Gut. Mein Progrämmche ist mitlerweile ein wenig komplexer geworden, daher ist es gut das du das aufgezeigt hast. Wäre da mit fopen() ran gegangen wenn du nicht eingeleenkt hättest ;-).

Vergiss bitte nicht, dass die Form, in der Konfigurationsdaten gespeichert werden (ini-Datei, PHP-Include, Datenbank, Binärdateien) und die Form, in der die Daten im Script vorliegen (Arrays, Objekte, einzelne Variablen mit gemeinsamen Namens-Präfixen) zwei völlig getrennte Aspekte sind. Mich beschleicht der Verdacht, dass du das gerade eifrig vermischt hast.

So long,
 Martin So long,
 Martin

[MB]

Hllo Martin,

Vergiss bitte nicht, dass die Form, in der Konfigurationsdaten gespeichert werden (ini-Datei, PHP-Include, Datenbank, Binärdateien) und die Form, in der die Daten im Script vorliegen (Arrays, Objekte, einzelne Variablen mit gemeinsamen Namens-Präfixen) zwei völlig getrennte Aspekte sind. Mich beschleicht der Verdacht, dass du das gerade eifrig vermischt hast.

Gut das du das ansprichst obwohl ich dich nicht so richtig verstanden habe. Hab da mal ne Frage: Worin bitte liegt der unterschied zwischen Sequentieller- wahlfreier- und Binärer Zugriff? Ich hab das mal gelesen aber nicht so ganz verstanden. Wer erzeugt Dateien die man nur mit den der genannten lesen und schreiben kann?

Herzlichste Grüße MB

[Jörg Reinholz]

Moin!

Sequentieller- wahlfreier- und Binärer Zugriff?

Stell Dir ein SEHR dickes Buch vor.

Sequentieller Zugriff:

Du musst den ganzen Mist lesen, bis Du zu Kapitel 913 auf Seite 10425 kommst.

Wahlfreier Zugriff:

Du schaust im Inhaltsverzeichnis nach, dass Kapitel 913 auf Seite 10425 beginnt und gehst direkt dahin. Das Inhaltsverzeichnis ist aber auch SEHR lang.

"Binärer" Zugriff:

Inhaltsverzeichnis verweist auf Seite 1 unter "Kapitel 900-999" auf Seite 10. Auf Seite 10 findest Du den Hinweis, dass die Kapitel "910 bis 929" auf Seite 110 gelistet sind. Auf Seite 110 findest Du heraus, dass das Kapitel 913 auf Seite 10425 beginnt und gehst direkt dahin.

Beim "Binären Zugriff" hast du zwar 4 Seiten aufschlagen aber nur 15 (10+3+2) Verzeichnisseinträge lesen müssen.

Und jetzt stell Dir das mit Datenblöcken vor und kombiniere das mit der Lösung des Wägeproblems.

Jörg Reinholz

[MB]

Hallo Jörg,

Jetzt habe ich es verstanden durch die bildlich beschreibende Erklärung. Besten Dank.

Grüße MB

[Jörg Reinholz]

Moin!

Danke für den Dank. Ich lebe davon erwachsenen Neueinsteigern (oder Fachgebietsumsteigern) IT-Themen zu "erklären", übe das hier sozusagen selbst und teste hier also auch meine "Kernsätze" gegen die "Wissen wollenden" und Experten. In dieser Situation ist Feedback für mich sehr wichtig.

Jörg Reinholz

[MB]

Hallo Jörg,

Danke für den Dank. Ich lebe davon erwachsenen Neueinsteigern (oder Fachgebietsumsteigern) IT-Themen zu "erklären", übe das hier sozusagen selbst und teste hier also auch meine "Kernsätze" gegen die "Wissen wollenden" und Experten. In dieser Situation ist Feedback für mich sehr wichtig.

gern. Du hast es ja auch sehr bildhaft und gut erklärt. nochmals vielen Dank.

MB

[Christian Kruse]

Hallo Jörg,

Sequentieller- wahlfreier- und Binärer Zugriff?

Stell Dir ein SEHR dickes Buch vor.

Sequentieller Zugriff:

Du musst den ganzen Mist lesen, bis Du zu Kapitel 913 auf Seite 10425 kommst.

Wahlfreier Zugriff:

Du schaust im Inhaltsverzeichnis nach, dass Kapitel 913 auf Seite 10425 beginnt und gehst direkt dahin. Das Inhaltsverzeichnis ist aber auch SEHR lang.

"Binärer" Zugriff:

Inhaltsverzeichnis verweist auf Seite 1 unter "Kapitel 900-999" auf Seite 10. Auf Seite 10 findest Du den Hinweis, dass die Kapitel "910 bis 929" auf Seite 110 gelistet sind. Auf Seite 110 findest Du heraus, dass das Kapitel 913 auf Seite 10425 beginnt und gehst direkt dahin.

Vorsicht. Dieser Vergleich erweckt den Eindruck, dass es immer schneller ist random auf eine Datei zuzugreifen („binärer“ Zugriff ist auch nur eine Art des Random Access). Das ist nicht der Fall. Je nach Datenmenge kann es bedeutend schneller sein, die ganze Datei zu lesen. Datenbanken haben eigens dafür Heuristiken entwickelt; die Abwägung ist viel komplizierter als sie scheinen mag.

LG,
CK

[Jörg Reinholz]

Moin!

• Stell Dir ein SEHR dickes Buch vor.
• Das Inhaltsverzeichnis ist aber auch SEHR lang.

Je nach Datenmenge kann es bedeutend schneller sein, die ganze Datei zu lesen.

Ja, klar. Deshalb hatte ich bei den Items auch stark betont auf die große Datenmenge und den großen Index ("Inhaltsverzeichnis") verwiesen.

Jörg Reinholz