projekt kivitendo

    $::request     = undef;

  $::request       = { };

  $::request  = undef;

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

  $::request       = { };

  $::request      = { };

  $::request = { };

  @globals = qw(lxdebug auth myconfig form cgi lx_office_conf locale dispatcher instance_conf request);