globale Variablen aus DB

[Hans]

Hallo,

ich bin noch recht neu mit PHP und versuche z.Zt. eher grundsätzliche Konzepte für den Aufbau einer komplexeren Anwendung zu verstehen. Dazu gehört u.a. das einmalige Auslesen von z.B. globalen Variablen für eine Anwendung aus einer Datenbank und deren Verwendung in mehreren Dateien ohne jedesmal wieder eine Abfrage auf die DB absetzen zu müssen.

Beispiel: Ich starte meine zentrale Startseite index.php?service=1 und lese nach Übergabe des Parameters "service" entsprechende Parameter aus meiner DB über eine includierte Klasse aus die ich für alle möglichen weiteren Operationen benötige. Solange ich mich in index.php bewege habe ich nach dem Aufruf der Seite alle Parameter zur Verfügung. Nun werden durch den User via Ajax auf meiner Seite diverse andere PHP-Dateien aufgerufen, um z.B. weitere Daten oder GUI Elemente nachzuladen etc. Diese Dateien benötigen auch wieder die Parameter (oder nur Teilmengen) aus der DB. Bisher rufe ich diese Dateien entsprechend der index.php auf und übergebe den Parameter z.B. getdata.php?service=1. Ich frage die gleiche Klasse und bekomme meine Parameter als Array zurück, allerdings wird dadurch wieder ein Aufruf auf die DB abgesetzt.

Meine Frage: Wie kann ich alle Parameter einmalig auslesen und global für alle weiteren Dateiaufrufe vorhalten? Eine Idee waren SESSIONS, allerdings weiß ich nicht ob das ein guter Stil ist über 80 verschiedene Parameter z.B. als Array oder JSON Objekt in einer Sessionvariablen zu speichern. Wie mache ich sowas in PHP? Danke für jeden Tipp Hans

[Auge]

Hallo

Dazu gehört u.a. das einmalige Auslesen von z.B. globalen Variablen für eine Anwendung aus einer Datenbank und deren Verwendung in mehreren Dateien ohne jedesmal wieder eine Abfrage auf die DB absetzen zu müssen.

Meine Frage: Wie kann ich alle Parameter einmalig auslesen und global für alle weiteren Dateiaufrufe vorhalten? Eine Idee waren SESSIONS, allerdings weiß ich nicht ob das ein guter Stil ist über 80 verschiedene Parameter z.B. als Array oder JSON Objekt in einer Sessionvariablen zu speichern.

Die Session ist der richtige Ansatz. Jeder Aufruf eines Skriptes, bei dem die Session-Kennung übermittelt wird, sorgt dafür, dass das Skript auf die in der Session gespeicherten Daten zugreifen kann. Dass soll aber nicht bedeuten, dass du alles in der Session speichern sollst.

Überlege, was während des Ablaufs dauerhaft gleich sein soll und packe es in die Session. Auch veränderliche Werte, die du pro Wert mehrfach benutzt (wie eine -zigfach aufgerufene ID), kannst du in der Session speichern. Werte, die sich absehbar ständig ändern, gehören meiner Meinung nach nicht in die Session.

Tschö, Auge

[Jörg Reinholz]

Moin!

ich bin noch recht neu mit PHP und versuche z.Zt. eher grundsätzliche Konzepte für den Aufbau einer komplexeren Anwendung zu verstehen. Dazu gehört u.a. das einmalige Auslesen von z.B. globalen Variablen für eine Anwendung aus einer Datenbank und deren Verwendung in mehreren Dateien ohne jedesmal wieder eine Abfrage auf die DB absetzen zu müssen.

Dafür wären Sessions, Cookies etc. durchaus ein Weg.

ABER

Die Frage ist die, ob bei den Abrufen neue Daten oder Daten ausgeliefert werden sollen, die eine halbe Stunde alt sind. Es könnte auch vorkommen, dass dem Benutzer Daten geliefert werden, welche auf Grund zwischenzeitlicher Änderungen nicht mehr zusammenpassen:

Beispiel 1: Neuer Artikel eingefügt, taucht aber auch der Startseite nicht auf, weil in der Session gespeichert.

Beispiel 2: Artikel gelöscht, taucht aber in der Übersicht weiterhin auf, Link führt zum 404er...

Zudem sind Sessions, Cookies und dergleichen stets auf den Benutzer bezogen. Das hängt also sehr von der Aufgabenstellung ab.

Hast Du quasi-statische Inhalte (z.B. aus einem CMS) lohnt es sich über einen Cache nachzudenken. Hierzu habe ich mir schon vor einiger Zeit Gedanken gemacht. Fehlt eigentlich nur noch eine Regel für das Löschen des Caches.

Willst Du nicht wie gezeigt die Rückgaben ganzer Requests, also "Webseiten" speichern (was oft sinnvoller sinnvoller sein dürfte als dann in PHP erfolgende Operation dennoch zu wiederholen) kannst Du auch die Ergebnisse aus dem Datenbank-Request speichern, z.B. als in JSON serialisierten Array. Beachte, dass auch hier eine Regel für das Löschen des Abfrage-Caches benötigt wird.

Jörg Reinholz

[Jörg Reinholz]

Moin!

Weiterhin kann man natürlich "Sniplets" als Textdatei abspeichern, also die Ergebnisse von Teiloperationen. Hier mache ich das mit "geparsten" RSS-Feeds, weil die Nutzer unterschiedliche Einstellungen haben könnten - was den Cache aufblähen würde.

Den Effekt des serverseitigen Cachens ganzer Webseiten kannst Du Dir hier ansehen.

Jörg Reinholz

[Hans]

Dafür wären Sessions, Cookies etc. durchaus ein Weg.

ABER

Die Frage ist die, ob bei den Abrufen neue Daten oder Daten ausgeliefert werden sollen, die eine halbe Stunde alt sind. Es könnte auch vorkommen, dass dem Benutzer Daten geliefert werden, welche auf Grund zwischenzeitlicher Änderungen nicht mehr zusammenpassen:

Beispiel 1: Neuer Artikel eingefügt, taucht aber auch der Startseite nicht auf, weil in der Session gespeichert.

Beispiel 2: Artikel gelöscht, taucht aber in der Übersicht weiterhin auf, Link führt zum 404er...

Zudem sind Sessions, Cookies und dergleichen stets auf den Benutzer bezogen. Das hängt also sehr von der Aufgabenstellung ab.

Ok, besten Dank für die Hinweise. Also in meinem Fall handelt es sich wirklich nur um das Auslesen von Statischen Variablen für einen bestimmten Client. Diese werden nicht während der Session verändert (wie gesagt, ca. maximal 80 Werte). In so einem Fall sind die Sessions dann doch der einfachste Weg die Daten zu cachen um sie in jedem Skript verfügbar zu haben? Hans

[Jörg Reinholz]

Moin!

Also in meinem Fall handelt es sich wirklich nur um das Auslesen von Statischen Variablen für einen bestimmten Client. Diese werden nicht während der Session verändert (wie gesagt, ca. maximal 80 Werte). In so einem Fall sind die Sessions dann doch der einfachste Weg die Daten zu cachen um sie in jedem Skript verfügbar zu haben?

Ja. Im Hinblick auf die gelieferten Informationen würde ich das so sehen. Übrigens, wenn es sich um Nutzereinstellungen oder derlei handelt, kann man diese durchaus auch ändern. Einfach die Session-Variable überladen. Bequemer geht es kaum.

Jörg Reinholz

[Hans]

Ja. Im Hinblick auf die gelieferten Informationen würde ich das so sehen. Übrigens, wenn es sich um Nutzereinstellungen oder derlei handelt, kann man diese durchaus auch ändern. Einfach die Session-Variable überladen. Bequemer geht es kaum.

Danke! Ich suche auch noch nach einem sinnvollen Weg globale statische Variablen die nicht aus der DB sondern aus einem Konfigurationsfile kommen zu speichern und auszulesen. Ich habe mir eben mal Dein fastix-cms runtergeladen und angeschaut darin parst Du eine .ini Datei und greifst so über das entstandene Array auf diese Daten zu. z.Zt. definiere ich solche Daten über die define() Methode, z.B. define('VARIABLE1', 'xyz'); Ich habe auch noch gelesen das es sinnvoll wäre solche Daten in einer Klasse zu definieren. Worin besteht der Vorteil der .ini Methode? Hans

[Jörg Reinholz]

Moin!

Worin besteht der Vorteil der .ini Methode?

Vorteile:

1. Für Menschen sehr gut lesbar.
2. Kommentare sind möglich
3. PHP bietet eine native Funktion zum Lesen.

Nachteile:

1. relativ(!) schwer durch ein Programm zu erzeugen (was nicht heisst, dass es nicht geht).
2. kann keine Arrays speichern, assoziative Arrays nur mit einer Ebene.

Hinweis/Tip:

Die Ergebnisse von parse_ini_file() an $GLOBALS anhängen:

 $GLOBALS['config']=parse_ini_file('/foo/bar/config.ini', true);

Jörg Reinholz

[Jörg Reinholz]

Moin!

2. kann keine Arrays speichern, assoziative Arrays nur mit einer Ebene.

Ach so. Das muss kein Nachteil sein. Wenn mehrere Ebenen gewünscht sind ist das Projekt meist sehr groß.

Dann bietet sich folgendes an:

$GLOBALS['config']['foo']=parse_ini_file('foo.ini', true);
$GLOBALS['config']['bar']=parse_ini_file('bar.ini', true);

Oder, automatisch für Plugins:

$plugdir='./plugins';
$d=dir($plugdir);
while( false !== ($e = $d->read()) ) {
    $f="$plugdir/$e/settings.ini";
    if ( is_dir ("$plugdir/$e") &&
         is_readable("$plugdir/$e") &&
         is_file($f) &&
         is_readable($f)
        ) {
        $GLOBALS['config'][$e]=parse_ini_file($f, true);
    }
}

Jörg Reinholz

[dedlfix]

Tach!

Danke! Ich suche auch noch nach einem sinnvollen Weg globale statische Variablen die nicht aus der DB sondern aus einem Konfigurationsfile kommen zu speichern und auszulesen.

Eine Session ist auch nur eine Datei. Wenn du die Werte aus einer Konfigurationsdatei liest, um sie beim nächsten Mal aus einer Session-Datei zu lesen, wirst du damit keinen Vorteil erhalten. Es wird nur umständlicher, weil du beide Abfragearten in dein Programm einbauen musst.

Ich habe auch noch gelesen das es sinnvoll wäre solche Daten in einer Klasse zu definieren.

Du meinst statt Datendateien stehen die Werte in PHP-Code-Dateien? Ob Klasse oder Array oder eine Liste von define-Anweisungen ist dabei egal. Der Vorteil wäre, dass der PHP-Parser die Datei liest und dann schon alles intus hat. Zudem gibt es auch Caches für PHP-Code.

Was auch noch anzumerken wäre: Don't look for things! ist eine der Regeln für sauberes Programmieren. Die muss man nicht berücksichtigen, aber es erleichtert die Arbeit und vor allem das Verstehen und Verwenden von unbekanntem Code. Wenn der Code ein ganz speziell gestaltetes Nest braucht, weil er an bestimmten Stellen die benötigten Dinge erwartet, dann musst du immerzu aufpassen, dass dieses Nest ständig für sämtliche Teile passend bleibt. Man kann auch nicht mal eben bei Bedarf was anderes übergeben, weil der Code ja selbständig zugreift. Für die Ausnahme etwas anderes ins Regal zu stellen und danach wieder den alten generell gültigen Wert, ist sehr gewagt, weil das voraussetzt, dass sämtlicher in der Zeit aufgerufener anderer Code ebenfalls mit dem geänderten Wert zufrieden ist. Es ist stattdessen besser, dem Code zu übergeben, was er braucht. Es gibt keine mehr oder weniger versteckten seitlichen Abhängigkeiten, alles geht sozusagen oben rein und unten kommt das Ergebnis raus. Das hört auch auf den Namen Dependency Injection.

dedlfix.