kivitendo/doc/html/ch04.html @ db911739
| f8309cb7 | Moritz Bunkus | <html><head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|||
<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="Lx-Office: Installation, Konfiguration, Entwicklung"><link rel="up" href="index.html" title="Lx-Office: Installation, Konfiguration, Entwicklung"><link rel="prev" href="ch03s03.html" title="3.3. Excel-Vorlagen"><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="ch03s03.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="d0e4243"></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="d0e4249"></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="d0e4350"></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 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.</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,
|
|||
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.</p></div><div class="sect2" title="4.1.3. Kanonische globale Variablen"><div class="titlepage"><div><div><h3 class="title"><a name="d0e4383"></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, 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 als M?llhalde misbrauch werden, im Folgenden
|
|||
eine kurze Erl?uterung was man von denn erwarten kann.</p><div class="sect3" title="4.1.3.1. $::form"><div class="titlepage"><div><div><h4 class="title"><a name="d0e4447"></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 misbraucht. S?mtliche
|
|||
alten Funktionen unter SL/ mutieren <code class="varname">$::form</code>, das
|
|||
hei?t, alles was einem lieb ist, sollte man vor einem Aufruf von zum
|
|||
Beispiel <code class="function">IS->retrieve_customer()</code> in
|
|||
Sicherheit bringen.</p><p>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.</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>. Innerhalb von Schleifen wird
|
|||
<code class="varname">$::form->{TEMPLATE_ARRAYS}{var}[$index]</code>
|
|||
bevorzugt, wenn vorhanden.</p></div><div class="sect3" title="4.1.3.2. %::myconfig"><div class="titlepage"><div><div><h4 class="title"><a name="d0e4514"></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 diesenuser drinsteht.</p></li><li class="listitem"><p>Enth?lt unter anderem Listenbegrenzung vclimit,
|
|||
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>.</p></div><div class="sect3" title="4.1.3.3. $::locale"><div class="titlepage"><div><div><h4 class="title"><a name="d0e4547"></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="d0e4565"></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 packen kann.</p></div><div class="sect3" title="4.1.3.5. $::auth"><div class="titlepage"><div><div><h4 class="title"><a name="d0e4598"></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></div><div class="sect3" title="4.1.3.6. $::lx_office_conf"><div class="titlepage"><div><div><h4 class="title"><a name="d0e4619"></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/lx_office.conf[.default]</code>-Dateien</p></li></ul></div><p>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.</p><p>F?r die folgende Konfigurationsdatei:</p><pre class="programlisting">[debug]
|
|||
file = /tmp/lxoffice_debug_log.txt</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="d0e4655"></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. Prominentestes Datum ist "eur",
|
|||
die Information ob Bilanz oder Einnahmen?berschussrechnung gemacht
|
|||
wird.</p></div><div class="sect3" title="4.1.3.8. $::dispatcher"><div class="titlepage"><div><div><h4 class="title"><a name="d0e4673"></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="d0e4691"></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="d0e4733"></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="d0e4738"></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="d0e4754"></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="d0e4773"></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="ch03s03.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.3. Excel-Vorlagen </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>
|