$::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 (alle Variablen die einem ans Herz gewachsen sind), sollte man vor einem Aufruf (!) von zum Beispiel IS->retrieve_customer() in Sicherheit bringen.

Z.B. das vom Benutzer eingestellte Zahlenformat, bevor man Berechnung in einem bestimmten Format durchführt (SL/Form.pm Zeile 3552, Stand version 2.7beta), um dies hinterher wieder auf den richtigen Wert zu setzen:

  my $saved_numberformat    = $::myconfig{numberformat};
  $::myconfig{numberformat} = $numberformat;
  # (...) div Berechnungen
  $::myconfig{numberformat} = $saved_numberformat;

Das Objekt der Klasse Form hat leider im Moment noch viele zentrale Funktionen die vom internen Zustand abhängen, deshalb bitte nie einfach zerstören oder überschreiben (zumindestens nicht kurz vor einem Release oder in Absprache über bspw. die devel-Liste ;-). Es geht ziemlich sicher etwas kaputt.

$::form ist gleichzeitig der Standard Scope in den Template::Toolkit™ Templates außerhalb 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}. Nochmal von der anderen Seite erläutert, innerhalb von (Web-)Templates sieht man häufiger solche Konstrukte:

[%- IF business %]
# (... Zeig die Auswahlliste Kunden-/Lieferantentyp an)
[%- END %]

Entweder wird hier dann $::form->{business} ausgewertet oder aber der Funktion $form->parse_html_template wird explizit noch ein zusätzlicher Hash übergeben, der dann auch in den (Web-)Templates zu Verfügung steht, bspw. so:

$form->parse_html_template("is/form_header", \%TMPL_VAR);

Innerhalb von Schleifen wird $::form->{TEMPLATE_ARRAYS}{var}[$index] bevorzugt, wenn vorhanden. Ein Beispiel findet sich in SL/DO.pm, welches über alle Positionen eines Lieferscheins in Schleife läuft:

for $i (1 .. $form->{rowcount}) {
  # ...
  push @{ $form->{TEMPLATE_ARRAYS}{runningnumber} },   $position;
  push @{ $form->{TEMPLATE_ARRAYS}{number} },          $form->{"partnumber_$i"};
  push @{ $form->{TEMPLATE_ARRAYS}{description} },     $form->{"description_$i"};
  # ...
}

%::myconfig ist im Moment der Ersatz für ein Userobjekt. Die meisten Funktionen, die etwas anhand des aktuellen Users entscheiden müssen, befragen %::myconfig. Innerhalb der Anwendungen sind dies überwiegend die Daten, die sich unter Programm -> Einstellungen befinden, bzw. die Informationen über den Benutzer die über die Administrator-Schnittstelle (admin.pl) eingegeben wurden.

Lokalisierung für den aktuellen User. Alle Übersetzungen, Zahlen- und Datumsformatierungen laufen über dieses Objekt.

$::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, sowie "message" und "dump" mit denen man flott Informationen ins Log (tmp/kivitendo-debug.log) packen kann.

Beispielsweise so:

$main::lxdebug->message(0, 'Meine Konfig:' . Dumper (%::myconfig));
$main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});

$::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.

Globale Konfiguration. Configdateien werden zum Start gelesen und danach nicht mehr angefasst. Es ist derzeit nicht geplant, dass das Programm die Konfiguration ändern kann oder sollte.

Beispielsweise ist über den Konfigurationseintrag [debug] die Debug- und Trace-Log-Datei wie folgt konfiguriert und verfügbar:

[debug]
file = /tmp/kivitendo-debug.log

ist der Key file 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.

Funktioniert wie $::lx_office_conf, speichert aber Daten die von der Instanz abhängig sind. Eine Instanz ist hier eine Mandantendatenbank. Beispielsweise überprüft

$::instance_conf->get_inventory_system eq 'perpetual'

ob die berüchtigte Bestandsmethode zur Anwendung kommt.

Der dritte Punkt ist auch der einzige Grund warum das Objekt global gespeichert wird. Wird vermutlich irgendwann in einem anderen Objekt untergebracht.

$::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: