--- /dev/null
+nachdem Holger heute den Bug eingestellt hat den ich schon lange befürchtet
+habe, bin ich heute mal die globalen Variablen angegangen. Das ganze ist über
+die Jahre leider recht komfus geworden, deshalb hier ne Erklärung, die
+hoffentlich sowas in Zukunft vermeidet.
+
+
+Wie sehen globale Variablen in Perl aus?
+----------------------------------------
+
+Globale Variablen liegen in einem speziellen namespace namens "main", der von
+überall erreichbar ist. Darüber hinaus sind bareword globs global und die
+meisten speziellen Variablen sind... speziell.
+
+Daraus ergeben sich folgende Formen:
+
+ $main::form - expliziter namespace main
+ $::form - impliziter namespace main
+ open FILE, "file.txt" - FILE ist global
+ $_ - speziell.
+
+(Ja, da fehlen noch ein paar Sachen, ich weiß)
+
+Im Gegensatz zu PHP gibt es kein Schlüsselwort wir "global" mit dem man
+importieren kann, my, our und local machen was anderes.
+
+ my $form - lexikalische Variable, gültig bis zum Ende des scopes
+ our $form - $form referenziert ab hier $PACKAGE::form.
+ local $form - Alle Änderungen an $form werden am Ende des scopes zurückgesetzt
+
+Warum ist das ein Problem?
+--------------------------
+
+Das erste Problem ist FCGI.
+
+sql-ledger hat fast alles im globalen namespace abgelegt, und erwartet, dass es
+da auch wiederzufinden ist. Unter FCGI müssen diese Sachen auch wieder
+aufgeräumt werden, damit sie nicht in den nächsten Request kommen. Einige
+Sachen wiederum sollen nicht gelöscht werden, wie zum Beispiel
+Datenbankverbindungen, weil die ne Ewigkeit zum initialisieren brauchen.
+
+Das zweite Problem ist strict.
+
+Unter strict werden alle Variablen die nicht explizit mit Package, my oder our
+angegeben werden als Tippfehler angemarkert, was einen vor so mancher Stunde
+suchen nach einem Bug erspart. Da globale Variablen aber implizit mit Package
+angegeben werden, werden die nicht geprüft, und ein Tippfehler da fällt
+niemandem auf.
+
+Kanonische globale Variablen
+----------------------------
+
+Um dieses Problem im Griff zu halten gibt es einige wenige globale Variablen,
+die kanonisch sind, und alles andere sollte anderweitig umhergereicht werden.
+
+Diese Variablen sind im Moment die folgenden neun:
+
+ $::form
+ %::myconfig
+ $::locale
+ $::lxdebug
+ $::auth
+ $::lx_office_conf
+ $::instance_conf
+ $::dispatcher
+ $::request
+
+Damit diese nicht als Müllhalde misbrauch werden, im Folgenden eine kurze
+Erläuterung was man von denn erwarten kann.
+
+
+$::form
+
+- Ist ein Objekt der Klasse "Form"
+- Wird nach jedem Request gelöscht
+- Muss auch in Tests und Konsolenscripts vorhanden sein.
+- Enthält am Anfang eines Requests die Requestparameter vom User
+- Kann zwar intern über Requestgrenzen ein Datenbankhandle cachen, das wird
+ aber momentan absichtlich zerstört
+
+$::form wurde unter sql ledger als Gottobjekt für alles misbraucht. Sämtliche alten
+Funktionen unter SL/ mutieren $::form, das heißt, alles was einem lieb ist,
+sollte man vor einem Aufruf von zum Beispiel IS->retrieve_customer in Sicherheit bringen.
+
+Das Objekt der Klasse Form hat leider im Moment noch viele zentrale Funktionen
+Gdie vom internen Zustand abhängen, deshalb bitte nie einfach zerstören oder
+überschreiben. Es geht ziemlich sicher etwas kaputt.
+
+$::form ist gleichzeitig der Standard Scope in den Template::Toolkit Templates
+ausserhalb der Controller, der Ausdruck [% var %] greift auf $::form->{var} zu.
+Unter Controllern ist der Standard Scope anders, da lautet der Zugriff [%
+FORM.var %]. In Druckvorlagen sind normale Variablen ebenfall im $::form Scope,
+d.h. <%var%> zeigt auf $::form->{var}. Innerhalb von Schleifen
+wird $::form->{TEMPLATE_ARRAYS}{var}[$index] bevorzugt wenn vorhanden.
+
+
+%::myconfig
+
+- Das einzige Hash unter den globalen Variablen
+- Wird spätestens benötigt wenn auf die Datenbank zugegriffen wird
+- Wird bei jedem Request neu erstellt.
+- Enthält die Userdaten des aktuellen Logins
+- Sollte nicht ohne Filterung irgendwo gedumpt werden oder extern serialisiert
+ werden, weil da auch der Datenbankzugriff für diesen user drinsteht.
+- Enthält unter anderem Listenbegrenzung vclimit, Datumsformat dateformat und
+ Nummernformat numberformat
+- Enthält Datenbankzugriffinformationen
+
+%::myconfig ist im Moment der Ersatz für ein Userobjekt. Die meisten Funktionen,
+die etwas anhand des aktuellen Users entscheiden müssen befragen %::myconfig.
+
+
+$::locale
+
+- Objekt der Klasse "Locale"
+- Wird pro Request erstellt
+- Muss auch für Tests und Scripte immer verfügbar sein.
+- Cached intern über Requestgrenzen hinweg benutzte Locales
+
+Lokalisierung für den aktuellen User. Alle Übersetzungen, Zahlen- und
+Datumsformatierungen laufen über dieses Objekt.
+
+
+$::lxdebug
+
+- Objekt der Klasse "LXDebug"
+- Wird global gecached
+- Muss immer verfügbar sein, in nahezu allen Funktionen
+
+$::lxdebug stellt Debuggingfunktionen bereit, wie "enter_sub" und "leave_sub",
+mit denen in den alten Modulen ein brauchbares Tracing gebaut ist, "log_time",
+mit der man die Wallclockzeit seit Requeststart loggen kann, und "message" und
+"dump" mit denen man flott Informationen ins Log packen kann.
+
+
+$::auth
+
+- Objekt der Klasse "SL::Auth"
+- Wird global gecached
+- Hat eine permanente DB Verbindung zur Authdatenbank
+- Wird nach jedem Request resettet.
+
+$::auth stellt Funktionen bereit um die Rechte des aktuellen Users abzufragen.
+Obwohl diese Informationen vom aktuellen User abhängen wird das Objekt aus
+Geschwindigkeitsgründen nur einmal angelegt und dann nach jedem Request kurz
+resettet.
+
+
+$::lx_office_conf
+
+- Objekt der Klasse "SL::LxOfficeConf"
+- Global gecached
+- Repräsentation der config/lx_office.conf[.default] Dateien
+
+Globale Konfiguration.
+
+Configdateien werden zum Start gelesen, und nicht mehr angefasst. Es ist
+derzeit nicht geplant, dass das Programm die Konfiguration ändern kann oder
+sollte.
+
+Der Konfigurationskey
+
+ [Debug]
+
+ file = /tmp/lxoffice_debug_log.txt
+
+ist im Programm als $::lx_office_conf->{Debug}{file} erreichbar.
+
+Warnung: Zugriff auf die Konfiguration erfolgt im Moment über Hashkeys, sind
+also nicht gegen Tippfehler abgesichert.
+
+
+$::instance_conf
+
+- Objekt der Klasse "SL::InstanceConfiguration"
+- wird pro Request neu erstellt.
+
+Funktioniert wie $::lx_office_conf, speichert aber Daten die von der Instanz
+abhängig sind. Eine Instanz ist hier eine Mandantendatenbank. Prominentestes
+Datum ist "eur", die Information ob Bilanz oder Einnahmenüberschussrechnung
+gemacht wird.
+
+
+
+$::dispatcher
+
+- Objekt der Klasse "SL::Dispatcher"
+- wird pro Serverprozess erstellt.
+- enthält Informationen über die technische Verbindung zum Server
+
+Der dritte Punkt ist auch der einzige Grund warum das Objekt global gespeichert
+wird. Wird vermutlich irgendwann in einem anderen Objekt untergebracht.
+
+
+
+$::request
+
+- Hashref
+- Wird pro Request neu initialisiert.
+- Keine Unterstruktur garantiert.
+
+$::request ist ein generischer Platz um Daten "für den aktuellen Request"
+abzulegen. Sollte nicht für action at a distance benutzt werden, sondern um
+lokales memoizing zu ermöglichen, das garantiert am Ende des Requests zerstört
+wird.
+
+Vieles von dem was im moment in $::form liegt sollte eigentlich hier liegen.
+Die groben Differentialkriterien sind:
+
+- Kommt es vom User, und soll unverändert wieder an den User?
+ => $::form, steht da eh schon
+
+- Sind es Daten aus der Datenbank, die nur bis zum Ende des Requests gebraucht werden?
+ => $::request
+
+- Muss ich von anderen Teilen des Programms lesend drauf zugreifen?
+ => $::request, aber Zugriff über Wrappermethode
projects / kivitendo-erp.git / commitdiff