|  | <html><head>
 | 
  
    |  |       <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 | 
  
    |  |    <title>Kapitel 4. Entwicklerdokumentation</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo 3.6.1: Installation, Konfiguration, Entwicklung"><link rel="up" href="index.html" title="kivitendo 3.6.1: Installation, Konfiguration, Entwicklung"><link rel="prev" href="ch03s10.html" title="3.10. ZUGFeRD Rechnungen"><link rel="next" href="ch04s02.html" title="4.2. Entwicklung unter FastCGI"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Kapitel 4. Entwicklerdokumentation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s10.html">Zurück</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch04s02.html">Weiter</a></td></tr></table><hr></div><div class="chapter" title="Kapitel 4. Entwicklerdokumentation"><div class="titlepage"><div><div><h2 class="title"><a name="d0e7265"></a>Kapitel 4. Entwicklerdokumentation</h2></div></div></div><div class="sect1" title="4.1. Globale Variablen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.globals"></a>4.1. Globale Variablen</h2></div></div></div><div class="sect2" title="4.1.1. Wie sehen globale Variablen in Perl aus?"><div class="titlepage"><div><div><h3 class="title"><a name="d0e7271"></a>4.1.1. Wie sehen globale Variablen in Perl aus?</h3></div></div></div><p>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.</p><p>Daraus ergeben sich folgende Formen:</p><div class="variablelist"><dl><dt><span class="term">
 | 
  
    |  |                      <code class="literal">$main::form</code>
 | 
  
    |  |                   </span></dt><dd><p>expliziter Namespace "main"</p></dd><dt><span class="term">
 | 
  
    |  |                      <code class="literal">$::form</code>
 | 
  
    |  |                   </span></dt><dd><p>impliziter Namespace "main"</p></dd><dt><span class="term">
 | 
  
    |  |                      <code class="literal">open FILE, "file.txt"</code>
 | 
  
    |  |                   </span></dt><dd><p>
 | 
  
    |  |                         <code class="varname">FILE</code> ist global</p></dd><dt><span class="term">
 | 
  
    |  |                      <code class="literal">$_</code>
 | 
  
    |  |                   </span></dt><dd><p>speziell</p></dd></dl></div><p>Im Gegensatz zu <span class="productname">PHP</span>™ gibt es kein
 | 
  
    |  |         Schlüsselwort wie "<code class="function">global</code>", mit dem man
 | 
  
    |  |         importieren kann. <code class="function">my</code>, <code class="function">our</code>
 | 
  
    |  |         und <code class="function">local</code> machen was anderes.</p><div class="variablelist"><dl><dt><span class="term">
 | 
  
    |  |                      <code class="literal">my $form</code>
 | 
  
    |  |                   </span></dt><dd><p>lexikalische Variable, gültig bis zum Ende des
 | 
  
    |  |               Scopes</p></dd><dt><span class="term">
 | 
  
    |  |                      <code class="literal">our $form</code>
 | 
  
    |  |                   </span></dt><dd><p>
 | 
  
    |  |                         <code class="varname">$form</code> referenziert ab hier
 | 
  
    |  |               <code class="varname">$PACKAGE::form</code>.</p></dd><dt><span class="term">
 | 
  
    |  |                      <code class="literal">local $form</code>
 | 
  
    |  |                   </span></dt><dd><p>Alle Änderungen an <code class="varname">$form</code> werden am Ende
 | 
  
    |  |               des scopes zurückgesetzt</p></dd></dl></div></div><div class="sect2" title="4.1.2. Warum sind globale Variablen ein Problem?"><div class="titlepage"><div><div><h3 class="title"><a name="d0e7372"></a>4.1.2. Warum sind globale Variablen ein Problem?</h3></div></div></div><p>Das erste Problem ist <span class="productname">FCGI</span>™.</p><p>
 | 
  
    |  |                <span class="productname">SQL-Ledger</span>™ hat fast alles im globalen
 | 
  
    |  |         namespace abgelegt, und erwartet, dass es da auch wiederzufinden ist.
 | 
  
    |  |         Unter <span class="productname">FCGI</span>™ müssen diese Sachen aber 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 sehr lange zum Initialisieren
 | 
  
    |  |         brauchen.</p><p>Das zweite Problem ist <code class="function">strict</code>. Unter
 | 
  
    |  |         <code class="function">strict</code> werden alle Variablen die nicht explizit
 | 
  
    |  |         mit <code class="function">Package</code>, <code class="function">my</code> oder
 | 
  
    |  |         <code class="function">our</code> angegeben werden als Tippfehler angemarkert,
 | 
  
    |  |         dies hat, seit der Einführung, u.a. schon so manche langwierige
 | 
  
    |  |         Bug-Suche verkürzt. Da globale Variablen aber implizit mit Package
 | 
  
    |  |         angegeben werden, werden die nicht geprüft, und somit kann sich
 | 
  
    |  |         schnell ein Tippfehler einschleichen.</p></div><div class="sect2" title="4.1.3. Kanonische globale Variablen"><div class="titlepage"><div><div><h3 class="title"><a name="d0e7405"></a>4.1.3. Kanonische globale Variablen</h3></div></div></div><p>Um dieses Problem im Griff zu halten gibt es einige wenige
 | 
  
    |  |         globale Variablen, die kanonisch sind, d.h. sie haben bestimmte
 | 
  
    |  |         vorgegebenen Eigenschaften, und alles andere sollte anderweitig
 | 
  
    |  |         umhergereicht werden.</p><p>Diese Variablen sind im Moment die folgenden neun:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::form</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">%::myconfig</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::locale</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::lxdebug</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::auth</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::lx_office_conf</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::instance_conf</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::dispatcher</code>
 | 
  
    |  |                   </p></li><li class="listitem"><p>
 | 
  
    |  |                      <code class="varname">$::request</code>
 | 
  
    |  |                   </p></li></ul></div><p>Damit diese nicht erneut als Müllhalde missbraucht werden, im
 | 
  
    |  |         Folgenden eine kurze Erläuterung der bestimmten vorgegebenen
 | 
  
    |  |         Eigenschaften (Konventionen):</p><div class="sect3" title="4.1.3.1. $::form"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7469"></a>4.1.3.1. $::form</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Ist ein Objekt der Klasse
 | 
  
    |  |               "<code class="classname">Form</code>"</p></li><li class="listitem"><p>Wird nach jedem Request gelöscht</p></li><li class="listitem"><p>Muss auch in Tests und Konsolenscripts vorhanden
 | 
  
    |  |               sein.</p></li><li class="listitem"><p>Enthält am Anfang eines Requests die Requestparameter vom
 | 
  
    |  |               User</p></li><li class="listitem"><p>Kann zwar intern über Requestgrenzen ein Datenbankhandle
 | 
  
    |  |               cachen, das wird aber momentan absichtlich zerstört</p></li></ul></div><p>
 | 
  
    |  |                   <code class="varname">$::form</code> wurde unter <span class="productname">SQL
 | 
  
    |  |           Ledger</span>™ als Gottobjekt für alles missbraucht. Sämtliche
 | 
  
    |  |           alten Funktionen unter SL/ mutieren <code class="varname">$::form</code>, das
 | 
  
    |  |           heißt, alles was einem lieb ist (alle Variablen die einem ans Herz
 | 
  
    |  |           gewachsen sind), sollte man vor einem Aufruf (!) von zum Beispiel
 | 
  
    |  |           <code class="function">IS->retrieve_customer()</code> in Sicherheit
 | 
  
    |  |           bringen.</p><p>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:</p><pre class="programlisting">  my $saved_numberformat    = $::myconfig{numberformat};
 | 
  
    |  |   $::myconfig{numberformat} = $numberformat;
 | 
  
    |  |   # (...) div Berechnungen
 | 
  
    |  |   $::myconfig{numberformat} = $saved_numberformat;</pre><p>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.</p><p>
 | 
  
    |  |                   <code class="varname">$::form</code> ist gleichzeitig der Standard Scope
 | 
  
    |  |           in den <span class="productname">Template::Toolkit</span>™ Templates
 | 
  
    |  |           außerhalb der Controller: der Ausdruck <code class="function">[% var
 | 
  
    |  |           %]</code> greift auf <code class="varname">$::form->{var}</code> zu.
 | 
  
    |  |           Unter Controllern ist der Standard Scope anders, da lautet der
 | 
  
    |  |           Zugriff <code class="function">[% FORM.var %]</code>. In Druckvorlagen sind
 | 
  
    |  |           normale Variablen ebenfall im <code class="varname">$::form</code> Scope, d.h.
 | 
  
    |  |           <code class="function"><%var%></code> zeigt auf
 | 
  
    |  |           <code class="varname">$::form->{var}</code>. Nochmal von der anderen Seite
 | 
  
    |  |           erläutert, innerhalb von (Web-)Templates sieht man häufiger solche
 | 
  
    |  |           Konstrukte:</p><pre class="programlisting">[%- IF business %]
 | 
  
    |  | # (... Zeig die Auswahlliste Kunden-/Lieferantentyp an)
 | 
  
    |  | [%- END %]</pre><p>Entweder wird hier dann $::form->{business} ausgewertet
 | 
  
    |  |           oder aber der Funktion
 | 
  
    |  |           <code class="function">$form->parse_html_template</code> wird explizit
 | 
  
    |  |           noch ein zusätzlicher Hash übergeben, der dann auch in den
 | 
  
    |  |           (Web-)Templates zu Verfügung steht, bspw. so:</p><pre class="programlisting">$form->parse_html_template("is/form_header", \%TMPL_VAR);</pre><p>Innerhalb von Schleifen wird
 | 
  
    |  |           <code class="varname">$::form->{TEMPLATE_ARRAYS}{var}[$index]</code>
 | 
  
    |  |           bevorzugt, wenn vorhanden. Ein Beispiel findet sich in SL/DO.pm,
 | 
  
    |  |           welches über alle Positionen eines Lieferscheins in Schleife
 | 
  
    |  |           läuft:</p><pre class="programlisting">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"};
 | 
  
    |  |   # ...
 | 
  
    |  | }</pre></div><div class="sect3" title="4.1.3.2. %::myconfig"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7553"></a>4.1.3.2. %::myconfig</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Das einzige Hash unter den globalen Variablen</p></li><li class="listitem"><p>Wird spätestens benötigt wenn auf die Datenbank
 | 
  
    |  |               zugegriffen wird</p></li><li class="listitem"><p>Wird bei jedem Request neu erstellt.</p></li><li class="listitem"><p>Enthält die Userdaten des aktuellen Logins</p></li><li class="listitem"><p>Sollte nicht ohne Filterung irgendwo gedumpt werden oder
 | 
  
    |  |               extern serialisiert werden, weil da auch der Datenbankzugriff
 | 
  
    |  |               für diesen user drinsteht.</p></li><li class="listitem"><p>Enthält unter anderem Datumsformat dateformat und
 | 
  
    |  |               Nummernformat numberformat</p></li><li class="listitem"><p>Enthält Datenbankzugriffinformationen</p></li></ul></div><p>
 | 
  
    |  |                   <code class="varname">%::myconfig</code> ist im Moment der Ersatz für
 | 
  
    |  |           ein Userobjekt. Die meisten Funktionen, die etwas anhand des
 | 
  
    |  |           aktuellen Users entscheiden müssen, befragen
 | 
  
    |  |           <code class="varname">%::myconfig</code>. Innerhalb der Anwendungen sind dies
 | 
  
    |  |           überwiegend die Daten, die sich unter <span class="guimenu">Programm</span>
 | 
  
    |  |           -> <span class="guimenuitem">Einstellungen</span> befinden, bzw. die
 | 
  
    |  |           Informationen über den Benutzer die über die
 | 
  
    |  |           Administrator-Schnittstelle eingegeben wurden.</p></div><div class="sect3" title="4.1.3.3. $::locale"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7592"></a>4.1.3.3. $::locale</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Objekt der Klasse "Locale"</p></li><li class="listitem"><p>Wird pro Request erstellt</p></li><li class="listitem"><p>Muss auch für Tests und Scripte immer verfügbar
 | 
  
    |  |               sein.</p></li><li class="listitem"><p>Cached intern über Requestgrenzen hinweg benutzte
 | 
  
    |  |               Locales</p></li></ul></div><p>Lokalisierung für den aktuellen User. Alle Übersetzungen,
 | 
  
    |  |           Zahlen- und Datumsformatierungen laufen über dieses Objekt.</p></div><div class="sect3" title="4.1.3.4. $::lxdebug"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7610"></a>4.1.3.4. $::lxdebug</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Objekt der Klasse "LXDebug"</p></li><li class="listitem"><p>Wird global gecached</p></li><li class="listitem"><p>Muss immer verfügbar sein, in nahezu allen
 | 
  
    |  |               Funktionen</p></li></ul></div><p>
 | 
  
    |  |                   <code class="varname">$::lxdebug</code> stellt Debuggingfunktionen
 | 
  
    |  |           bereit, wie "<code class="function">enter_sub</code>" und
 | 
  
    |  |           "<code class="function">leave_sub</code>", mit denen in den alten Modulen ein
 | 
  
    |  |           brauchbares Tracing gebaut ist, "<code class="function">log_time</code>", mit
 | 
  
    |  |           der man die Wallclockzeit seit Requeststart loggen kann, sowie
 | 
  
    |  |           "<code class="function">message</code>" und "<code class="function">dump</code>" mit
 | 
  
    |  |           denen man flott Informationen ins Log (tmp/kivitendo-debug.log)
 | 
  
    |  |           packen kann.</p><p>Beispielsweise so:</p><pre class="programlisting">$main::lxdebug->message(0, 'Meine Konfig:' . Dumper (%::myconfig));
 | 
  
    |  | $main::lxdebug->message(0, 'Wer bin ich? Kunde oder Lieferant:' . $form->{vc});</pre></div><div class="sect3" title="4.1.3.5. $::auth"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7647"></a>4.1.3.5. $::auth</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Objekt der Klasse "SL::Auth"</p></li><li class="listitem"><p>Wird global gecached</p></li><li class="listitem"><p>Hat eine permanente DB Verbindung zur Authdatenbank</p></li><li class="listitem"><p>Wird nach jedem Request resettet.</p></li></ul></div><p>
 | 
  
    |  |                   <code class="varname">$::auth</code> 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.</p><p>Dieses Objekt kapselt auch den gerade aktiven Mandanten.
 | 
  
    |  |           Dessen Einstellungen können über
 | 
  
    |  |           <code class="literal">$::auth->client</code> abgefragt werden; Rückgabewert
 | 
  
    |  |           ist ein Hash mit den Werten aus der Tabelle
 | 
  
    |  |           <code class="literal">auth.clients</code>.</p></div><div class="sect3" title="4.1.3.6. $::lx_office_conf"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7676"></a>4.1.3.6. $::lx_office_conf</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Objekt der Klasse
 | 
  
    |  |               "<code class="classname">SL::LxOfficeConf</code>"</p></li><li class="listitem"><p>Global gecached</p></li><li class="listitem"><p>Repräsentation der
 | 
  
    |  |               <code class="filename">config/kivitendo.conf[.default]</code>-Dateien</p></li></ul></div><p>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.</p><p>Beispielsweise ist über den Konfigurationseintrag [debug] die
 | 
  
    |  |           Debug- und Trace-Log-Datei wie folgt konfiguriert und
 | 
  
    |  |           verfügbar:</p><pre class="programlisting">[debug]
 | 
  
    |  | file_name = /tmp/kivitendo-debug.log</pre><p>ist der Key <code class="varname">file</code> im Programm als
 | 
  
    |  |           <code class="varname">$::lx_office_conf->{debug}{file}</code>
 | 
  
    |  |           erreichbar.</p><div class="warning" title="Warnung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Warning"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Warnung]" src="system/docbook-xsl/images/warning.png"></td><th align="left">Warnung</th></tr><tr><td align="left" valign="top"><p>Zugriff auf die Konfiguration erfolgt im Moment über
 | 
  
    |  |             Hashkeys, sind also nicht gegen Tippfehler abgesichert.</p></td></tr></table></div></div><div class="sect3" title="4.1.3.7. $::instance_conf"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7712"></a>4.1.3.7. $::instance_conf</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Objekt der Klasse
 | 
  
    |  |               "<code class="classname">SL::InstanceConfiguration</code>"</p></li><li class="listitem"><p>wird pro Request neu erstellt</p></li></ul></div><p>Funktioniert wie <code class="varname">$::lx_office_conf</code>,
 | 
  
    |  |           speichert aber Daten die von der Instanz abhängig sind. Eine Instanz
 | 
  
    |  |           ist hier eine Mandantendatenbank. Beispielsweise überprüft
 | 
  
    |  |           </p><pre class="programlisting">$::instance_conf->get_inventory_system eq 'perpetual'</pre><p>
 | 
  
    |  |           ob die berüchtigte Bestandsmethode zur Anwendung kommt.</p></div><div class="sect3" title="4.1.3.8. $::dispatcher"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7733"></a>4.1.3.8. $::dispatcher</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Objekt der Klasse
 | 
  
    |  |               "<code class="varname">SL::Dispatcher</code>"</p></li><li class="listitem"><p>wird pro Serverprozess erstellt.</p></li><li class="listitem"><p>enthält Informationen über die technische Verbindung zum
 | 
  
    |  |               Server</p></li></ul></div><p>Der dritte Punkt ist auch der einzige Grund warum das Objekt
 | 
  
    |  |           global gespeichert wird. Wird vermutlich irgendwann in einem anderen
 | 
  
    |  |           Objekt untergebracht.</p></div><div class="sect3" title="4.1.3.9. $::request"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7751"></a>4.1.3.9. $::request</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Hashref (evtl später Objekt)</p></li><li class="listitem"><p>Wird pro Request neu initialisiert.</p></li><li class="listitem"><p>Keine Unterstruktur garantiert.</p></li></ul></div><p>
 | 
  
    |  |                   <code class="varname">$::request</code> 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.</p><p>Vieles von dem, was im moment in <code class="varname">$::form</code>
 | 
  
    |  |           liegt, sollte eigentlich hier liegen. Die groben
 | 
  
    |  |           Differentialkriterien sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Kommt es vom User, und soll unverändert wieder an den
 | 
  
    |  |               User? Dann <code class="varname">$::form</code>, steht da eh schon</p></li><li class="listitem"><p>Sind es Daten aus der Datenbank, die nur bis zum Ende des
 | 
  
    |  |               Requests gebraucht werden? Dann
 | 
  
    |  |               <code class="varname">$::request</code>
 | 
  
    |  |                      </p></li><li class="listitem"><p>Muss ich von anderen Teilen des Programms lesend drauf
 | 
  
    |  |               zugreifen? Dann <code class="varname">$::request</code>, aber Zugriff über
 | 
  
    |  |               Wrappermethode</p></li></ul></div></div></div><div class="sect2" title="4.1.4. Ehemalige globale Variablen"><div class="titlepage"><div><div><h3 class="title"><a name="d0e7793"></a>4.1.4. Ehemalige globale Variablen</h3></div></div></div><p>Die folgenden Variablen waren einmal im Programm, und wurden
 | 
  
    |  |         entfernt.</p><div class="sect3" title="4.1.4.1. $::cgi"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7798"></a>4.1.4.1. $::cgi</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>war nötig, weil cookie Methoden nicht als
 | 
  
    |  |               Klassenfunktionen funktionieren</p></li><li class="listitem"><p>Aufruf als Klasse erzeugt Dummyobjekt was im
 | 
  
    |  |               Klassennamespace gehalten wird und über Requestgrenzen
 | 
  
    |  |               leaked</p></li><li class="listitem"><p>liegt jetzt unter
 | 
  
    |  |               <code class="varname">$::request->{cgi}</code>
 | 
  
    |  |                      </p></li></ul></div></div><div class="sect3" title="4.1.4.2. $::all_units"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7814"></a>4.1.4.2. $::all_units</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>war nötig, weil einige Funktionen in Schleifen zum Teil
 | 
  
    |  |               ein paar hundert mal pro Request eine Liste der Einheiten
 | 
  
    |  |               brauchen, und de als Parameter durch einen Riesenstack von
 | 
  
    |  |               Funktionen geschleift werden müssten.</p></li><li class="listitem"><p>Liegt jetzt unter
 | 
  
    |  |               <code class="varname">$::request->{cache}{all_units}</code>
 | 
  
    |  |                      </p></li><li class="listitem"><p>Wird nur in
 | 
  
    |  |               <code class="function">AM->retrieve_all_units()</code> gesetzt oder
 | 
  
    |  |               gelesen.</p></li></ul></div></div><div class="sect3" title="4.1.4.3. %::called_subs"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7833"></a>4.1.4.3. %::called_subs</h4></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>wurde benutzt um callsub deep recursions
 | 
  
    |  |               abzufangen.</p></li><li class="listitem"><p>Wurde entfernt, weil callsub nur einen Bruchteil der
 | 
  
    |  |               möglichen Rekursioenen darstellt, und da nie welche
 | 
  
    |  |               auftreten.</p></li><li class="listitem"><p>komplette recursion protection wurde entfernt.</p></li></ul></div></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch03s10.html">Zurück</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch04s02.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">3.10. ZUGFeRD Rechnungen </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.2. Entwicklung unter FastCGI</td></tr></table></div></body></html>
 |