$::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/lx-office-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/lx-office-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: