Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03131.jsonl.gz/2920

Lokale Variablen als global zu deklarieren finde ich persönlich nur sub-optimal, und kann recht fehleranfällig sein. Je nach Namen kann/könnte sie mit einer schon vorhandenen gleichnamigen Variablen im globalen Namensraum kollidieren, oder auch 'später' durch eine gleichnamige Var in einem anderen Script überschrieben werden. Mindestens den Namen entsprechend zu prefixen wäre was, z.B $haguJumiVar1.
Besser wäre es aber, wenn du dazu die JRegistry-Klasse oder auch die User-Session verwendest. Denn für solche Dinge sind die da. Auch JRequest könnte man dazu 'missbrauchen'. Oder halt auch ein Cookie setzten und wieder auslesen, wenn's denn sein muss. Oder wenn du eine eigene Klasse oder Funktion verwendest könntest du auch statische Variablen verwenden. Oder auch eigene Konstanten definieren
Es ist mir klar, dass ich mich auf die Namensvergabe der Variable achten muss.
Ich möchte in einem Modul, welches ich als erstes aufrufe, eine Verbindung zu einer Datenbank herstellen.
In Modulen, welche ich später aufrufe, möchte ich die Daten aus der Datenbank ausgeben.
Das ganze soll ohne allzugrossen Aufwand entstehen. Es wird auch nur für interne Zwecke verwendet. Sicherheit steht da nicht an erster Stelle.
Joomla mit Jumi scheint mir da eine Lösung zu sein, um sowas schnell zu bewerkstelligen.
Ich finde es aber merkwürdig, dass weder eine Variable, noch eine Funktion oder eine Klasse im nächsten Modul vorhanden ist.
Weil wie schon erwähnt, lokale Variablen als global setzen unzuverlässig ist. Du siehts es ja. Das hab ich bisher noch nie irgendwo verwendet, und werde das auch nie tun. Das ist noch aus der Zeit, als PHP weniger Objekt-Orientiert war, und gilt schon länger als 'bad' oder 'poor' practice.
Da gibt es seit PHP5 und insbesondere im Joomla-Framework geeignetere und weitaus bessere Möglichkeiten. Ein paar hab ich dir aufgezählt. Und eine vergessen:
Den eingebauten Caching-Mechanismus von Joomla (JCache), der z.B. von fast allen Core-Modulen genutzt wird. Ermöglicht ein Session unabhängiges Caching.
Ein Beispiel:
Die Daten in die Usersession schreiben. Ist simpel, und ein Caching (Lebensdauer der Session) ist auch gleich mit dabei:
Datengenerierung:
$sessionData = JFactory::getApplication()->getUserState('mod_meinmodul.daten', false);
if(false === $sessionData)
{
// Noch keine Daten vorhanden: generieren und in Session schreiben
$dbDaten = [DATEN];
$jsonData = json_decode($dbDaten);
JFactory::getApplication()->setUserState('mod_meinmodul.daten', $jasonData);
}
Ich habe mir die Jumi-Module mal geholt und installiert. Der Code wird da mit eval() ausgeführt, jedenfalls in der Version für 2.5. Und dieses eval() hat auch so seine Besonderheiten, was den Namensraum von Variablen betrifft.
php.net/manual/de/function.eval.php
Ob das mit dem JSON-String nötig ist, und welchen default-Wert die Session-Daten haben sollten, musst du wissen, je nach Datengrösse, -Struktur und -Art, und Code für die Auswertung/Anzeige.
Mir viel noch was auf:
Die Module haben ja auch ein Caching. Würd ich ausschalten, wenn du das so wie oben mit der User-Session verwendest. Tipp zum testen: eine neue Session im Frontend gibt's immer jeweils beim Ausloggen.
Man soll das Kind ins Korn werfen solange es noch heiss ist, auch wenn das der eine Tropfen ist, der dem Fass die Krone ins Gesicht schlägt...