Revision 42298d2c
Von Moritz Bunkus vor fast 6 Jahren hinzugefügt
| doc/html/ch02s05.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>2.5. Anpassung der PostgreSQL-Konfiguration</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch02.html" title="Kapitel 2. Installation und Grundkonfiguration"><link rel="prev" href="ch02s04.html" title="2.4. kivitendo-Konfigurationsdatei"><link rel="next" href="ch02s06.html" title="2.6. Webserver-Konfiguration"></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">2.5. Anpassung der PostgreSQL-Konfiguration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 2. Installation und Grundkonfiguration</th><td width="20%" align="right"> <a accesskey="n" href="ch02s06.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="2.5. Anpassung der PostgreSQL-Konfiguration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Anpassung-der-PostgreSQL-Konfiguration"></a>2.5. Anpassung der PostgreSQL-Konfiguration</h2></div></div></div><p>PostgreSQL muss auf verschiedene Weisen angepasst werden.</p><p>Dies variert je nach eingesetzter Distribution, da distributionsabhängig unterschiedliche Strategien beim Upgrade der Postgres Version eingesetzt werden.
|
||
|
Als Hinweis einige Links zu den drei Distribution (Stand Dezember 2018):</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><a class="ulink" href="https://fedoraproject.org/wiki/PostgreSQL" target="_top">Fedora (Postgres-Installation unter Fedora)</a></li><li class="listitem"><a class="ulink" href="https://help.ubuntu.com/lts/serverguide/postgresql.html" target="_top">Ubuntu (Infos für Postgres für die aktuelle LTS Version)</a></li><li class="listitem"><a class="ulink" href="https://de.opensuse.org/PostgreSQL" target="_top">OpenSuSE (aktuell nur bis Version OpenSuSE 13 verifiziert)</a></li></ul></div><div class="sect2" title="2.5.1. Zeichensätze/die Verwendung von Unicode/UTF-8"><div class="titlepage"><div><div><h3 class="title"><a name="Zeichens%C3%A4tze-die-Verwendung-von-UTF-8"></a>2.5.1. Zeichensätze/die Verwendung von Unicode/UTF-8</h3></div></div></div><p>kivitendo setzt zwingend voraus, dass die Datenbank
|
||
|
Als Hinweis einige Links zu den drei Distribution (Stand Dezember 2018):</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<a class="ulink" href="https://fedoraproject.org/wiki/PostgreSQL" target="_top">Fedora (Postgres-Installation unter Fedora)</a>
|
||
|
</p></li><li class="listitem"><p>
|
||
|
<a class="ulink" href="https://help.ubuntu.com/lts/serverguide/postgresql.html" target="_top">Ubuntu (Infos für Postgres für die aktuelle LTS Version)</a>
|
||
|
</p></li><li class="listitem"><p>
|
||
|
<a class="ulink" href="https://de.opensuse.org/PostgreSQL" target="_top">OpenSuSE (aktuell nur bis Version OpenSuSE 13 verifiziert)</a>
|
||
|
</p></li></ul></div><div class="sect2" title="2.5.1. Zeichensätze/die Verwendung von Unicode/UTF-8"><div class="titlepage"><div><div><h3 class="title"><a name="Zeichens%C3%A4tze-die-Verwendung-von-UTF-8"></a>2.5.1. Zeichensätze/die Verwendung von Unicode/UTF-8</h3></div></div></div><p>kivitendo setzt zwingend voraus, dass die Datenbank
|
||
|
Unicode/UTF-8 als Encoding einsetzt. Bei aktuellen
|
||
|
Serverinstallationen braucht man hier meist nicht einzugreifen.</p><p>Das Encoding des Datenbankservers kann überprüft werden. Ist das
|
||
|
Encoding der Datenbank "template1" "Unicode" bzw. "UTF-8", so braucht
|
||
| doc/html/ch02s06.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>2.6. Webserver-Konfiguration</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch02.html" title="Kapitel 2. Installation und Grundkonfiguration"><link rel="prev" href="ch02s05.html" title="2.5. Anpassung der PostgreSQL-Konfiguration"><link rel="next" href="ch02s07.html" title="2.7. Der Task-Server"></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">2.6. Webserver-Konfiguration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 2. Installation und Grundkonfiguration</th><td width="20%" align="right"> <a accesskey="n" href="ch02s07.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="2.6. Webserver-Konfiguration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Apache-Konfiguration"></a>2.6. Webserver-Konfiguration</h2></div></div></div><div class="sect2" title="2.6.1. Grundkonfiguration mittels CGI"><div class="titlepage"><div><div><h3 class="title"><a name="d0e1042"></a>2.6.1. Grundkonfiguration mittels CGI</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Für einen deutlichen Performanceschub sorgt die Ausführung
|
||
|
<title>2.6. Webserver-Konfiguration</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch02.html" title="Kapitel 2. Installation und Grundkonfiguration"><link rel="prev" href="ch02s05.html" title="2.5. Anpassung der PostgreSQL-Konfiguration"><link rel="next" href="ch02s07.html" title="2.7. Der Task-Server"></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">2.6. Webserver-Konfiguration</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 2. Installation und Grundkonfiguration</th><td width="20%" align="right"> <a accesskey="n" href="ch02s07.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="2.6. Webserver-Konfiguration"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Apache-Konfiguration"></a>2.6. Webserver-Konfiguration</h2></div></div></div><div class="sect2" title="2.6.1. Grundkonfiguration mittels CGI"><div class="titlepage"><div><div><h3 class="title"><a name="d0e1051"></a>2.6.1. Grundkonfiguration mittels CGI</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Für einen deutlichen Performanceschub sorgt die Ausführung
|
||
|
mittels FastCGI/FCGI. Die Einrichtung wird ausführlich im Abschnitt
|
||
|
<a class="xref" href="ch02s06.html#Apache-Konfiguration.FCGI" title="2.6.2. Konfiguration für FastCGI/FCGI">Konfiguration für FastCGI/FCGI</a> beschrieben.</p></td></tr></table></div><p>Der Zugriff auf das Programmverzeichnis muss in der Apache
|
||
|
Webserverkonfigurationsdatei <code class="literal">httpd.conf</code> eingestellt
|
||
| ... | ... | |
|
Alias /url/for/kivitendo-erp-fcgid/ /path/to/kivitendo-erp/</pre><p>Dann ist unter <code class="filename">/url/for/kivitendo-erp/</code>
|
||
|
die normale Version erreichbar, und unter
|
||
|
<code class="constant">/url/for/kivitendo-erp-fcgid/</code> die
|
||
|
FastCGI-Version.</p></div></div><div class="sect2" title="2.6.3. Authentifizierung mittels HTTP Basic Authentication"><div class="titlepage"><div><div><h3 class="title"><a name="d0e1193"></a>2.6.3. Authentifizierung mittels HTTP Basic Authentication</h3></div></div></div><p>
|
||
|
FastCGI-Version.</p></div></div><div class="sect2" title="2.6.3. Authentifizierung mittels HTTP Basic Authentication"><div class="titlepage"><div><div><h3 class="title"><a name="d0e1202"></a>2.6.3. Authentifizierung mittels HTTP Basic Authentication</h3></div></div></div><p>
|
||
|
Kivitendo unterstützt, dass Benutzerauthentifizierung über den Webserver mittels des »Basic«-HTTP-Authentifizierungs-Schema erfolgt
|
||
|
(siehe <a class="ulink" href="https://tools.ietf.org/html/rfc7617" target="_top">RFC 7617</a>). Dazu ist es aber nötig, dass der dabei vom Client
|
||
|
mitgeschickte Header <code class="constant">Authorization</code> vom Webserver an Kivitendo über die Umgebungsvariable
|
||
|
<code class="constant">HTTP_AUTHORIZATION</code> weitergegeben wird, was standardmäßig nicht der Fall ist. Für Apache kann dies über die
|
||
|
folgende Konfigurationsoption aktiviert werden:
|
||
|
</p><pre class="programlisting">SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1</pre></div><div class="sect2" title="2.6.4. Weitergehende Konfiguration"><div class="titlepage"><div><div><h3 class="title"><a name="d0e1209"></a>2.6.4. Weitergehende Konfiguration</h3></div></div></div><p>Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung
|
||
|
</p><pre class="programlisting">SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1</pre></div><div class="sect2" title="2.6.4. Weitergehende Konfiguration"><div class="titlepage"><div><div><h3 class="title"><a name="d0e1218"></a>2.6.4. Weitergehende Konfiguration</h3></div></div></div><p>Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung
|
||
|
von kivitendo nur über https-verschlüsselten Verbindungen, sowie
|
||
|
weiteren Zusatzmassnahmen, wie beispielsweise Basic Authenticate. Die
|
||
|
Konfigurationsmöglichkeiten sprengen allerdings den Rahmen dieser
|
||
| doc/html/ch02s07.html | ||
|---|---|---|
|
Links aus einem der Runlevel-Verzeichnisse heraus in den Boot-Prozess
|
||
|
einzubinden. Da das bei neueren Linux-Distributionen aber nicht
|
||
|
zwangsläufig funktioniert, werden auch Start-Scripte mitgeliefert, die
|
||
|
anstelle eines symbolischen Links verwendet werden können.</p><div class="sect3" title="2.7.3.1. SystemV-basierende Systeme (z.B. ältere Debian, ältere openSUSE, ältere Fedora)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e1283"></a>2.7.3.1. SystemV-basierende Systeme (z.B. ältere Debian, ältere
|
||
|
anstelle eines symbolischen Links verwendet werden können.</p><div class="sect3" title="2.7.3.1. SystemV-basierende Systeme (z.B. ältere Debian, ältere openSUSE, ältere Fedora)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e1292"></a>2.7.3.1. SystemV-basierende Systeme (z.B. ältere Debian, ältere
|
||
|
openSUSE, ältere Fedora)</h4></div></div></div><p>Kopieren Sie die Datei
|
||
|
<code class="filename">scripts/boot/system-v/kivitendo-task-server</code>
|
||
|
nach <code class="filename">/etc/init.d/kivitendo-task-server</code>. Passen
|
||
| ... | ... | |
|
<code class="literal">DAEMON=....</code>). Binden Sie das Script in den
|
||
|
Boot-Prozess ein. Dies ist distributionsabhängig:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Debian-basierende Systeme:</p><pre class="programlisting">update-rc.d kivitendo-task-server defaults
|
||
|
insserv kivitendo-task-server</pre></li><li class="listitem"><p>Ältere openSUSE und ältere Fedora:</p><pre class="programlisting">chkconfig --add kivitendo-task-server</pre></li></ul></div><p>Danach kann der Task-Server mit dem folgenden Befehl gestartet
|
||
|
werden:</p><pre class="programlisting">/etc/init.d/kivitendo-task-server start</pre></div><div class="sect3" title="2.7.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e1312"></a>2.7.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)</h4></div></div></div><p>Kopieren Sie die Datei
|
||
|
werden:</p><pre class="programlisting">/etc/init.d/kivitendo-task-server start</pre></div><div class="sect3" title="2.7.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e1321"></a>2.7.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)</h4></div></div></div><p>Kopieren Sie die Datei
|
||
|
<code class="filename">scripts/boot/upstart/kivitendo-task-server.conf</code>
|
||
|
nach <code class="filename">/etc/init/kivitendo-task-server.conf</code>.
|
||
|
Passen Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile
|
||
|
<code class="literal">exec ....</code>).</p><p>Danach kann der Task-Server mit dem folgenden Befehl gestartet
|
||
|
werden:</p><pre class="programlisting">service kivitendo-task-server start</pre></div><div class="sect3" title="2.7.3.3. systemd-basierende Systeme (z.B. neure openSUSE, neuere Fedora, neuere Ubuntu und neuere Debians)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e1330"></a>2.7.3.3. systemd-basierende Systeme (z.B. neure openSUSE, neuere
|
||
|
werden:</p><pre class="programlisting">service kivitendo-task-server start</pre></div><div class="sect3" title="2.7.3.3. systemd-basierende Systeme (z.B. neure openSUSE, neuere Fedora, neuere Ubuntu und neuere Debians)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e1339"></a>2.7.3.3. systemd-basierende Systeme (z.B. neure openSUSE, neuere
|
||
|
Fedora, neuere Ubuntu und neuere Debians)</h4></div></div></div><p>Kopieren Sie die Datei
|
||
|
<code class="filename">scripts/boot/systemd/kivitendo-task-server.service</code>
|
||
|
nach <code class="filename">/etc/systemd/system/</code>. Passen Sie in der
|
||
| doc/html/ch02s13.html | ||
|---|---|---|
|
Verzeichnis umbenannt werden.</p><p>Dieses Verzeichnis, wie auch das komplette
|
||
|
<code class="literal">users</code>-Verzeichnis, muss vom Webserver beschreibbar
|
||
|
sein. Dieses wurde bereits erledigt (siehe <a class="xref" href="ch02s03.html" title="2.3. Manuelle Installation des Programmpaketes">Manuelle Installation des Programmpaketes</a>), kann aber erneut
|
||
|
überprüft werden, wenn die Konvertierung nach PDF fehlschlägt.</p><div class="sect2" title="2.13.1. OpenDocument (odt) Druckvorlagen mit Makros"><div class="titlepage"><div><div><h3 class="title"><a name="d0e2374"></a>2.13.1. OpenDocument (odt) Druckvorlagen mit Makros</h3></div></div></div><p>OpenDocument Vorlagen können Makros enthalten, welche komplexere
|
||
|
überprüft werden, wenn die Konvertierung nach PDF fehlschlägt.</p><div class="sect2" title="2.13.1. OpenDocument (odt) Druckvorlagen mit Makros"><div class="titlepage"><div><div><h3 class="title"><a name="d0e2383"></a>2.13.1. OpenDocument (odt) Druckvorlagen mit Makros</h3></div></div></div><p>OpenDocument Vorlagen können Makros enthalten, welche komplexere
|
||
|
Aufgaben erfüllen.</p><p>Der Vorlagensatz "rev-odt" enthält solche Vorlagen mit <span class="bold"><strong>Schweizer Bank-Einzahlungsscheinen (BESR)</strong></span>.
|
||
|
Diese Makros haben die Aufgabe, die in den Einzahlungsscheinen
|
||
|
benötigte Referenznummer und Kodierzeile zu erzeugen. Hier eine kurze
|
||
|
Beschreibung, wie die Makros aufgebaut sind, und was bei ihrer Nutzung
|
||
|
zu beachten ist (<span class="bold"><strong>in fett sind nötige einmalige
|
||
|
Anpassungen aufgeführt</strong></span>):</p><div class="sect3" title="2.13.1.1. Bezeichnung der Vorlagen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2387"></a>2.13.1.1. Bezeichnung der Vorlagen</h4></div></div></div><p>Rechnung: invoice_besr.odt, Auftrag:
|
||
|
sales_order_besr.odt</p></div><div class="sect3" title="2.13.1.2. Vorbereitungen im Adminbereich"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2392"></a>2.13.1.2. Vorbereitungen im Adminbereich</h4></div></div></div><p>Damit beim Erstellen von Rechnungen und Aufträgen neben der
|
||
|
Anpassungen aufgeführt</strong></span>):</p><div class="sect3" title="2.13.1.1. Bezeichnung der Vorlagen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2396"></a>2.13.1.1. Bezeichnung der Vorlagen</h4></div></div></div><p>Rechnung: invoice_besr.odt, Auftrag:
|
||
|
sales_order_besr.odt</p></div><div class="sect3" title="2.13.1.2. Vorbereitungen im Adminbereich"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2401"></a>2.13.1.2. Vorbereitungen im Adminbereich</h4></div></div></div><p>Damit beim Erstellen von Rechnungen und Aufträgen neben der
|
||
|
Standardvorlage ohne Einzahlungsschein weitere Vorlagen (z.B. mit
|
||
|
Einzahlungsschein) auswählbar sind, muss für jedes Vorlagen-Suffix
|
||
|
ein Drucker eingerichtet werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Druckeradministration → Drucker hinzufügen</p></li><li class="listitem"><p>Mandant wählen</p></li><li class="listitem"><p>Druckerbeschreibung → aussagekräftiger Text: wird in der
|
||
| ... | ... | |
|
Aufträgen oder Rechnungen als odt-Datei keine Bedeutung, darf
|
||
|
aber nicht leer sein)</p></li><li class="listitem"><p>Vorlagenkürzel → besr bzw. selbst gewähltes Vorlagensuffix
|
||
|
(muss genau der Zeichenfolge entsprechen, die zwischen
|
||
|
"invoice_" bzw. "sales_order_" und ".odt" steht.)</p></li><li class="listitem"><p>speichern</p></li></ul></div></div><div class="sect3" title="2.13.1.3. Benutzereinstellungen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2416"></a>2.13.1.3. Benutzereinstellungen</h4></div></div></div><p>Wer den Ausdruck mit Einzahlungsschein als Standardeinstellung
|
||
|
"invoice_" bzw. "sales_order_" und ".odt" steht.)</p></li><li class="listitem"><p>speichern</p></li></ul></div></div><div class="sect3" title="2.13.1.3. Benutzereinstellungen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2425"></a>2.13.1.3. Benutzereinstellungen</h4></div></div></div><p>Wer den Ausdruck mit Einzahlungsschein als Standardeinstellung
|
||
|
im Rechnungs- bzw. Auftragsformular angezeigt haben möchte, kann
|
||
|
dies persönlich für sich bei den Benutzereinstellungen
|
||
|
konfigurieren:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Programm → Benutzereinstellungen → Druckoptionen</p></li><li class="listitem"><p>Standardvorlagenformat → OpenDocument/OASIS</p></li><li class="listitem"><p>Standardausgabekanal → Bildschirm</p></li><li class="listitem"><p>Standarddrucker → gewünschte Druckerbeschreibung auswählen
|
||
|
(z.B. mit Einzahlungsschein Bank xy)</p></li><li class="listitem"><p>Anzahl Kopien → leer</p></li><li class="listitem"><p>speichern</p></li></ul></div></div><div class="sect3" title="2.13.1.4. Aufbau und nötige Anpassungen der Vorlagen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2440"></a>2.13.1.4. Aufbau und nötige Anpassungen der Vorlagen</h4></div></div></div><p>In der Vorlage sind als Modul "BESR" 4 Makros gespeichert, die
|
||
|
(z.B. mit Einzahlungsschein Bank xy)</p></li><li class="listitem"><p>Anzahl Kopien → leer</p></li><li class="listitem"><p>speichern</p></li></ul></div></div><div class="sect3" title="2.13.1.4. Aufbau und nötige Anpassungen der Vorlagen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2449"></a>2.13.1.4. Aufbau und nötige Anpassungen der Vorlagen</h4></div></div></div><p>In der Vorlage sind als Modul "BESR" 4 Makros gespeichert, die
|
||
|
aus dem von kivitendo erzeugten odt-Dokument die korrekte
|
||
|
Referenznummer inklusive Prüfziffer sowie die Kodierzeile in
|
||
|
OCRB-Schrift erzeugen und am richtigen Ort ins Dokument
|
||
| ... | ... | |
|
angepasst werden.</strong></span> Dabei ist darauf zu achten, dass
|
||
|
sich die Positionen der Postkonto-Nummern der Bank, sowie der
|
||
|
Zeichenfolgen dddfr, DDDREF1, DDDREF2, 609, DDDKODIERZEILE nicht
|
||
|
verschieben.</p></li></ul></div><div class="screenshot"><div class="mediaobject"><img src="images/Einzahlungsschein_Makro.png"></div></div></div><div class="sect3" title="2.13.1.5. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer odt-Rechnung (analog bei Auftrag)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2504"></a>2.13.1.5. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer
|
||
|
verschieben.</p></li></ul></div><div class="screenshot"><div class="mediaobject"><img src="images/Einzahlungsschein_Makro.png"></div></div></div><div class="sect3" title="2.13.1.5. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer odt-Rechnung (analog bei Auftrag)"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2513"></a>2.13.1.5. Auswahl der Druckvorlage in kivitendo beim Erzeugen einer
|
||
|
odt-Rechnung (analog bei Auftrag)</h4></div></div></div><p>Im Fussbereich der Rechnungsmaske muss neben Rechnung,
|
||
|
OpenDocument/OASIS und Bildschirm die im Adminbereich erstellte
|
||
|
Druckerbeschreibung ausgewählt werden, falls diese nicht bereits bei
|
||
|
den Benutzereinstellungen als persönlicher Standard gewählt
|
||
|
wurde.</p></div><div class="sect3" title="2.13.1.6. Makroeinstellungen in LibreOffice anpassen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2509"></a>2.13.1.6. Makroeinstellungen in LibreOffice anpassen</h4></div></div></div><p>Falls beim Öffnen einer von kivitendo erzeugten odt-Rechnung
|
||
|
wurde.</p></div><div class="sect3" title="2.13.1.6. Makroeinstellungen in LibreOffice anpassen"><div class="titlepage"><div><div><h4 class="title"><a name="d0e2518"></a>2.13.1.6. Makroeinstellungen in LibreOffice anpassen</h4></div></div></div><p>Falls beim Öffnen einer von kivitendo erzeugten odt-Rechnung
|
||
|
die Meldung kommt, dass Makros aus Sicherheitsgründen nicht
|
||
|
ausgeführt werden, so müssen folgende Einstellungen in LibreOffice
|
||
|
angepasst werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Extras → Optionen → Sicherheit → Makrosicherheit</p></li><li class="listitem"><p>Sicherheitslevel auf "Mittel" einstellen (Diese
|
||
| doc/html/ch03s03.html | ||
|---|---|---|
|
<code class="varname">invdate</code>
|
||
|
</span></dt><dd><p>Rechnungsdatum</p></dd><dt><span class="term">
|
||
|
<code class="varname">invnumber</code>
|
||
|
</span></dt><dd><p>Rechnungsnummer</p></dd></dl></div></div></div><div class="sect2" title="3.3.10. Variablen in anderen Vorlagen"><div class="titlepage"><div><div><h3 class="title"><a name="dokumentenvorlagen-und-variablen.andere-vorlagen"></a>3.3.10. Variablen in anderen Vorlagen</h3></div></div></div><div class="sect3" title="3.3.10.1. Einführung"><div class="titlepage"><div><div><h4 class="title"><a name="d0e5776"></a>3.3.10.1. Einführung</h4></div></div></div><p>Die Variablen in anderen Vorlagen sind ähnlich wie in der
|
||
|
</span></dt><dd><p>Rechnungsnummer</p></dd></dl></div></div></div><div class="sect2" title="3.3.10. Variablen in anderen Vorlagen"><div class="titlepage"><div><div><h3 class="title"><a name="dokumentenvorlagen-und-variablen.andere-vorlagen"></a>3.3.10. Variablen in anderen Vorlagen</h3></div></div></div><div class="sect3" title="3.3.10.1. Einführung"><div class="titlepage"><div><div><h4 class="title"><a name="d0e5785"></a>3.3.10.1. Einführung</h4></div></div></div><p>Die Variablen in anderen Vorlagen sind ähnlich wie in der
|
||
|
Rechnung. Allerdings heißen die Variablen, die mit
|
||
|
<code class="varname">inv</code> beginnen, jetzt anders. Bei den Angeboten
|
||
|
fangen sie mit <code class="varname">quo</code> für "quotation" an:
|
||
| doc/html/ch03s07.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>3.7. Artikelklassifizierung</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch03.html" title="Kapitel 3. Features und Funktionen"><link rel="prev" href="ch03s06.html" title="3.6. Schweizer Kontenpläne"><link rel="next" href="ch03s08.html" title="3.8. Dateiverwaltung (Mini-DMS)"></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">3.7. Artikelklassifizierung</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s06.html">Zurück</a> </td><th width="60%" align="center">Kapitel 3. Features und Funktionen</th><td width="20%" align="right"> <a accesskey="n" href="ch03s08.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="3.7. Artikelklassifizierung"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="features.part_classification"></a>3.7. Artikelklassifizierung</h2></div></div></div><div class="sect2" title="3.7.1. Übersicht"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6444"></a>3.7.1. Übersicht</h3></div></div></div><p>Die Klassifizierung von Artikeln dient einer weiteren
|
||
|
<title>3.7. Artikelklassifizierung</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch03.html" title="Kapitel 3. Features und Funktionen"><link rel="prev" href="ch03s06.html" title="3.6. Schweizer Kontenpläne"><link rel="next" href="ch03s08.html" title="3.8. Dateiverwaltung (Mini-DMS)"></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">3.7. Artikelklassifizierung</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s06.html">Zurück</a> </td><th width="60%" align="center">Kapitel 3. Features und Funktionen</th><td width="20%" align="right"> <a accesskey="n" href="ch03s08.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="3.7. Artikelklassifizierung"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="features.part_classification"></a>3.7. Artikelklassifizierung</h2></div></div></div><div class="sect2" title="3.7.1. Übersicht"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6453"></a>3.7.1. Übersicht</h3></div></div></div><p>Die Klassifizierung von Artikeln dient einer weiteren
|
||
|
Gliederung, um zum Beispiel den Einkauf vom Verkauf zu trennen,
|
||
|
gekennzeichnet durch eine Beschreibung (z.B. "Einkauf") und ein Kürzel
|
||
|
(z.B. "E"). Für jede Klassifizierung besteht eine Beschreibung und
|
||
|
eine Abkürzung die normalerweise aus einem Zeichen besteht, kann aber
|
||
|
auf mehrere Zeichen erweitert werden, falls zur Unterscheidung
|
||
|
notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen.</p></div><div class="sect2" title="3.7.2. Basisklassifizierung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6449"></a>3.7.2. Basisklassifizierung</h3></div></div></div><p>Als Basisklassifizierungen gibt es</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Einkauf</p></li><li class="listitem"><p>Verkauf</p></li><li class="listitem"><p>Handelsware</p></li><li class="listitem"><p>Produktion</p></li><li class="listitem"><p>- keine - (diese wird bei einer Aktualisierung für alle
|
||
|
notwendig. Sinnvoll sind jedoch nur maximal 2 Zeichen.</p></div><div class="sect2" title="3.7.2. Basisklassifizierung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6458"></a>3.7.2. Basisklassifizierung</h3></div></div></div><p>Als Basisklassifizierungen gibt es</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Einkauf</p></li><li class="listitem"><p>Verkauf</p></li><li class="listitem"><p>Handelsware</p></li><li class="listitem"><p>Produktion</p></li><li class="listitem"><p>- keine - (diese wird bei einer Aktualisierung für alle
|
||
|
existierenden Artikel verwendet und ist gültig für Verkauf und
|
||
|
Einkauf)</p></li></ul></div><p>Es können weitere Klassifizierungen angelegt werden. So kann es
|
||
|
z.B. für separat auszuweisende Artikel folgende Klassen geben:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Lieferung (Logistik, Transport) mit Kürzel L</p></li><li class="listitem"><p>Material (Verpackungsmaterial) mit Kürzel M</p></li></ul></div></div><div class="sect2" title="3.7.3. Attribute"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6479"></a>3.7.3. Attribute</h3></div></div></div><p>Bisher haben die Klassifizierungen folgende Attribute, die auch
|
||
|
z.B. für separat auszuweisende Artikel folgende Klassen geben:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Lieferung (Logistik, Transport) mit Kürzel L</p></li><li class="listitem"><p>Material (Verpackungsmaterial) mit Kürzel M</p></li></ul></div></div><div class="sect2" title="3.7.3. Attribute"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6488"></a>3.7.3. Attribute</h3></div></div></div><p>Bisher haben die Klassifizierungen folgende Attribute, die auch
|
||
|
alle gleichzeitg gültig sein können</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>gültig für Verkauf - dieser Artikel kann im Verkauf genutzt
|
||
|
werden</p></li><li class="listitem"><p>gültig für Einkauf - dieser Artikel kann im Einkauf genutzt
|
||
|
werden</p></li><li class="listitem"><p>separat ausweisen - hierzu gibt es zur Dokumentengenerierung
|
||
| ... | ... | |
|
pro separat auszuweisenden Klassifizierungen die Variable<span class="bold"><strong>< %separate_X_subtotal%></strong></span>, wobei X das
|
||
|
Kürzel der Klassifizierung ist.</p><p>Im obigen Beispiel wäre das für Lieferkosten <span class="bold"><strong><%separate_L_subtotal%></strong></span> und für
|
||
|
Verpackungsmaterial <span class="bold"><strong>
|
||
|
<%separate_M_subtotal%></strong></span>.</p></div><div class="sect2" title="3.7.4. Zwei-Zeichen Abkürzung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6510"></a>3.7.4. Zwei-Zeichen Abkürzung</h3></div></div></div><p>Der Typ des Artikels und die Klassifizierung werden durch zwei
|
||
|
<%separate_M_subtotal%></strong></span>.</p></div><div class="sect2" title="3.7.4. Zwei-Zeichen Abkürzung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6519"></a>3.7.4. Zwei-Zeichen Abkürzung</h3></div></div></div><p>Der Typ des Artikels und die Klassifizierung werden durch zwei
|
||
|
Buchstaben dargestellt. Der erste Buchstabe ist eine Lokalisierung des
|
||
|
Artikel-Typs ('P','A','S'), deutsch 'W', 'E', und 'D' für Ware
|
||
|
Erzeugnis oder Dienstleistung und ggf. weiterer Typen.</p><p>Der zweite Buchstabe (und ggf. auch ein dritter, falls nötig)
|
||
| doc/html/ch03s08.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>3.8. Dateiverwaltung (Mini-DMS)</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch03.html" title="Kapitel 3. Features und Funktionen"><link rel="prev" href="ch03s07.html" title="3.7. Artikelklassifizierung"><link rel="next" href="ch03s09.html" title="3.9. Webshop-Api"></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">3.8. Dateiverwaltung (Mini-DMS)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s07.html">Zurück</a> </td><th width="60%" align="center">Kapitel 3. Features und Funktionen</th><td width="20%" align="right"> <a accesskey="n" href="ch03s09.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="3.8. Dateiverwaltung (Mini-DMS)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="features.file_managment"></a>3.8. Dateiverwaltung (Mini-DMS)</h2></div></div></div><div class="sect2" title="3.8.1. Übersicht"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6522"></a>3.8.1. Übersicht</h3></div></div></div><p>Parallel zum alten WebDAV gibt es ein Datei-Management-System,
|
||
|
<title>3.8. Dateiverwaltung (Mini-DMS)</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch03.html" title="Kapitel 3. Features und Funktionen"><link rel="prev" href="ch03s07.html" title="3.7. Artikelklassifizierung"><link rel="next" href="ch03s09.html" title="3.9. Webshop-Api"></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">3.8. Dateiverwaltung (Mini-DMS)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s07.html">Zurück</a> </td><th width="60%" align="center">Kapitel 3. Features und Funktionen</th><td width="20%" align="right"> <a accesskey="n" href="ch03s09.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="3.8. Dateiverwaltung (Mini-DMS)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="features.file_managment"></a>3.8. Dateiverwaltung (Mini-DMS)</h2></div></div></div><div class="sect2" title="3.8.1. Übersicht"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6531"></a>3.8.1. Übersicht</h3></div></div></div><p>Parallel zum alten WebDAV gibt es ein Datei-Management-System,
|
||
|
das Dateien verschiedenen Typs verwaltet. Dies können</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>aus ERP-Daten per LaTeX Template erzeugte
|
||
|
PDF-Dokumente,</p></li><li class="listitem"><p>zu bestimmten ERP-Daten gehörende Anhangdateien
|
||
|
unterschiedlichen Formats,</p></li><li class="listitem"><p>per Scanner eingelesene PDF-Dateien,</p></li><li class="listitem"><p>per E-Mail empfangene Dateianhänge unterschiedlichen
|
||
|
Formats,</p></li><li class="listitem"><p>sowie speziel für Artikel hochgeladene Bilder sein.</p></li></ol></div><div class="screenshot"><div class="mediaobject"><img src="images/DMS-Overview.png"></div></div></div><div class="sect2" title="3.8.2. Struktur"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6549"></a>3.8.2. Struktur</h3></div></div></div><p>Über eine vom Speichermedium unabhängige Zwischenschicht werden
|
||
|
Formats,</p></li><li class="listitem"><p>sowie speziel für Artikel hochgeladene Bilder sein.</p></li></ol></div><div class="screenshot"><div class="mediaobject"><img src="images/DMS-Overview.png"></div></div></div><div class="sect2" title="3.8.2. Struktur"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6558"></a>3.8.2. Struktur</h3></div></div></div><p>Über eine vom Speichermedium unabhängige Zwischenschicht werden
|
||
|
die Dateien und ihre Versionen in der Datenbank verwaltet. Darunter
|
||
|
können verschiedene Implementierungen (Backends) gleichzeitig
|
||
|
existieren:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Dateisystem</p></li><li class="listitem"><p>WebDAV</p></li><li class="listitem"><p>Schnittstelle zu externen
|
||
| ... | ... | |
|
für "attachment" und "image" nur die Quelle "uploaded". Für "document"
|
||
|
gibt es auf jeden Fall die Quelle "created". Die Quellen "scanner" und
|
||
|
"email" müssen derzeit in der Datenbank konfiguriert werden (siehe
|
||
|
<a class="xref" href="ch03s08.html#file_management.dbconfig" title="3.8.4.2. Datenbank-Konfigurierung">Datenbank-Konfigurierung</a>).</p></div><div class="sect2" title="3.8.3. Anwendung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6601"></a>3.8.3. Anwendung</h3></div></div></div><p>Die Daten werden bei den ERP-Objekten als extra Reiter
|
||
|
<a class="xref" href="ch03s08.html#file_management.dbconfig" title="3.8.4.2. Datenbank-Konfigurierung">Datenbank-Konfigurierung</a>).</p></div><div class="sect2" title="3.8.3. Anwendung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6610"></a>3.8.3. Anwendung</h3></div></div></div><p>Die Daten werden bei den ERP-Objekten als extra Reiter
|
||
|
dargestellt. Eine Verkaufsrechnung z.B. hat die Reiter "Dokumente" und
|
||
|
"Dateianhänge".</p><div class="screenshot"><div class="mediaobject"><img src="images/DMS-Anhaenge.png"></div></div><p>Bei den Dateianhängen wird immer nur die aktuelle Version einer
|
||
|
Datei angezeigt. Wird eine Datei mit gleichem Namen hochgeladen, so
|
||
| ... | ... | |
|
so sind diese z.B. bei Einkaufsrechnungen sichtbar:</p><div class="screenshot"><div class="mediaobject"><img src="images/DMS-Dokumente-Scanner.png"></div></div><p>Statt des Löschens wird hier die Datei zurück zur Quelle
|
||
|
verschoben. Somit kann die Datei anschließend an ein anderes
|
||
|
ERP-Objekt angehängt werden.</p><p>Derzeit sind "Titel" und "Beschreibung" noch nicht genutzt. Sie
|
||
|
sind bisher nur bei Bildern relevant.</p></div><div class="sect2" title="3.8.4. Konfigurierung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6644"></a>3.8.4. Konfigurierung</h3></div></div></div><div class="sect3" title="3.8.4.1. Mandantenkonfiguration"><div class="titlepage"><div><div><h4 class="title"><a name="file_management.clientconfig"></a>3.8.4.1. Mandantenkonfiguration</h4></div></div></div><div class="sect4" title="3.8.4.1.1. Reiter "Features""><div class="titlepage"><div><div><h5 class="title"><a name="d0e6650"></a>3.8.4.1.1. Reiter "Features"</h5></div></div></div><p>Unter dem Reiter <span class="bold"><strong>Features</strong></span>
|
||
|
sind bisher nur bei Bildern relevant.</p></div><div class="sect2" title="3.8.4. Konfigurierung"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6653"></a>3.8.4. Konfigurierung</h3></div></div></div><div class="sect3" title="3.8.4.1. Mandantenkonfiguration"><div class="titlepage"><div><div><h4 class="title"><a name="file_management.clientconfig"></a>3.8.4.1. Mandantenkonfiguration</h4></div></div></div><div class="sect4" title="3.8.4.1.1. Reiter "Features""><div class="titlepage"><div><div><h5 class="title"><a name="d0e6659"></a>3.8.4.1.1. Reiter "Features"</h5></div></div></div><p>Unter dem Reiter <span class="bold"><strong>Features</strong></span>
|
||
|
im Abschnitt Dateimanagement ist neben dem "alten" WebDAV das
|
||
|
Dateimangement generell zu- und abschaltbar, sowie die Zuordnung
|
||
|
der Dateitypen zu Backends. Die Löschbarkeit von Dateien, sowie
|
||
|
die maximale Uploadgröße sind Backend-unabhängig</p><div class="screenshot"><div class="mediaobject"><img src="images/DMS-ClientConfig.png"></div></div><p>Die einzelnen Backends sind einzeln einschaltbar.
|
||
|
Spezifische Backend-Konfigurierungen sind hier noch
|
||
|
ergänzbar.</p></div><div class="sect4" title="3.8.4.1.2. Reiter "Allgemeine Dokumentenanhänge""><div class="titlepage"><div><div><h5 class="title"><a name="d0e6666"></a>3.8.4.1.2. Reiter "Allgemeine Dokumentenanhänge"</h5></div></div></div><p>Unter dem Reiter <span class="bold"><strong>Allgemeine
|
||
|
ergänzbar.</p></div><div class="sect4" title="3.8.4.1.2. Reiter "Allgemeine Dokumentenanhänge""><div class="titlepage"><div><div><h5 class="title"><a name="d0e6675"></a>3.8.4.1.2. Reiter "Allgemeine Dokumentenanhänge"</h5></div></div></div><p>Unter dem Reiter <span class="bold"><strong>Allgemeine
|
||
|
Dokumentenanhänge</strong></span> kann für alle ERP-Dokumente (
|
||
|
Angebote, Aufträge, Lieferscheine, Rechnungen im Verkauf und
|
||
|
Einkauf ) allgemeingültige Anhänge hochgeladen werden.</p><div class="screenshot"><div class="mediaobject"><img src="images/DMS-Allgemeine-Dokumentenanhaenge.png"></div></div><p>Diese Anhänge werden beim Generieren von PDF-Dateien an die
|
||
| doc/html/ch03s09.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>3.9. Webshop-Api</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch03.html" title="Kapitel 3. Features und Funktionen"><link rel="prev" href="ch03s08.html" title="3.8. Dateiverwaltung (Mini-DMS)"><link rel="next" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"></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">3.9. Webshop-Api</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s08.html">Zurück</a> </td><th width="60%" align="center">Kapitel 3. Features und Funktionen</th><td width="20%" align="right"> <a accesskey="n" href="ch04.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="3.9. Webshop-Api"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e6700"></a>3.9. Webshop-Api</h2></div></div></div><p>Das Shopmodul bietet die Möglichkeit Onlineshopartikel und
|
||
|
<title>3.9. Webshop-Api</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch03.html" title="Kapitel 3. Features und Funktionen"><link rel="prev" href="ch03s08.html" title="3.8. Dateiverwaltung (Mini-DMS)"><link rel="next" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"></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">3.9. Webshop-Api</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s08.html">Zurück</a> </td><th width="60%" align="center">Kapitel 3. Features und Funktionen</th><td width="20%" align="right"> <a accesskey="n" href="ch04.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="3.9. Webshop-Api"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e6709"></a>3.9. Webshop-Api</h2></div></div></div><p>Das Shopmodul bietet die Möglichkeit Onlineshopartikel und
|
||
|
Onlineshopbestellungen zu verwalten und zu bearbeiten.</p><p>Es ist Multishopfähig, d.h. Artikel können mehreren oder
|
||
|
unterschiedlichen Shops zugeordnet werden. Bestellungen können aus
|
||
|
mehreren Shops geholt werden.</p><p>Zur Zeit bietet das Modul nur einen Connector zur REST-Api von
|
||
|
Shopware. Weitere Connectoren können dazu programmiert und eingerichtet
|
||
|
werden.</p><div class="sect2" title="3.9.1. Rechte für die Webshopapi"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6709"></a>3.9.1. Rechte für die Webshopapi</h3></div></div></div><p>In der Administration können folgende Rechte vergeben
|
||
|
werden</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Webshopartikel anlegen und bearbeiten</p></li><li class="listitem"><p>Shopbestellungen holen und bearbeiten</p></li><li class="listitem"><p>Shop anlegen und bearbeiten</p></li></ul></div></div><div class="sect2" title="3.9.2. Konfiguration"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6724"></a>3.9.2. Konfiguration</h3></div></div></div><p>Unter System->Webshops können Shops angelegt und konfiguriert
|
||
|
werden</p><div class="mediaobject"><img src="images/Shop_Listing.png"></div></div><div class="sect2" title="3.9.3. Webshopartikel"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6732"></a>3.9.3. Webshopartikel</h3></div></div></div><div class="sect3" title="3.9.3.1. Shopvariablenreiter in Artikelstammdaten"><div class="titlepage"><div><div><h4 class="title"><a name="d0e6735"></a>3.9.3.1. Shopvariablenreiter in Artikelstammdaten</h4></div></div></div><p>Mit dem Recht "Shopartikel anlegen und bearbeiten" und des
|
||
|
werden.</p><div class="sect2" title="3.9.1. Rechte für die Webshopapi"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6718"></a>3.9.1. Rechte für die Webshopapi</h3></div></div></div><p>In der Administration können folgende Rechte vergeben
|
||
|
werden</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Webshopartikel anlegen und bearbeiten</p></li><li class="listitem"><p>Shopbestellungen holen und bearbeiten</p></li><li class="listitem"><p>Shop anlegen und bearbeiten</p></li></ul></div></div><div class="sect2" title="3.9.2. Konfiguration"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6733"></a>3.9.2. Konfiguration</h3></div></div></div><p>Unter System->Webshops können Shops angelegt und konfiguriert
|
||
|
werden</p><div class="mediaobject"><img src="images/Shop_Listing.png"></div></div><div class="sect2" title="3.9.3. Webshopartikel"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6741"></a>3.9.3. Webshopartikel</h3></div></div></div><div class="sect3" title="3.9.3.1. Shopvariablenreiter in Artikelstammdaten"><div class="titlepage"><div><div><h4 class="title"><a name="d0e6744"></a>3.9.3.1. Shopvariablenreiter in Artikelstammdaten</h4></div></div></div><p>Mit dem Recht "Shopartikel anlegen und bearbeiten" und des
|
||
|
Markers <span class="bold"><strong>"Shopartikel" in den Basisdaten
|
||
|
</strong></span>zeigt sich der Reiter "Shopvariablen" in den
|
||
|
Artikelstammdaten. Hier können jetzt die Artikel mit
|
||
| ... | ... | |
|
Stelle können auch beliebig viele Bilder dem Shopartikel zugeordnet
|
||
|
werden. Artikelbilder gelten für alle Shops.</p><div class="mediaobject"><img src="images/Shop_Artikel.png"></div><p>Die Artikelgruppen werden direkt vom Shopsystem geholt somit
|
||
|
ist es möglich einen Artikel auch mehreren Gruppen
|
||
|
zuzuordenen</p></div><div class="sect3" title="3.9.3.2. Shopartikelliste"><div class="titlepage"><div><div><h4 class="title"><a name="d0e6748"></a>3.9.3.2. Shopartikelliste</h4></div></div></div><p>Unter dem Menu Webshop->Webshop Artikel hat man nochmal
|
||
|
zuzuordenen</p></div><div class="sect3" title="3.9.3.2. Shopartikelliste"><div class="titlepage"><div><div><h4 class="title"><a name="d0e6757"></a>3.9.3.2. Shopartikelliste</h4></div></div></div><p>Unter dem Menu Webshop->Webshop Artikel hat man nochmal
|
||
|
eine Gesamtübersicht. Von hier aus ist es möglich Artikel im Stapel
|
||
|
unter verschiedenen Kriterien <alles><nur Preis><nur
|
||
|
Bestand><Preis und Bestand> an die jeweiligen Shops
|
||
|
hochzuladen.</p><div class="mediaobject"><img src="images/Shop_Artikel_Listing.png"></div></div></div><div class="sect2" title="3.9.4. Bestellimport"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6756"></a>3.9.4. Bestellimport</h3></div></div></div><p>Unter dem Menupunkt Webshop->Webshop Import öffnet sich die
|
||
|
hochzuladen.</p><div class="mediaobject"><img src="images/Shop_Artikel_Listing.png"></div></div></div><div class="sect2" title="3.9.4. Bestellimport"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6765"></a>3.9.4. Bestellimport</h3></div></div></div><p>Unter dem Menupunkt Webshop->Webshop Import öffnet sich die
|
||
|
Bestellimportsliste. Hier ist sind Möglichkeiten gegeben Neue
|
||
|
Bestellungen vom Shop abzuholen, geholte Bestellungen im Stapel oder
|
||
|
einzeln als Auftrag zu transferieren. Die Liste kann nach
|
||
| ... | ... | |
|
auch der Grund für die Auftragssperre sein.</p></li><li class="listitem"><p>Die Buttons "Auftrag erstellen" und "Kunde mit
|
||
|
Rechnungsadresse überschreiben" zeigen sich erst, wenn ein Kunde
|
||
|
aus dem Listing ausgewählt ist.</p></li><li class="listitem"><p>Es ist aber möglich die Shopbestellung zu löschen.</p></li><li class="listitem"><p>Ist eine Bestellung schon übernommen, zeigen sich an dieser
|
||
|
Stelle, die dazugehörigen Belegverknüpfungen.</p></li></ul></div></div><div class="sect2" title="3.9.5. Mapping der Daten"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6809"></a>3.9.5. Mapping der Daten</h3></div></div></div><p>Das Mapping der kivitendo Daten mit den Shopdaten geschieht in
|
||
|
Stelle, die dazugehörigen Belegverknüpfungen.</p></li></ul></div></div><div class="sect2" title="3.9.5. Mapping der Daten"><div class="titlepage"><div><div><h3 class="title"><a name="d0e6818"></a>3.9.5. Mapping der Daten</h3></div></div></div><p>Das Mapping der kivitendo Daten mit den Shopdaten geschieht in
|
||
|
der Datei SL/ShopConnector/<SHOPCONNECTORNAME>.pm
|
||
|
z.B.:SL/ShopConnector/Shopware.pm</p><p>In dieser Datei gibt es einen Bereich wo die Bestellpostionen,
|
||
|
die Bestellkopfdaten und die Artikeldaten gemapt werden. In dieser
|
||
| doc/html/ch04.html | ||
|---|---|---|
|
<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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="index.html" title="kivitendo 3.5.3: Installation, Konfiguration, Entwicklung"><link rel="prev" href="ch03s09.html" title="3.9. Webshop-Api"><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="ch03s09.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="d0e6819"></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="d0e6825"></a>4.1.1. Wie sehen globale Variablen in Perl aus?</h3></div></div></div><p>Globale Variablen liegen in einem speziellen namespace namens
|
||
|
<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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="index.html" title="kivitendo 3.5.3: Installation, Konfiguration, Entwicklung"><link rel="prev" href="ch03s09.html" title="3.9. Webshop-Api"><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="ch03s09.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="d0e6828"></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="d0e6834"></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="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="d0e6926"></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>
|
||
|
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="d0e6935"></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
|
||
| ... | ... | |
|
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="d0e6959"></a>4.1.3. Kanonische globale Variablen</h3></div></div></div><p>Um dieses Problem im Griff zu halten gibt es einige wenige
|
||
|
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="d0e6968"></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">$::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="d0e7023"></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
|
||
|
Eigenschaften (Konventionen):</p><div class="sect3" title="4.1.3.1. $::form"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7032"></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
|
||
| ... | ... | |
|
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="d0e7107"></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
|
||
|
}</pre></div><div class="sect3" title="4.1.3.2. %::myconfig"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7116"></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
|
||
| ... | ... | |
|
ü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="d0e7146"></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
|
||
|
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="d0e7155"></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="d0e7164"></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
|
||
|
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="d0e7173"></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">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="d0e7201"></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>
|
||
|
$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="d0e7210"></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
|
||
| ... | ... | |
|
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="d0e7230"></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="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="d0e7239"></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
|
||
| ... | ... | |
|
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="d0e7266"></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
|
||
|
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="d0e7275"></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="d0e7287"></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
|
||
|
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="d0e7296"></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="d0e7305"></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>
|
||
|
Objekt untergebracht.</p></div><div class="sect3" title="4.1.3.9. $::request"><div class="titlepage"><div><div><h4 class="title"><a name="d0e7314"></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
|
||
| ... | ... | |
|
<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="d0e7347"></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="d0e7352"></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
|
||
|
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="d0e7356"></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="d0e7361"></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="d0e7368"></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
|
||
|
</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="d0e7377"></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="d0e7387"></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
|
||
|
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="d0e7396"></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="ch03s09.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.9. Webshop-Api </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>
|
||
| doc/html/ch04s02.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.2. Entwicklung unter FastCGI</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="next" href="ch04s03.html" title="4.3. SQL-Upgradedateien"></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">4.2. Entwicklung unter FastCGI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s03.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.2. Entwicklung unter FastCGI"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.fcgi"></a>4.2. Entwicklung unter FastCGI</h2></div></div></div><div class="sect2" title="4.2.1. Allgemeines"><div class="titlepage"><div><div><h3 class="title"><a name="devel.fcgi.general"></a>4.2.1. Allgemeines</h3></div></div></div><p>Wenn Änderungen in der Konfiguration von kivitendo gemacht
|
||
|
<title>4.2. Entwicklung unter FastCGI</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="next" href="ch04s03.html" title="4.3. Programmatische API-Aufrufe"></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">4.2. Entwicklung unter FastCGI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s03.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.2. Entwicklung unter FastCGI"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.fcgi"></a>4.2. Entwicklung unter FastCGI</h2></div></div></div><div class="sect2" title="4.2.1. Allgemeines"><div class="titlepage"><div><div><h3 class="title"><a name="devel.fcgi.general"></a>4.2.1. Allgemeines</h3></div></div></div><p>Wenn Änderungen in der Konfiguration von kivitendo gemacht
|
||
|
werden, muss der Webserver neu gestartet werden.</p><p>Bei der Entwicklung für FastCGI ist auf ein paar Fallstricke zu
|
||
|
achten. Dadurch, dass das Programm in einer Endlosschleife läuft,
|
||
|
müssen folgende Aspekte beachtet werden.</p></div><div class="sect2" title="4.2.2. Programmende und Ausnahmen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.fcgi.exiting"></a>4.2.2. Programmende und Ausnahmen</h3></div></div></div><p>Betrifft die Funktionen <code class="function">warn</code>,
|
||
| ... | ... | |
|
4GB Arbeitsspeicher und Ubuntu 9.10 eine halbe Sekunde. In der 2.6.0
|
||
|
sind es je nach Menge der definierten Variablen 1-2s. Ab der
|
||
|
Moose/Rose::DB Version sind es 5-6s.</p><p>Mit FastCGI ist die neuste Version auf 0,26 Sekunden selbst in
|
||
|
den kritischen Pfaden, unter 0,15 sonst.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s03.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">Kapitel 4. Entwicklerdokumentation </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.3. SQL-Upgradedateien</td></tr></table></div></body></html>
|
||
|
den kritischen Pfaden, unter 0,15 sonst.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s03.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">Kapitel 4. Entwicklerdokumentation </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.3. Programmatische API-Aufrufe</td></tr></table></div></body></html>
|
||
| doc/html/ch04s03.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.3. SQL-Upgradedateien</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s02.html" title="4.2. Entwicklung unter FastCGI"><link rel="next" href="ch04s04.html" title="4.4. Translations and languages"></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">4.3. SQL-Upgradedateien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s02.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s04.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.3. SQL-Upgradedateien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="db-upgrade-files"></a>4.3. SQL-Upgradedateien</h2></div></div></div><div class="sect2" title="4.3.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.introduction"></a>4.3.1. Einführung</h3></div></div></div><p>Datenbankupgrades werden über einzelne Upgrade-Scripte
|
||
|
gesteuert, die sich im Verzeichnis
|
||
|
<code class="filename">sql/Pg-upgrade2</code> befinden. In diesem Verzeichnis
|
||
|
muss pro Datenbankupgrade eine Datei existieren, die neben den
|
||
|
eigentlich auszuführenden SQL- oder Perl-Befehlen einige
|
||
|
Kontrollinformationen enthält.</p><p>Kontrollinformationen definieren Abhängigkeiten und Prioritäten,
|
||
|
sodass Datenbankscripte zwar in einer sicheren Reihenfolge ausgeführt
|
||
|
werden (z.B. darf ein <code class="literal">ALTER TABLE</code> erst ausgeführt
|
||
|
werden, wenn die Tabelle mit <code class="literal">CREATE TABLE</code> angelegt
|
||
|
wurde), diese Reihenfolge aber so flexibel ist, dass man keine
|
||
|
Versionsnummern braucht.</p><p>kivitendo merkt sich dabei, welches der Upgradescripte in
|
||
|
<code class="filename">sql/Pg-upgrade2</code> bereits durchgeführt wurde und
|
||
|
führt diese nicht erneut aus. Dazu dient die Tabelle
|
||
|
"<code class="literal">schema_info</code>", die bei der Anmeldung automatisch
|
||
|
angelegt wird.</p></div><div class="sect2" title="4.3.2. Format der Kontrollinformationen"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.format"></a>4.3.2. Format der Kontrollinformationen</h3></div></div></div><p>Die Kontrollinformationen sollten sich am Anfang der jeweiligen
|
||
|
Upgradedatei befinden. Jede Zeile, die Kontrollinformationen enthält,
|
||
|
hat dabei das folgende Format:</p><p>Für SQL-Upgradedateien:</p><pre class="programlisting">-- @key: value</pre><p>Für Perl-Upgradedateien:</p><pre class="programlisting"># @key: value</pre><p>Leerzeichen vor "<code class="varname">value</code>" werden
|
||
|
entfernt.</p><p>Die folgenden Schlüsselworte werden verarbeitet:</p><div class="variablelist"><dl><dt><span class="term">
|
||
|
<code class="varname">tag</code>
|
||
|
</span></dt><dd><p>Wird zwingend benötigt. Dies ist der "Name" des Upgrades.
|
||
|
Dieser "tag" kann von anderen Kontrolldateien in ihren
|
||
|
Abhängigkeiten verwendet werden (Schlüsselwort
|
||
|
"<code class="varname">depends</code>"). Der "tag" ist auch der Name, der
|
||
|
in der Datenbank eingetragen wird.</p><p>Normalerweise sollte die Kontrolldatei genau so heißen wie
|
||
|
der "tag", nur mit der Endung ".sql" bzw. "pl".</p><p>Ein Tag darf nur aus alphanumerischen Zeichen sowie den
|
||
|
Zeichen _ - ( ) bestehen. Insbesondere sind Leerzeichen nicht
|
||
|
erlaubt und sollten stattdessen mit Unterstrichen ersetzt
|
||
|
werden.</p></dd><dt><span class="term">
|
||
|
<code class="varname">charset</code>
|
||
|
</span></dt><dd><p>Empfohlen. Gibt den Zeichensatz an, in dem das Script
|
||
|
geschrieben wurde, z.B. "<code class="literal">UTF-8</code>". Aus
|
||
|
Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei
|
||
|
Abwesenheit des Tags für SQL-Upgradedateien der Zeichensatz
|
||
|
"<code class="literal">ISO-8859-15</code>" angenommen. Perl-Upgradescripte
|
||
|
hingegen müssen immer in UTF-8 encodiert sein und sollten
|
||
|
demnach auch ein "<code class="literal">use utf8;</code>"
|
||
|
enthalten.</p></dd><dt><span class="term">
|
||
|
<code class="varname">description</code>
|
||
|
</span></dt><dd><p>Benötigt. Eine Beschreibung, was in diesem Update
|
||
|
passiert. Diese wird dem Benutzer beim eigentlichen
|
||
|
Datenbankupdate angezeigt. Während der Tag in Englisch gehalten
|
||
|
sein sollte, sollte die Beschreibung auf Deutsch
|
||
|
erfolgen.</p></dd><dt><span class="term">
|
||
|
<code class="varname">depends</code>
|
||
|
</span></dt><dd><p>Optional. Eine mit Leerzeichen getrennte Liste von "tags",
|
||
|
von denen dieses Upgradescript abhängt. kivitendo stellt sicher,
|
||
|
dass die in dieser Liste aufgeführten Scripte bereits
|
||
|
durchgeführt wurden, bevor dieses Script ausgeführt wird.</p><p>Abhängigkeiten werden rekursiv betrachtet. Wenn also ein
|
||
|
Script "b" existiert, das von Änderungen in "a" abhängt, und
|
||
|
eine neue Kontrolldatei für "c" erstellt wird, die von
|
||
|
Änderungen in "a" und "b" abhängt, so genügt es, in "c" nur den
|
||
|
Tag "b" als Abhängigkeit zu definieren.</p><p>Es ist nicht erlaubt, sich selbst referenzierende
|
||
|
Abhängigkeiten zu definieren (z.B. "a" -> "b", "b" -> "c"
|
||
|
und "c" -> "a").</p></dd><dt><span class="term">
|
||
|
<code class="varname">priority</code>
|
||
|
</span></dt><dd><p>Optional. Ein Zahlenwert, der die Reihenfolge bestimmt, in
|
||
|
der Scripte ausgeführt werden, die die gleichen
|
||
|
Abhängigkeitstiefen besitzen. Fehlt dieser Parameter, so wird
|
||
|
der Wert 1000 benutzt.</p><p>Dies ist reine Kosmetik. Für echte Reihenfolgen muss
|
||
|
"depends" benutzt werden. kivitendo sortiert die auszuführenden
|
||
|
Scripte zuerst nach der Abhängigkeitstiefe (wenn "z" von "y"
|
||
|
abhängt und "y" von "x", so hat "z" eine Abhängigkeitstiefe von
|
||
|
2, "y" von 1 und "x" von 0. "x" würde hier zuerst ausgeführt,
|
||
|
dann "y", dann "z"), dann nach der Priorität und bei gleicher
|
||
|
Priorität alphabetisch nach dem "tag".</p></dd><dt><span class="term">
|
||
|
<code class="varname">ignore</code>
|
||
|
</span></dt><dd><p>Optional. Falls der Wert auf 1 (true) steht, wird das
|
||
|
Skript bei der Anmeldung ignoriert und entsprechend nicht
|
||
|
ausgeführt.</p></dd></dl></div></div><div class="sect2" title="4.3.3. Format von in Perl geschriebenen Datenbankupgradescripten"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.format-perl-files"></a>4.3.3. Format von in Perl geschriebenen
|
||
|
Datenbankupgradescripten</h3></div></div></div><p>In Perl geschriebene Datenbankscripte werden nicht einfach so
|
||
|
ausgeführt sondern müssen sich an gewisse Konventionen halten. Dafür
|
||
|
bekommen sie aber auch einige Komfortfunktionen bereitgestellt.</p><p>Ein Upgradescript stellt dabei eine vollständige Objektklasse
|
||
|
dar, die vom Elternobjekt "<code class="literal">SL::DBUpgrade2::Base</code>"
|
||
|
erben und eine Funktion namens "<code class="literal">run</code>" zur Verfügung
|
||
|
stellen muss. Das Script wird ausgeführt, indem eine Instanz dieser
|
||
|
Klasse erzeugt und darauf die erwähnte "<code class="literal">run</code>"
|
||
|
aufgerufen wird.</p><p>Zu beachten ist, dass sich der Paketname der Datei aus dem Wert
|
||
|
für "<code class="literal">@tag</code>" ableitet. Dabei werden alle Zeichen, die
|
||
|
in Paketnamen ungültig wären (gerade Bindestriche), durch Unterstriche
|
||
|
ersetzt. Insgesamt sieht der Paketname wie folgt aus:
|
||
|
"<code class="literal">SL::DBUpgrade2::tag</code>".</p><p>Welche Komfortfunktionen zur Verfügung stehen, erfahren Sie in
|
||
|
der Perl-Dokumentation zum oben genannten Modul; aufzurufen mit
|
||
|
"<span class="command"><strong>perldoc SL/DBUpgrade2/Base.pm</strong></span>".</p><p>Ein Mindestgerüst eines gültigen Perl-Upgradescriptes sieht wie
|
||
|
folgt aus:</p><pre class="programlisting"># @tag: beispiel-upgrade-file42
|
||
|
# @description: Ein schönes Beispielscript
|
||
|
# @depends: release_3_1_0
|
||
|
package SL::DBUpgrade2::beispiel_upgrade_file42;
|
||
|
|
||
|
use strict;
|
||
|
use utf8;
|
||
|
|
||
|
use parent qw(SL::DBUpgrade2::Base);
|
||
|
|
||
|
sub run {
|
||
|
my ($self) = @_;
|
||
|
|
||
|
# hier Aktionen ausführen
|
||
|
|
||
|
return 1;
|
||
|
}
|
||
|
|
||
|
1;
|
||
|
</pre></div><div class="sect2" title="4.3.4. Hilfsscript dbupgrade2_tool.pl"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.dbupgrade-tool"></a>4.3.4. Hilfsscript dbupgrade2_tool.pl</h3></div></div></div><p>Um die Arbeit mit den Abhängigkeiten etwas zu erleichtern,
|
||
|
existiert ein Hilfsscript namens
|
||
|
"<code class="filename">scripts/dbupgrade2_tool.pl</code>". Es muss aus dem
|
||
|
kivitendo-ERP-Basisverzeichnis heraus aufgerufen werden. Dieses Tool
|
||
|
liest alle Datenbankupgradescripte aus dem Verzeichnis
|
||
|
<code class="filename">sql/Pg-upgrade2</code> aus. Es benutzt dafür die
|
||
|
gleichen Methoden wie kivitendo selber, sodass alle Fehlersituationen
|
||
|
von der Kommandozeile überprüft werden können.</p><p>Wird dem Script kein weiterer Parameter übergeben, so wird nur
|
||
|
eine Überprüfung der Felder und Abhängigkeiten vorgenommen. Man kann
|
||
|
sich aber auch Informationen auf verschiedene Art ausgeben
|
||
|
lassen:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Listenform: "<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--list</strong></span>"</p><p>Gibt eine Liste aller Scripte aus. Die Liste ist in der
|
||
|
Reihenfolge sortiert, in der kivitendo die Scripte ausführen
|
||
|
würde. Es werden neben der Listenposition der Tag, die
|
||
|
Abhängigkeitstiefe und die Priorität ausgegeben.</p></li><li class="listitem"><p>Baumform: "<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--tree</strong></span>"</p><p>Listet alle Tags in Baumform basierend auf den
|
||
|
Abhängigkeiten auf. Die "Wurzelknoten" sind dabei die Scripte, von
|
||
|
denen keine anderen abhängen. Die Unterknoten sind Scripte, die
|
||
|
beim übergeordneten Script als Abhängigkeit eingetragen
|
||
|
sind.</p></li><li class="listitem"><p><a name="db-upgrade-files.dbupgrade-tool.reverse-tree"></a>Umgekehrte Baumform: "<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--rtree</strong></span>"</p><p>Listet alle Tags in Baumform basierend auf den
|
||
|
Abhängigkeiten auf. Die "Wurzelknoten" sind dabei die Scripte mit
|
||
|
der geringsten Abhängigkeitstiefe. Die Unterknoten sind Scripte,
|
||
|
die das übergeordnete Script als Abhängigkeit eingetragen
|
||
|
haben.</p></li><li class="listitem"><p>Baumform mit Postscriptausgabe:
|
||
|
"<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--graphviz</strong></span>"</p><p>Benötigt das Tool "<span class="command"><strong>graphviz</strong></span>", um mit
|
||
|
seiner Hilfe die <a class="link" href="ch04s03.html#db-upgrade-files.dbupgrade-tool.reverse-tree">umgekehrte
|
||
|
Baumform</a> in eine Postscriptdatei namens
|
||
|
"<code class="filename">db_dependencies.ps</code>" auszugeben. Dies ist
|
||
|
vermutlich die übersichtlichste Form, weil hierbei jeder Knoten
|
||
|
nur einmal ausgegeben wird. Bei den Textmodusbaumformen hingegen
|
||
|
können Knoten und all ihre Abhängigkeiten mehrfach ausgegeben
|
||
|
werden.</p></li><li class="listitem"><p>Scripte, von denen kein anderes Script abhängt:
|
||
|
"<span class="command"><strong>./scripts/dbupgrade2_tool.pl --nodeps</strong></span>"</p><p>Listet die Tags aller Scripte auf, von denen keine anderen
|
||
|
Scripte abhängen.</p></li></ul></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s02.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s04.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.2. Entwicklung unter FastCGI </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.4. Translations and languages</td></tr></table></div></body></html>
|
||
|
<title>4.3. Programmatische API-Aufrufe</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s02.html" title="4.2. Entwicklung unter FastCGI"><link rel="next" href="ch04s04.html" title="4.4. SQL-Upgradedateien"></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">4.3. Programmatische API-Aufrufe</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s02.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s04.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.3. Programmatische API-Aufrufe"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="dev-programmatic-api-calls"></a>4.3. Programmatische API-Aufrufe</h2></div></div></div><div class="sect2" title="4.3.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="dev-programmatic-api-calls.introduction"></a>4.3.1. Einführung</h3></div></div></div><p>
|
||
|
Es ist möglich, Funktionen in kivitendo programmatisch aus anderen Programmen aufzurufen. Dazu ist nötig, dass
|
||
|
Authentifizierungsinformationen in jedem Aufruf mitgegeben werden. Dafür gibt es zwei Methoden: die HTTP-»Basic«-Authentifizierung
|
||
|
oder die Übergabe als spziell benannte GET-Parameter. Neben den Authentifizierungsinformationen muss auch der zu verwendende Mandant
|
||
|
übergeben werden.
|
||
|
</p></div><div class="sect2" title="4.3.2. Wahl des Mandanten"><div class="titlepage"><div><div><h3 class="title"><a name="dev-programmatic-api-calls.client_selection"></a>4.3.2. Wahl des Mandanten</h3></div></div></div><p>
|
||
|
Der zu verwendende Mandant kann als Parameter <code class="varname">{AUTH}client_id</code> mit jedem Request mitgeschickt werden. Der Wert
|
||
|
muss dabei die Datenbank-ID des Mandanten sein. kivitendo prüft, ob der Account, der über die Authentifizierungsinformationen
|
||
|
übergeben wurde, Zugriff auf den angegebenen Mandanten hat.
|
||
|
</p><p>
|
||
|
Wird in einem Request kein Mandant mitgegeben, so wird derjenige Mandant genommen, wer als Standardmandant markiert wurde. Gibt es
|
||
|
keinen solchen, kommt es zu einer Fehlermeldung.
|
||
|
</p></div><div class="sect2" title="4.3.3. HTTP-»Basic«-Authentifizierung"><div class="titlepage"><div><div><h3 class="title"><a name="dev-programmatic-api-calls.http_basic_authentication"></a>4.3.3. HTTP-»Basic«-Authentifizierung</h3></div></div></div><p>
|
||
|
Für diese Methode muss jedem Request der bekannte HTTP-Header <code class="constant">Authorization</code> mitgeschickt werden (siehe <a class="ulink" href="https://tools.ietf.org/html/rfc7617" target="_top">RFC 7617</a>). Unterstützt wird ausschließlich die »Basic«-Methode. Loginname und
|
||
|
Passwort werden bei dieser Methode durch einen Doppelpunkt getrennt und Base64-encodiert im genannten HTTP-Header übertragen.
|
||
|
</p><p>
|
||
|
Diese Informationen müssen einen vorhandenen Account benennen. kivitendo prüft genau wie bei Benutzung über den Webbrowser, ob
|
||
|
dieser Account Zugriff auf den Mandanten sowie auf die angeforderte Funktion hat.
|
||
|
</p><p>
|
||
|
Da die Logininformationen im Klartext im Request stehen, sollte der Zugriff auf kivitendo ausschließlich über HTTPS verschlüsselt
|
||
|
erfolgen.
|
||
|
</p></div><div class="sect2" title="4.3.4. Authentifizierung mit Parametern"><div class="titlepage"><div><div><h3 class="title"><a name="dev-programmatic-api-calls.authentication_via_parameters"></a>4.3.4. Authentifizierung mit Parametern</h3></div></div></div><p>
|
||
|
Für diese Methode müssen jedem Request zwei Parameter mitgegeben werden: <code class="varname">{AUTH}login</code> und
|
||
|
<code class="varname">{AUTH}password</code>. Diese Informationen müssen einen vorhandenen Account benennen. kivitendo prüft genau wie bei
|
||
|
Benutzung über den Webbrowser, ob dieser Account Zugriff auf den Mandanten sowie auf die angeforderte Funktion hat.
|
||
|
</p><p>
|
||
|
Da die Logininformationen im Klartext im Request stehen, sollte der Zugriff auf kivitendo ausschließlich über HTTPS verschlüsselt
|
||
|
erfolgen.
|
||
|
</p><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>
|
||
|
Die Verwendung dieser Methode ist veraltet. Statt dessen sollte die oben erwähnte HTTP-»Basic«-Authentifizierung verwendet werden.
|
||
|
</p></td></tr></table></div></div><div class="sect2" title="4.3.5. Beispiele"><div class="titlepage"><div><div><h3 class="title"><a name="dev-programmatic-api-calls.examples"></a>4.3.5. Beispiele</h3></div></div></div><p>
|
||
|
Das folgende Beispiel nutzt das Kommandozeilenprogramm »curl« und ruft die Funktion auf, die eine vorhandene Telefonnummer in den
|
||
|
Ansprechpersonen sucht und dazu Informationen zurückliefert. Dabei wird die HTTP-»Basic«-Authentifizierung genutzt.
|
||
|
</p><pre class="programlisting">$ curl --silent --user 'jdoe:SecretPassword!' \
|
||
|
'https://…/controller.pl?action=PhoneNumber/look_up&number=053147110815'</pre></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s02.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s04.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.2. Entwicklung unter FastCGI </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.4. SQL-Upgradedateien</td></tr></table></div></body></html>
|
||
| doc/html/ch04s04.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.4. Translations and languages</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s03.html" title="4.3. SQL-Upgradedateien"><link rel="next" href="ch04s05.html" title="4.5. Die kivitendo-Test-Suite"></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">4.4. Translations and languages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.4. Translations and languages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="translations-languages"></a>4.4. Translations and languages</h2></div></div></div><div class="sect2" title="4.4.1. Introduction"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.introduction"></a>4.4.1. Introduction</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Dieser Abschnitt ist in Englisch geschrieben, um
|
||
|
internationalen Übersetzern die Arbeit zu erleichtern.</p></td></tr></table></div><p>This section describes how localization packages in kivitendo
|
||
|
are built. Currently the only language fully supported is German, and
|
||
|
since most of the internal messages are held in English the English
|
||
|
version is usable too.</p></div><div class="sect2" title="4.4.2. Character set"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.character-set"></a>4.4.2. Character set</h3></div></div></div><p>All files included in a language pack must use UTF-8 as their
|
||
|
encoding.</p></div><div class="sect2" title="4.4.3. File structure"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.file-structure"></a>4.4.3. File structure</h3></div></div></div><p>The structure of locales in kivitendo is:</p><pre class="programlisting">kivitendo/locale/<langcode>/</pre><p>where <langcode> stands for an abbreviation of the
|
||
|
language package. The builtin packages use two letter <a class="ulink" href="http://en.wikipedia.org/wiki/ISO_639-1" target="_top">ISO 639-1</a> codes,
|
||
|
but the actual name is not relevant for the program and can easily be
|
||
|
extended to <a class="ulink" href="http://en.wikipedia.org/wiki/IETF_language_tag" target="_top">IETF language
|
||
|
tags</a> (i.e. "en_GB"). In fact the original language packages
|
||
|
from SQL Ledger are named in this way.</p><p>In such a language directory the following files are
|
||
|
recognized:</p><div class="variablelist"><dl><dt><span class="term">LANGUAGE</span></dt><dd><p>This file is mandatory.</p><p>The <code class="filename">LANGUAGE</code> file contains the self
|
||
|
descripted name of the language. It should contain a native
|
||
|
representation first, and in parenthesis an english translation
|
||
|
after that. Example:</p><pre class="programlisting">Deutsch (German)</pre></dd><dt><span class="term">all</span></dt><dd><p>This file is mandatory.</p><p>The central translation file. It is essentially an inline
|
||
|
Perl script autogenerated by <span class="command"><strong>locales.pl</strong></span>. To
|
||
|
generate it, generate the directory and the two files mentioned
|
||
|
above, and execute the following command:</p><pre class="programlisting">scripts/locales.pl <langcode></pre><p>Otherwise you can simply copy one of the other languages.
|
||
|
You will be told how many are missing like this:</p><pre class="programlisting">$ scripts/locales.pl en
|
||
|
English - 0.6% - 2015/2028 missing</pre><p>A file named "<code class="filename">missing</code>" will be
|
||
|
generated and can be edited. You can also edit the
|
||
|
"<code class="filename">all</code>" file directly. Edit everything you
|
||
|
like to fit the target language and execute
|
||
|
<span class="command"><strong>locales.pl</strong></span> again. See how the missing words
|
||
|
get fewer.</p></dd><dt><span class="term">Num2text</span></dt><dd><p>Legacy code from SQL Ledger. It provides a means for
|
||
|
numbers to be converted into natural language, like
|
||
|
<code class="literal">1523 => one thousand five hundred twenty
|
||
|
three</code>. If you want to provide it, it must be inlinable
|
||
|
Perl code which provides a <code class="function">num2text</code> sub. If
|
||
|
an <code class="function">init</code> sub exists it will be executed
|
||
|
first.</p><p>Only used in the check and receipt printing module.</p></dd><dt><span class="term">special_chars</span></dt><dd><p>kivitendo comes with a lot of interfaces to different
|
||
|
formats, some of which are rather picky with their accepted
|
||
|
charset. The <code class="filename">special_chars</code> file contains a
|
||
|
listing of chars not suited for different file format and
|
||
|
provides substitutions. It is written in "Simple Ini" style,
|
||
|
containing a block for every file format.</p><p>First entry should be the order of substitution for
|
||
|
entries as a whitespace separated list. All entries are
|
||
|
interpolated, so <code class="literal">\n</code>, <code class="literal">\x20</code>
|
||
|
and <code class="literal">\\</code> all work.</p><p>After that every entry is a special char that should be
|
||
|
translated when writing text into such a file.</p><p>Example:</p><pre class="programlisting">[Template/XML]
|
||
|
order=& < > \n
|
||
|
&=&amp;
|
||
|
<=&lt;
|
||
|
>=&gt;
|
||
|
\n=<br></pre><p>Note the importance of the order in this example.
|
||
|
Substituting < and > befor & would lead to $gt; become
|
||
|
&amp;gt;</p><p>For a list of valid formats, see the German
|
||
|
<code class="filename">special_chars</code> entry. As of this writing the
|
||
|
following are recognized:</p><pre class="programlisting">HTML
|
||
|
URL@HTML
|
||
|
Template/HTML
|
||
|
Template/XML
|
||
|
Template/LaTeX
|
||
|
Template/OpenDocument
|
||
|
filenames</pre><p>The last of which is very machine dependant. Remember that
|
||
|
a lot of characters are forbidden by some filesystems, for
|
||
|
example MS Windows doesn't like ':' in its files where Linux
|
||
|
doesn't mind that. If you want the files created with your
|
||
|
language pack to be portable, find all chars that could cause
|
||
|
trouble.</p></dd><dt><span class="term">missing</span></dt><dd><p>This file is not a part of the language package
|
||
|
itself.</p><p>This is a file generated by
|
||
|
<span class="command"><strong>scripts/locales.pl</strong></span> while processing your
|
||
|
locales. It's only to have the missing entries singled out and
|
||
|
does not belong to a language package.</p></dd><dt><span class="term">lost</span></dt><dd><p>This file is not a part of the language package
|
||
|
itself.</p><p>Another file generated by
|
||
|
<span class="command"><strong>scripts/locales.pl</strong></span>. If for any reason a
|
||
|
translation does not appear anymore and can be deleted, it gets
|
||
|
moved here. The last 50 or so entries deleted are saved here in
|
||
|
case you made a typo, so that you don't have to translate
|
||
|
everything again. If a tranlsation is missing, the lost file is
|
||
|
checked first. If you maintain a language package, you might
|
||
|
want to keep this safe somewhere.</p></dd><dt><span class="term">more/all</span></dt><dd><p>This subdir and file is not a part of the language package
|
||
|
itself.</p><p>If the directory more exists and contains a file called
|
||
|
all it will be parsed in addition to the mandatory all (see
|
||
|
above). The file is useful if you want to change some
|
||
|
translations for the current installation without conflicting
|
||
|
further upgrades. The file is not autogenerated and has the same
|
||
|
format as the all, but needs another key (more_texts). See the
|
||
|
german translation for an example or copy the following code:
|
||
|
</p><pre class="programlisting">
|
||
|
#!/usr/bin/perl
|
||
|
# -*- coding: utf-8; -*-
|
||
|
# vim: fenc=utf-8
|
||
|
<title>4.4. SQL-Upgradedateien</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s03.html" title="4.3. Programmatische API-Aufrufe"><link rel="next" href="ch04s05.html" title="4.5. Translations and languages"></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">4.4. SQL-Upgradedateien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.4. SQL-Upgradedateien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="db-upgrade-files"></a>4.4. SQL-Upgradedateien</h2></div></div></div><div class="sect2" title="4.4.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.introduction"></a>4.4.1. Einführung</h3></div></div></div><p>Datenbankupgrades werden über einzelne Upgrade-Scripte
|
||
|
gesteuert, die sich im Verzeichnis
|
||
|
<code class="filename">sql/Pg-upgrade2</code> befinden. In diesem Verzeichnis
|
||
|
muss pro Datenbankupgrade eine Datei existieren, die neben den
|
||
|
eigentlich auszuführenden SQL- oder Perl-Befehlen einige
|
||
|
Kontrollinformationen enthält.</p><p>Kontrollinformationen definieren Abhängigkeiten und Prioritäten,
|
||
|
sodass Datenbankscripte zwar in einer sicheren Reihenfolge ausgeführt
|
||
|
werden (z.B. darf ein <code class="literal">ALTER TABLE</code> erst ausgeführt
|
||
|
werden, wenn die Tabelle mit <code class="literal">CREATE TABLE</code> angelegt
|
||
|
wurde), diese Reihenfolge aber so flexibel ist, dass man keine
|
||
|
Versionsnummern braucht.</p><p>kivitendo merkt sich dabei, welches der Upgradescripte in
|
||
|
<code class="filename">sql/Pg-upgrade2</code> bereits durchgeführt wurde und
|
||
|
führt diese nicht erneut aus. Dazu dient die Tabelle
|
||
|
"<code class="literal">schema_info</code>", die bei der Anmeldung automatisch
|
||
|
angelegt wird.</p></div><div class="sect2" title="4.4.2. Format der Kontrollinformationen"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.format"></a>4.4.2. Format der Kontrollinformationen</h3></div></div></div><p>Die Kontrollinformationen sollten sich am Anfang der jeweiligen
|
||
|
Upgradedatei befinden. Jede Zeile, die Kontrollinformationen enthält,
|
||
|
hat dabei das folgende Format:</p><p>Für SQL-Upgradedateien:</p><pre class="programlisting">-- @key: value</pre><p>Für Perl-Upgradedateien:</p><pre class="programlisting"># @key: value</pre><p>Leerzeichen vor "<code class="varname">value</code>" werden
|
||
|
entfernt.</p><p>Die folgenden Schlüsselworte werden verarbeitet:</p><div class="variablelist"><dl><dt><span class="term">
|
||
|
<code class="varname">tag</code>
|
||
|
</span></dt><dd><p>Wird zwingend benötigt. Dies ist der "Name" des Upgrades.
|
||
|
Dieser "tag" kann von anderen Kontrolldateien in ihren
|
||
|
Abhängigkeiten verwendet werden (Schlüsselwort
|
||
|
"<code class="varname">depends</code>"). Der "tag" ist auch der Name, der
|
||
|
in der Datenbank eingetragen wird.</p><p>Normalerweise sollte die Kontrolldatei genau so heißen wie
|
||
|
der "tag", nur mit der Endung ".sql" bzw. "pl".</p><p>Ein Tag darf nur aus alphanumerischen Zeichen sowie den
|
||
|
Zeichen _ - ( ) bestehen. Insbesondere sind Leerzeichen nicht
|
||
|
erlaubt und sollten stattdessen mit Unterstrichen ersetzt
|
||
|
werden.</p></dd><dt><span class="term">
|
||
|
<code class="varname">charset</code>
|
||
|
</span></dt><dd><p>Empfohlen. Gibt den Zeichensatz an, in dem das Script
|
||
|
geschrieben wurde, z.B. "<code class="literal">UTF-8</code>". Aus
|
||
|
Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei
|
||
|
Abwesenheit des Tags für SQL-Upgradedateien der Zeichensatz
|
||
|
"<code class="literal">ISO-8859-15</code>" angenommen. Perl-Upgradescripte
|
||
|
hingegen müssen immer in UTF-8 encodiert sein und sollten
|
||
|
demnach auch ein "<code class="literal">use utf8;</code>"
|
||
|
enthalten.</p></dd><dt><span class="term">
|
||
|
<code class="varname">description</code>
|
||
|
</span></dt><dd><p>Benötigt. Eine Beschreibung, was in diesem Update
|
||
|
passiert. Diese wird dem Benutzer beim eigentlichen
|
||
|
Datenbankupdate angezeigt. Während der Tag in Englisch gehalten
|
||
|
sein sollte, sollte die Beschreibung auf Deutsch
|
||
|
erfolgen.</p></dd><dt><span class="term">
|
||
|
<code class="varname">depends</code>
|
||
|
</span></dt><dd><p>Optional. Eine mit Leerzeichen getrennte Liste von "tags",
|
||
|
von denen dieses Upgradescript abhängt. kivitendo stellt sicher,
|
||
|
dass die in dieser Liste aufgeführten Scripte bereits
|
||
|
durchgeführt wurden, bevor dieses Script ausgeführt wird.</p><p>Abhängigkeiten werden rekursiv betrachtet. Wenn also ein
|
||
|
Script "b" existiert, das von Änderungen in "a" abhängt, und
|
||
|
eine neue Kontrolldatei für "c" erstellt wird, die von
|
||
|
Änderungen in "a" und "b" abhängt, so genügt es, in "c" nur den
|
||
|
Tag "b" als Abhängigkeit zu definieren.</p><p>Es ist nicht erlaubt, sich selbst referenzierende
|
||
|
Abhängigkeiten zu definieren (z.B. "a" -> "b", "b" -> "c"
|
||
|
und "c" -> "a").</p></dd><dt><span class="term">
|
||
|
<code class="varname">priority</code>
|
||
|
</span></dt><dd><p>Optional. Ein Zahlenwert, der die Reihenfolge bestimmt, in
|
||
|
der Scripte ausgeführt werden, die die gleichen
|
||
|
Abhängigkeitstiefen besitzen. Fehlt dieser Parameter, so wird
|
||
|
der Wert 1000 benutzt.</p><p>Dies ist reine Kosmetik. Für echte Reihenfolgen muss
|
||
|
"depends" benutzt werden. kivitendo sortiert die auszuführenden
|
||
|
Scripte zuerst nach der Abhängigkeitstiefe (wenn "z" von "y"
|
||
|
abhängt und "y" von "x", so hat "z" eine Abhängigkeitstiefe von
|
||
|
2, "y" von 1 und "x" von 0. "x" würde hier zuerst ausgeführt,
|
||
|
dann "y", dann "z"), dann nach der Priorität und bei gleicher
|
||
|
Priorität alphabetisch nach dem "tag".</p></dd><dt><span class="term">
|
||
|
<code class="varname">ignore</code>
|
||
|
</span></dt><dd><p>Optional. Falls der Wert auf 1 (true) steht, wird das
|
||
|
Skript bei der Anmeldung ignoriert und entsprechend nicht
|
||
|
ausgeführt.</p></dd></dl></div></div><div class="sect2" title="4.4.3. Format von in Perl geschriebenen Datenbankupgradescripten"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.format-perl-files"></a>4.4.3. Format von in Perl geschriebenen
|
||
|
Datenbankupgradescripten</h3></div></div></div><p>In Perl geschriebene Datenbankscripte werden nicht einfach so
|
||
|
ausgeführt sondern müssen sich an gewisse Konventionen halten. Dafür
|
||
|
bekommen sie aber auch einige Komfortfunktionen bereitgestellt.</p><p>Ein Upgradescript stellt dabei eine vollständige Objektklasse
|
||
|
dar, die vom Elternobjekt "<code class="literal">SL::DBUpgrade2::Base</code>"
|
||
|
erben und eine Funktion namens "<code class="literal">run</code>" zur Verfügung
|
||
|
stellen muss. Das Script wird ausgeführt, indem eine Instanz dieser
|
||
|
Klasse erzeugt und darauf die erwähnte "<code class="literal">run</code>"
|
||
|
aufgerufen wird.</p><p>Zu beachten ist, dass sich der Paketname der Datei aus dem Wert
|
||
|
für "<code class="literal">@tag</code>" ableitet. Dabei werden alle Zeichen, die
|
||
|
in Paketnamen ungültig wären (gerade Bindestriche), durch Unterstriche
|
||
|
ersetzt. Insgesamt sieht der Paketname wie folgt aus:
|
||
|
"<code class="literal">SL::DBUpgrade2::tag</code>".</p><p>Welche Komfortfunktionen zur Verfügung stehen, erfahren Sie in
|
||
|
der Perl-Dokumentation zum oben genannten Modul; aufzurufen mit
|
||
|
"<span class="command"><strong>perldoc SL/DBUpgrade2/Base.pm</strong></span>".</p><p>Ein Mindestgerüst eines gültigen Perl-Upgradescriptes sieht wie
|
||
|
folgt aus:</p><pre class="programlisting"># @tag: beispiel-upgrade-file42
|
||
|
# @description: Ein schönes Beispielscript
|
||
|
# @depends: release_3_1_0
|
||
|
package SL::DBUpgrade2::beispiel_upgrade_file42;
|
||
|
|
||
|
use strict;
|
||
|
use utf8;
|
||
|
|
||
|
# These are additional texts for custom translations.
|
||
|
# The format is the same as for the normal file all, only
|
||
|
# with another key (more_texts instead of texts).
|
||
|
# The file has the form of 'english text' => 'foreign text',
|
||
|
use parent qw(SL::DBUpgrade2::Base);
|
||
|
|
||
|
$self->{more_texts} = {
|
||
|
sub run {
|
||
|
my ($self) = @_;
|
||
|
|
||
|
'Ship via' => 'Terms of delivery',
|
||
|
'Shipping Point' => 'Delivery time',
|
||
|
# hier Aktionen ausführen
|
||
|
|
||
|
return 1;
|
||
|
}
|
||
|
</pre><p>
|
||
|
</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. SQL-Upgradedateien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.5. Die kivitendo-Test-Suite</td></tr></table></div></body></html>
|
||
|
|
||
|
1;
|
||
|
</pre></div><div class="sect2" title="4.4.4. Hilfsscript dbupgrade2_tool.pl"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.dbupgrade-tool"></a>4.4.4. Hilfsscript dbupgrade2_tool.pl</h3></div></div></div><p>Um die Arbeit mit den Abhängigkeiten etwas zu erleichtern,
|
||
|
existiert ein Hilfsscript namens
|
||
|
"<code class="filename">scripts/dbupgrade2_tool.pl</code>". Es muss aus dem
|
||
|
kivitendo-ERP-Basisverzeichnis heraus aufgerufen werden. Dieses Tool
|
||
|
liest alle Datenbankupgradescripte aus dem Verzeichnis
|
||
|
<code class="filename">sql/Pg-upgrade2</code> aus. Es benutzt dafür die
|
||
|
gleichen Methoden wie kivitendo selber, sodass alle Fehlersituationen
|
||
|
von der Kommandozeile überprüft werden können.</p><p>Wird dem Script kein weiterer Parameter übergeben, so wird nur
|
||
|
eine Überprüfung der Felder und Abhängigkeiten vorgenommen. Man kann
|
||
|
sich aber auch Informationen auf verschiedene Art ausgeben
|
||
|
lassen:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Listenform: "<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--list</strong></span>"</p><p>Gibt eine Liste aller Scripte aus. Die Liste ist in der
|
||
|
Reihenfolge sortiert, in der kivitendo die Scripte ausführen
|
||
|
würde. Es werden neben der Listenposition der Tag, die
|
||
|
Abhängigkeitstiefe und die Priorität ausgegeben.</p></li><li class="listitem"><p>Baumform: "<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--tree</strong></span>"</p><p>Listet alle Tags in Baumform basierend auf den
|
||
|
Abhängigkeiten auf. Die "Wurzelknoten" sind dabei die Scripte, von
|
||
|
denen keine anderen abhängen. Die Unterknoten sind Scripte, die
|
||
|
beim übergeordneten Script als Abhängigkeit eingetragen
|
||
|
sind.</p></li><li class="listitem"><p><a name="db-upgrade-files.dbupgrade-tool.reverse-tree"></a>Umgekehrte Baumform: "<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--rtree</strong></span>"</p><p>Listet alle Tags in Baumform basierend auf den
|
||
|
Abhängigkeiten auf. Die "Wurzelknoten" sind dabei die Scripte mit
|
||
|
der geringsten Abhängigkeitstiefe. Die Unterknoten sind Scripte,
|
||
|
die das übergeordnete Script als Abhängigkeit eingetragen
|
||
|
haben.</p></li><li class="listitem"><p>Baumform mit Postscriptausgabe:
|
||
|
"<span class="command"><strong>./scripts/dbupgrade2_tool.pl
|
||
|
--graphviz</strong></span>"</p><p>Benötigt das Tool "<span class="command"><strong>graphviz</strong></span>", um mit
|
||
|
seiner Hilfe die <a class="link" href="ch04s04.html#db-upgrade-files.dbupgrade-tool.reverse-tree">umgekehrte
|
||
|
Baumform</a> in eine Postscriptdatei namens
|
||
|
"<code class="filename">db_dependencies.ps</code>" auszugeben. Dies ist
|
||
|
vermutlich die übersichtlichste Form, weil hierbei jeder Knoten
|
||
|
nur einmal ausgegeben wird. Bei den Textmodusbaumformen hingegen
|
||
|
können Knoten und all ihre Abhängigkeiten mehrfach ausgegeben
|
||
|
werden.</p></li><li class="listitem"><p>Scripte, von denen kein anderes Script abhängt:
|
||
|
"<span class="command"><strong>./scripts/dbupgrade2_tool.pl --nodeps</strong></span>"</p><p>Listet die Tags aller Scripte auf, von denen keine anderen
|
||
|
Scripte abhängen.</p></li></ul></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s03.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s05.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. Programmatische API-Aufrufe </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.5. Translations and languages</td></tr></table></div></body></html>
|
||
| doc/html/ch04s05.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.5. Die kivitendo-Test-Suite</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s04.html" title="4.4. Translations and languages"><link rel="next" href="ch04s06.html" title="4.6. Stil-Richtlinien"></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">4.5. Die kivitendo-Test-Suite</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.5. Die kivitendo-Test-Suite"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.testsuite"></a>4.5. Die kivitendo-Test-Suite</h2></div></div></div><div class="sect2" title="4.5.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.intro"></a>4.5.1. Einführung</h3></div></div></div><p>kivitendo enthält eine Suite für automatisierte Tests. Sie
|
||
|
basiert auf dem Standard-Perl-Modul
|
||
|
<code class="literal">Test::More</code>.</p><p>Die grundlegenden Fakten sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Alle Tests liegen im Unterverzeichnis
|
||
|
<code class="filename">t/</code>.</p></li><li class="listitem"><p>Ein Script (bzw. ein Test) in <code class="filename">t/</code>
|
||
|
enthält einen oder mehrere Testfälle.</p></li><li class="listitem"><p>Alle Dateinamen von Tests enden auf <code class="literal">.t</code>.
|
||
|
Es sind selbstständig ausführbare Perl-Scripte.</p></li><li class="listitem"><p>Die Test-Suite besteht aus der Gesamtheit aller Tests,
|
||
|
sprich aller Scripte in <code class="filename">t/</code>, deren Dateiname
|
||
|
auf <code class="literal">.t</code> endet.</p></li></ul></div></div><div class="sect2" title="4.5.2. Voraussetzungen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.prerequisites"></a>4.5.2. Voraussetzungen</h3></div></div></div><p>Für die Ausführung werden neben den für kivitendo eh schon
|
||
|
benötigten Module noch weitere Perl-Module benötigt. Diese
|
||
|
sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<code class="literal">Test::Deep</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-deep-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Deep</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Deep</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Exception</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-exception-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Exception</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Exception</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Output</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-output-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Output</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Output</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Harness</code> 3.0.0 oder höher. Dieses
|
||
|
Modul ist ab Perl 5.10.1 Bestandteil der Perl-Distribution und
|
||
|
kann für frühere Versionen aus dem <a class="ulink" href="http://www.cpan.org" target="_top">CPAN</a> bezogen werden.</p></li><li class="listitem"><p>
|
||
|
<code class="literal">LWP::Simple</code> aus dem Paket
|
||
|
<code class="literal">libwww-perl</code> (Debian-Panetname:
|
||
|
<code class="literal">libwww-perl</code>; Fedora:
|
||
|
<code class="literal">perl-libwww-perl</code>; openSUSE:
|
||
|
<code class="literal">perl-libwww-perl</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">URI::Find</code> (Debian-Panetname:
|
||
|
<code class="literal">liburi-find-perl</code>; Fedora:
|
||
|
<code class="literal">perl-URI-Find</code>; openSUSE:
|
||
|
<code class="literal">perl-URI-Find</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Sys::CPU</code> (Debian-Panetname:
|
||
|
<code class="literal">libsys-cpu-perl</code>; Fedora und openSUSE: nicht
|
||
|
vorhanden)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Thread::Pool::Simple</code> (Debian-Panetname:
|
||
|
<code class="literal">libthread-pool-simple-perl</code>; Fedora und
|
||
|
openSUSE: nicht vorhanden)</p></li></ul></div><p>Weitere Voraussetzung ist, dass die Testsuite ihre eigene
|
||
|
Datenbank anlegen kann, um Produktivdaten nicht zu gefährden. Dazu
|
||
|
müssen in der Konfigurationsdatei im Abschnit
|
||
|
<code class="literal">testing/database</code> Datenbankverbindungsparameter
|
||
|
angegeben werden. Der hier angegebene Benutzer muss weiterhin das
|
||
|
Recht haben, Datenbanken anzulegen und zu löschen.</p><p>Der so angegebene Benutzer muss nicht zwingend über
|
||
|
Super-User-Rechte verfügen. Allerdings gibt es einige
|
||
|
Datenbank-Upgrades, die genau diese Rechte benötigen. Für den Fall
|
||
|
kann man in diesem Konfigurationsabschnitt einen weiteren
|
||
|
Benutzeraccount angeben, der dann über Super-User-Rechte verfügt, und
|
||
|
mit dem die betroffenen Upgrades durchgeführt werden. In der
|
||
|
Beispiel-Konfigurationsdatei finden Sie die benötigten
|
||
|
Parameter.</p></div><div class="sect2" title="4.5.3. Existierende Tests ausführen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.execution"></a>4.5.3. Existierende Tests ausführen</h3></div></div></div><p>Es gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder,
|
||
|
man lässt alle Tests auf einmal ausführen, oder man führt gezielt
|
||
|
einzelne Scripte aus. Für beide Fälle gibt es das Helferscript
|
||
|
<code class="filename">t/test.pl</code>.</p><p>Will man die komplette Test-Suite ausführen, so muss man einfach
|
||
|
nur <code class="filename">t/test.pl</code> ohne weitere Parameter aus dem
|
||
|
kivitendo-Basisverzeichnis heraus ausführen.</p><p>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen
|
||
|
an <code class="filename">t/test.pl</code>. Beispielsweise:</p><pre class="programlisting">t/test.pl t/form/format_amount.t t/background_job/known_jobs.t</pre></div><div class="sect2" title="4.5.4. Bedeutung der verschiedenen Test-Scripte"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.meaning_of_scripts"></a>4.5.4. Bedeutung der verschiedenen Test-Scripte</h3></div></div></div><p>Die Test-Suite umfasst Tests sowohl für Funktionen als auch für
|
||
|
Programmierstil. Einige besonders zu erwähnende, weil auch während der
|
||
|
Entwicklung nützliche Tests sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<code class="filename">t/001compile.t</code> -- compiliert alle
|
||
|
Quelldateien und bricht bei Fehlern sofort ab</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/002goodperl.t</code> -- überprüft alle
|
||
|
Perl-Dateien auf Anwesenheit von '<code class="literal">use
|
||
|
strict</code>'-Anweisungen</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/003safesys.t</code> -- überprüft Aufrufe von
|
||
|
<code class="function">system()</code> und <code class="function">exec()</code> auf
|
||
|
Gültigkeit</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/005no_tabs.t</code> -- überprüft, ob Dateien
|
||
|
Tab-Zeichen enthalten</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/006spelling.t</code> -- sucht nach häufigen
|
||
|
Rechtschreibfehlern</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/011pod.t</code> -- überprüft die Syntax von
|
||
|
Dokumentation im POD-Format auf Gültigkeit</p></li></ul></div><p>Weitere Test-Scripte überprüfen primär die Funktionsweise
|
||
|
einzelner Funktionen und Module.</p></div><div class="sect2" title="4.5.5. Neue Test-Scripte erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.create_new"></a>4.5.5. Neue Test-Scripte erstellen</h3></div></div></div><p>Es wird sehr gern gesehen, wenn neue Funktionalität auch gleich
|
||
|
mit einem Test-Script abgesichert wird. Auch bestehende Funktion darf
|
||
|
und soll ausdrücklich nachträglich mit Test-Scripten abgesichert
|
||
|
werden.</p><div class="sect3" title="4.5.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen testen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.ideas_for_non_function_tests"></a>4.5.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen
|
||
|
testen</h4></div></div></div><p>Ideen, die abgesehen von Funktionen noch nicht umgesetzt
|
||
|
wurden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Überprüfung auf fehlende symbolische Links</p></li><li class="listitem"><p>Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit
|
||
|
gewissen Einschränkungen wie das Erlauben von deutschen
|
||
|
Umlauten)</p></li><li class="listitem"><p>Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)</p></li><li class="listitem"><p>Überprüfung auf Leerzeichen am Ende von Zeilen</p></li><li class="listitem"><p>Test, ob alle zu übersetzenden Strings in
|
||
|
<code class="filename">locale/de/all</code> vorhanden sind</p></li><li class="listitem"><p>Test, ob alle Webseiten-Templates in
|
||
|
<code class="filename">templates/webpages</code> mit vom Perl-Modul
|
||
|
<code class="literal">Template</code> compiliert werden können</p></li></ul></div></div><div class="sect3" title="4.5.5.2. Konvention für Verzeichnis- und Dateinamen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.directory_and_test_names"></a>4.5.5.2. Konvention für Verzeichnis- und Dateinamen</h4></div></div></div><p>Es gibt momentan eine wenige Richtlinien, wie Test-Scripte zu
|
||
|
benennen sind. Bitte die folgenden Punkte als Richtlinie betrachten
|
||
|
und ihnen soweit es geht folgen:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Die Dateiendung muss <code class="filename">.t</code>
|
||
|
lauten.</p></li><li class="listitem"><p>Namen sind englisch, komplett klein geschrieben und
|
||
|
einzelne Wörter mit Unterstrichten getrennt (beispielsweise
|
||
|
<code class="filename">bad_function_params.t</code>).</p></li><li class="listitem"><p>Unterverzeichnisse sollten grob nach dem Themenbereich
|
||
|
benannt sein, mit dem sich die Scripte darin befassen
|
||
|
(beispielsweise <code class="filename">background_jobs</code> für Tests
|
||
|
rund um Hintergrund-Jobs).</p></li><li class="listitem"><p>Test-Scripte sollten einen überschaubaren Bereich von
|
||
|
Funktionalität testen, der logisch zusammenhängend ist (z.B. nur
|
||
|
Tests für eine einzelne Funktion in einem Modul). Lieber mehrere
|
||
|
Test-Scripte schreiben.</p></li></ul></div></div><div class="sect3" title="4.5.5.3. Minimales Skelett für eigene Scripte"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.minimal_example"></a>4.5.5.3. Minimales Skelett für eigene Scripte</h4></div></div></div><p>Der folgenden Programmcode enthält das kleinstmögliche
|
||
|
Testscript und kann als Ausgangspunkt für eigene Tests verwendet
|
||
|
werden:</p><pre class="programlisting">use Test::More tests => 0;
|
||
|
<title>4.5. Translations and languages</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s04.html" title="4.4. SQL-Upgradedateien"><link rel="next" href="ch04s06.html" title="4.6. Die kivitendo-Test-Suite"></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">4.5. Translations and languages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.5. Translations and languages"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="translations-languages"></a>4.5. Translations and languages</h2></div></div></div><div class="sect2" title="4.5.1. Introduction"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.introduction"></a>4.5.1. Introduction</h3></div></div></div><div class="note" title="Anmerkung" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Anmerkung]" src="system/docbook-xsl/images/note.png"></td><th align="left">Anmerkung</th></tr><tr><td align="left" valign="top"><p>Dieser Abschnitt ist in Englisch geschrieben, um
|
||
|
internationalen Übersetzern die Arbeit zu erleichtern.</p></td></tr></table></div><p>This section describes how localization packages in kivitendo
|
||
|
are built. Currently the only language fully supported is German, and
|
||
|
since most of the internal messages are held in English the English
|
||
|
version is usable too.</p></div><div class="sect2" title="4.5.2. Character set"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.character-set"></a>4.5.2. Character set</h3></div></div></div><p>All files included in a language pack must use UTF-8 as their
|
||
|
encoding.</p></div><div class="sect2" title="4.5.3. File structure"><div class="titlepage"><div><div><h3 class="title"><a name="translations-languages.file-structure"></a>4.5.3. File structure</h3></div></div></div><p>The structure of locales in kivitendo is:</p><pre class="programlisting">kivitendo/locale/<langcode>/</pre><p>where <langcode> stands for an abbreviation of the
|
||
|
language package. The builtin packages use two letter <a class="ulink" href="http://en.wikipedia.org/wiki/ISO_639-1" target="_top">ISO 639-1</a> codes,
|
||
|
but the actual name is not relevant for the program and can easily be
|
||
|
extended to <a class="ulink" href="http://en.wikipedia.org/wiki/IETF_language_tag" target="_top">IETF language
|
||
|
tags</a> (i.e. "en_GB"). In fact the original language packages
|
||
|
from SQL Ledger are named in this way.</p><p>In such a language directory the following files are
|
||
|
recognized:</p><div class="variablelist"><dl><dt><span class="term">LANGUAGE</span></dt><dd><p>This file is mandatory.</p><p>The <code class="filename">LANGUAGE</code> file contains the self
|
||
|
descripted name of the language. It should contain a native
|
||
|
representation first, and in parenthesis an english translation
|
||
|
after that. Example:</p><pre class="programlisting">Deutsch (German)</pre></dd><dt><span class="term">all</span></dt><dd><p>This file is mandatory.</p><p>The central translation file. It is essentially an inline
|
||
|
Perl script autogenerated by <span class="command"><strong>locales.pl</strong></span>. To
|
||
|
generate it, generate the directory and the two files mentioned
|
||
|
above, and execute the following command:</p><pre class="programlisting">scripts/locales.pl <langcode></pre><p>Otherwise you can simply copy one of the other languages.
|
||
|
You will be told how many are missing like this:</p><pre class="programlisting">$ scripts/locales.pl en
|
||
|
English - 0.6% - 2015/2028 missing</pre><p>A file named "<code class="filename">missing</code>" will be
|
||
|
generated and can be edited. You can also edit the
|
||
|
"<code class="filename">all</code>" file directly. Edit everything you
|
||
|
like to fit the target language and execute
|
||
|
<span class="command"><strong>locales.pl</strong></span> again. See how the missing words
|
||
|
get fewer.</p></dd><dt><span class="term">Num2text</span></dt><dd><p>Legacy code from SQL Ledger. It provides a means for
|
||
|
numbers to be converted into natural language, like
|
||
|
<code class="literal">1523 => one thousand five hundred twenty
|
||
|
three</code>. If you want to provide it, it must be inlinable
|
||
|
Perl code which provides a <code class="function">num2text</code> sub. If
|
||
|
an <code class="function">init</code> sub exists it will be executed
|
||
|
first.</p><p>Only used in the check and receipt printing module.</p></dd><dt><span class="term">special_chars</span></dt><dd><p>kivitendo comes with a lot of interfaces to different
|
||
|
formats, some of which are rather picky with their accepted
|
||
|
charset. The <code class="filename">special_chars</code> file contains a
|
||
|
listing of chars not suited for different file format and
|
||
|
provides substitutions. It is written in "Simple Ini" style,
|
||
|
containing a block for every file format.</p><p>First entry should be the order of substitution for
|
||
|
entries as a whitespace separated list. All entries are
|
||
|
interpolated, so <code class="literal">\n</code>, <code class="literal">\x20</code>
|
||
|
and <code class="literal">\\</code> all work.</p><p>After that every entry is a special char that should be
|
||
|
translated when writing text into such a file.</p><p>Example:</p><pre class="programlisting">[Template/XML]
|
||
|
order=& < > \n
|
||
|
&=&amp;
|
||
|
<=&lt;
|
||
|
>=&gt;
|
||
|
\n=<br></pre><p>Note the importance of the order in this example.
|
||
|
Substituting < and > befor & would lead to $gt; become
|
||
|
&amp;gt;</p><p>For a list of valid formats, see the German
|
||
|
<code class="filename">special_chars</code> entry. As of this writing the
|
||
|
following are recognized:</p><pre class="programlisting">HTML
|
||
|
URL@HTML
|
||
|
Template/HTML
|
||
|
Template/XML
|
||
|
Template/LaTeX
|
||
|
Template/OpenDocument
|
||
|
filenames</pre><p>The last of which is very machine dependant. Remember that
|
||
|
a lot of characters are forbidden by some filesystems, for
|
||
|
example MS Windows doesn't like ':' in its files where Linux
|
||
|
doesn't mind that. If you want the files created with your
|
||
|
language pack to be portable, find all chars that could cause
|
||
|
trouble.</p></dd><dt><span class="term">missing</span></dt><dd><p>This file is not a part of the language package
|
||
|
itself.</p><p>This is a file generated by
|
||
|
<span class="command"><strong>scripts/locales.pl</strong></span> while processing your
|
||
|
locales. It's only to have the missing entries singled out and
|
||
|
does not belong to a language package.</p></dd><dt><span class="term">lost</span></dt><dd><p>This file is not a part of the language package
|
||
|
itself.</p><p>Another file generated by
|
||
|
<span class="command"><strong>scripts/locales.pl</strong></span>. If for any reason a
|
||
|
translation does not appear anymore and can be deleted, it gets
|
||
|
moved here. The last 50 or so entries deleted are saved here in
|
||
|
case you made a typo, so that you don't have to translate
|
||
|
everything again. If a tranlsation is missing, the lost file is
|
||
|
checked first. If you maintain a language package, you might
|
||
|
want to keep this safe somewhere.</p></dd><dt><span class="term">more/all</span></dt><dd><p>This subdir and file is not a part of the language package
|
||
|
itself.</p><p>If the directory more exists and contains a file called
|
||
|
all it will be parsed in addition to the mandatory all (see
|
||
|
above). The file is useful if you want to change some
|
||
|
translations for the current installation without conflicting
|
||
|
further upgrades. The file is not autogenerated and has the same
|
||
|
format as the all, but needs another key (more_texts). See the
|
||
|
german translation for an example or copy the following code:
|
||
|
</p><pre class="programlisting">
|
||
|
#!/usr/bin/perl
|
||
|
# -*- coding: utf-8; -*-
|
||
|
# vim: fenc=utf-8
|
||
|
|
||
|
use lib 't';
|
||
|
use utf8;
|
||
|
|
||
|
use Support::TestSetup;
|
||
|
# These are additional texts for custom translations.
|
||
|
# The format is the same as for the normal file all, only
|
||
|
# with another key (more_texts instead of texts).
|
||
|
# The file has the form of 'english text' => 'foreign text',
|
||
|
|
||
|
Support::TestSetup::login();</pre><p>Wird eine vollständig initialisierte kivitendo-Umgebung
|
||
|
benötigt (Stichwort: alle globalen Variablen wie
|
||
|
<code class="varname">$::auth</code>, <code class="varname">$::form</code> oder
|
||
|
<code class="varname">$::lxdebug</code>), so muss in der Konfigurationsdatei
|
||
|
<code class="filename">config/kivitendo.conf</code> im Abschnitt
|
||
|
<code class="literal">testing.login</code> ein gültiger Login-Name eingetragen
|
||
|
sein. Dieser wird für die Datenbankverbindung benötigt.</p><p>Wir keine vollständig initialisierte Umgebung benötigt, so
|
||
|
kann die letzte Zeile </p><pre class="programlisting">Support::TestSetup::login();</pre><p>
|
||
|
weggelassen werden, was die Ausführungszeit des Scripts leicht
|
||
|
verringert.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.4. Translations and languages </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.6. Stil-Richtlinien</td></tr></table></div></body></html>
|
||
|
$self->{more_texts} = {
|
||
|
|
||
|
'Ship via' => 'Terms of delivery',
|
||
|
'Shipping Point' => 'Delivery time',
|
||
|
}
|
||
|
</pre><p>
|
||
|
</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s04.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s06.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.4. SQL-Upgradedateien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.6. Die kivitendo-Test-Suite</td></tr></table></div></body></html>
|
||
| doc/html/ch04s06.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.6. Stil-Richtlinien</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Die kivitendo-Test-Suite"><link rel="next" href="ch04s07.html" title="4.7. Dokumentation erstellen"></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">4.6. Stil-Richtlinien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.6. Stil-Richtlinien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.style-guide"></a>4.6. Stil-Richtlinien</h2></div></div></div><p>Die folgenden Regeln haben das Ziel, den Code möglichst gut les-
|
||
|
und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich
|
||
|
eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden
|
||
|
wird (Stichworte "Klammern" oder "Hash-Keys").</p><p>Diese Regeln sind keine Schikane sondern erleichtern allen das
|
||
|
Leben!</p><p>Jeder, der einen Patch schickt, sollte seinen Code vorher
|
||
|
überprüfen. Einige der Regeln lassen sich automatisch überprüfen, andere
|
||
|
nicht.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Es werden keine echten Tabs sondern Leerzeichen
|
||
|
verwendet.</p></li><li class="listitem"><p>Die Einrückung beträgt zwei Leerzeichen. Beispiel:</p><pre class="programlisting">foreach my $row (@data) {
|
||
|
if ($flag) {
|
||
|
# do something with $row
|
||
|
}
|
||
|
<title>4.6. Die kivitendo-Test-Suite</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s05.html" title="4.5. Translations and languages"><link rel="next" href="ch04s07.html" title="4.7. Stil-Richtlinien"></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">4.6. Die kivitendo-Test-Suite</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.6. Die kivitendo-Test-Suite"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.testsuite"></a>4.6. Die kivitendo-Test-Suite</h2></div></div></div><div class="sect2" title="4.6.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.intro"></a>4.6.1. Einführung</h3></div></div></div><p>kivitendo enthält eine Suite für automatisierte Tests. Sie
|
||
|
basiert auf dem Standard-Perl-Modul
|
||
|
<code class="literal">Test::More</code>.</p><p>Die grundlegenden Fakten sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Alle Tests liegen im Unterverzeichnis
|
||
|
<code class="filename">t/</code>.</p></li><li class="listitem"><p>Ein Script (bzw. ein Test) in <code class="filename">t/</code>
|
||
|
enthält einen oder mehrere Testfälle.</p></li><li class="listitem"><p>Alle Dateinamen von Tests enden auf <code class="literal">.t</code>.
|
||
|
Es sind selbstständig ausführbare Perl-Scripte.</p></li><li class="listitem"><p>Die Test-Suite besteht aus der Gesamtheit aller Tests,
|
||
|
sprich aller Scripte in <code class="filename">t/</code>, deren Dateiname
|
||
|
auf <code class="literal">.t</code> endet.</p></li></ul></div></div><div class="sect2" title="4.6.2. Voraussetzungen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.prerequisites"></a>4.6.2. Voraussetzungen</h3></div></div></div><p>Für die Ausführung werden neben den für kivitendo eh schon
|
||
|
benötigten Module noch weitere Perl-Module benötigt. Diese
|
||
|
sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<code class="literal">Test::Deep</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-deep-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Deep</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Deep</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Exception</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-exception-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Exception</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Exception</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Output</code> (Debian-Paketname:
|
||
|
<code class="literal">libtest-output-perl</code>; Fedora:
|
||
|
<code class="literal">perl-Test-Output</code>; openSUSE:
|
||
|
<code class="literal">perl-Test-Output</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Test::Harness</code> 3.0.0 oder höher. Dieses
|
||
|
Modul ist ab Perl 5.10.1 Bestandteil der Perl-Distribution und
|
||
|
kann für frühere Versionen aus dem <a class="ulink" href="http://www.cpan.org" target="_top">CPAN</a> bezogen werden.</p></li><li class="listitem"><p>
|
||
|
<code class="literal">LWP::Simple</code> aus dem Paket
|
||
|
<code class="literal">libwww-perl</code> (Debian-Panetname:
|
||
|
<code class="literal">libwww-perl</code>; Fedora:
|
||
|
<code class="literal">perl-libwww-perl</code>; openSUSE:
|
||
|
<code class="literal">perl-libwww-perl</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">URI::Find</code> (Debian-Panetname:
|
||
|
<code class="literal">liburi-find-perl</code>; Fedora:
|
||
|
<code class="literal">perl-URI-Find</code>; openSUSE:
|
||
|
<code class="literal">perl-URI-Find</code>)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Sys::CPU</code> (Debian-Panetname:
|
||
|
<code class="literal">libsys-cpu-perl</code>; Fedora und openSUSE: nicht
|
||
|
vorhanden)</p></li><li class="listitem"><p>
|
||
|
<code class="literal">Thread::Pool::Simple</code> (Debian-Panetname:
|
||
|
<code class="literal">libthread-pool-simple-perl</code>; Fedora und
|
||
|
openSUSE: nicht vorhanden)</p></li></ul></div><p>Weitere Voraussetzung ist, dass die Testsuite ihre eigene
|
||
|
Datenbank anlegen kann, um Produktivdaten nicht zu gefährden. Dazu
|
||
|
müssen in der Konfigurationsdatei im Abschnit
|
||
|
<code class="literal">testing/database</code> Datenbankverbindungsparameter
|
||
|
angegeben werden. Der hier angegebene Benutzer muss weiterhin das
|
||
|
Recht haben, Datenbanken anzulegen und zu löschen.</p><p>Der so angegebene Benutzer muss nicht zwingend über
|
||
|
Super-User-Rechte verfügen. Allerdings gibt es einige
|
||
|
Datenbank-Upgrades, die genau diese Rechte benötigen. Für den Fall
|
||
|
kann man in diesem Konfigurationsabschnitt einen weiteren
|
||
|
Benutzeraccount angeben, der dann über Super-User-Rechte verfügt, und
|
||
|
mit dem die betroffenen Upgrades durchgeführt werden. In der
|
||
|
Beispiel-Konfigurationsdatei finden Sie die benötigten
|
||
|
Parameter.</p></div><div class="sect2" title="4.6.3. Existierende Tests ausführen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.execution"></a>4.6.3. Existierende Tests ausführen</h3></div></div></div><p>Es gibt mehrere Möglichkeiten zum Ausführen der Tests: entweder,
|
||
|
man lässt alle Tests auf einmal ausführen, oder man führt gezielt
|
||
|
einzelne Scripte aus. Für beide Fälle gibt es das Helferscript
|
||
|
<code class="filename">t/test.pl</code>.</p><p>Will man die komplette Test-Suite ausführen, so muss man einfach
|
||
|
nur <code class="filename">t/test.pl</code> ohne weitere Parameter aus dem
|
||
|
kivitendo-Basisverzeichnis heraus ausführen.</p><p>Um einzelne Test-Scripte auszuführen, übergibt man deren Namen
|
||
|
an <code class="filename">t/test.pl</code>. Beispielsweise:</p><pre class="programlisting">t/test.pl t/form/format_amount.t t/background_job/known_jobs.t</pre></div><div class="sect2" title="4.6.4. Bedeutung der verschiedenen Test-Scripte"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.meaning_of_scripts"></a>4.6.4. Bedeutung der verschiedenen Test-Scripte</h3></div></div></div><p>Die Test-Suite umfasst Tests sowohl für Funktionen als auch für
|
||
|
Programmierstil. Einige besonders zu erwähnende, weil auch während der
|
||
|
Entwicklung nützliche Tests sind:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<code class="filename">t/001compile.t</code> -- compiliert alle
|
||
|
Quelldateien und bricht bei Fehlern sofort ab</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/002goodperl.t</code> -- überprüft alle
|
||
|
Perl-Dateien auf Anwesenheit von '<code class="literal">use
|
||
|
strict</code>'-Anweisungen</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/003safesys.t</code> -- überprüft Aufrufe von
|
||
|
<code class="function">system()</code> und <code class="function">exec()</code> auf
|
||
|
Gültigkeit</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/005no_tabs.t</code> -- überprüft, ob Dateien
|
||
|
Tab-Zeichen enthalten</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/006spelling.t</code> -- sucht nach häufigen
|
||
|
Rechtschreibfehlern</p></li><li class="listitem"><p>
|
||
|
<code class="filename">t/011pod.t</code> -- überprüft die Syntax von
|
||
|
Dokumentation im POD-Format auf Gültigkeit</p></li></ul></div><p>Weitere Test-Scripte überprüfen primär die Funktionsweise
|
||
|
einzelner Funktionen und Module.</p></div><div class="sect2" title="4.6.5. Neue Test-Scripte erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.testsuite.create_new"></a>4.6.5. Neue Test-Scripte erstellen</h3></div></div></div><p>Es wird sehr gern gesehen, wenn neue Funktionalität auch gleich
|
||
|
mit einem Test-Script abgesichert wird. Auch bestehende Funktion darf
|
||
|
und soll ausdrücklich nachträglich mit Test-Scripten abgesichert
|
||
|
werden.</p><div class="sect3" title="4.6.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen testen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.ideas_for_non_function_tests"></a>4.6.5.1. Ideen für neue Test-Scripte, die keine konkreten Funktionen
|
||
|
testen</h4></div></div></div><p>Ideen, die abgesehen von Funktionen noch nicht umgesetzt
|
||
|
wurden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Überprüfung auf fehlende symbolische Links</p></li><li class="listitem"><p>Suche nach Nicht-ASCII-Zeichen in Perl-Code-Dateien (mit
|
||
|
gewissen Einschränkungen wie das Erlauben von deutschen
|
||
|
Umlauten)</p></li><li class="listitem"><p>Test auf DOS-Zeilenenden (\r\n anstelle von nur \n)</p></li><li class="listitem"><p>Überprüfung auf Leerzeichen am Ende von Zeilen</p></li><li class="listitem"><p>Test, ob alle zu übersetzenden Strings in
|
||
|
<code class="filename">locale/de/all</code> vorhanden sind</p></li><li class="listitem"><p>Test, ob alle Webseiten-Templates in
|
||
|
<code class="filename">templates/webpages</code> mit vom Perl-Modul
|
||
|
<code class="literal">Template</code> compiliert werden können</p></li></ul></div></div><div class="sect3" title="4.6.5.2. Konvention für Verzeichnis- und Dateinamen"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.directory_and_test_names"></a>4.6.5.2. Konvention für Verzeichnis- und Dateinamen</h4></div></div></div><p>Es gibt momentan eine wenige Richtlinien, wie Test-Scripte zu
|
||
|
benennen sind. Bitte die folgenden Punkte als Richtlinie betrachten
|
||
|
und ihnen soweit es geht folgen:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Die Dateiendung muss <code class="filename">.t</code>
|
||
|
lauten.</p></li><li class="listitem"><p>Namen sind englisch, komplett klein geschrieben und
|
||
|
einzelne Wörter mit Unterstrichten getrennt (beispielsweise
|
||
|
<code class="filename">bad_function_params.t</code>).</p></li><li class="listitem"><p>Unterverzeichnisse sollten grob nach dem Themenbereich
|
||
|
benannt sein, mit dem sich die Scripte darin befassen
|
||
|
(beispielsweise <code class="filename">background_jobs</code> für Tests
|
||
|
rund um Hintergrund-Jobs).</p></li><li class="listitem"><p>Test-Scripte sollten einen überschaubaren Bereich von
|
||
|
Funktionalität testen, der logisch zusammenhängend ist (z.B. nur
|
||
|
Tests für eine einzelne Funktion in einem Modul). Lieber mehrere
|
||
|
Test-Scripte schreiben.</p></li></ul></div></div><div class="sect3" title="4.6.5.3. Minimales Skelett für eigene Scripte"><div class="titlepage"><div><div><h4 class="title"><a name="devel.testsuite.minimal_example"></a>4.6.5.3. Minimales Skelett für eigene Scripte</h4></div></div></div><p>Der folgenden Programmcode enthält das kleinstmögliche
|
||
|
Testscript und kann als Ausgangspunkt für eigene Tests verwendet
|
||
|
werden:</p><pre class="programlisting">use Test::More tests => 0;
|
||
|
|
||
|
if ($use_modules) {
|
||
|
$row->{modules} = MODULE->retrieve(
|
||
|
id => $row->{id},
|
||
|
date => $use_now ? localtime() : $row->{time},
|
||
|
);
|
||
|
}
|
||
|
use lib 't';
|
||
|
|
||
|
$report->add($row);
|
||
|
}</pre></li><li class="listitem"><p>Öffnende geschweifte Klammern befinden sich auf der gleichen
|
||
|
Zeile wie der letzte Befehl. Beispiele:</p><pre class="programlisting">sub debug {
|
||
|
...
|
||
|
}</pre><p>oder</p><pre class="programlisting">if ($form->{item_rows} > 0) {
|
||
|
...
|
||
|
}</pre></li><li class="listitem"><p>Schließende geschweifte Klammern sind so weit eingerückt wie
|
||
|
der Befehl / die öffnende schließende Klammer, die den Block
|
||
|
gestartet hat, und nicht auf der Ebene des Inhalts. Die gleichen
|
||
|
Beispiele wie bei 3. gelten.</p></li><li class="listitem"><p>Die Wörter "<code class="function">else</code>",
|
||
|
"<code class="function">elsif</code>", "<code class="function">while</code>" befinden
|
||
|
sich auf der gleichen Zeile wie schließende geschweifte Klammern.
|
||
|
Beispiele:</p><pre class="programlisting">if ($form->{sum} > 1000) {
|
||
|
...
|
||
|
} elsif ($form->{sum} > 0) {
|
||
|
...
|
||
|
} else {
|
||
|
...
|
||
|
}
|
||
|
use Support::TestSetup;
|
||
|
|
||
|
do {
|
||
|
...
|
||
|
} until ($a > 0);</pre></li><li class="listitem"><p>Parameter von Funktionsaufrufen müssen mit runden Klammern
|
||
|
versehen werden. Davon nicht betroffen sind interne Perl-Funktionen,
|
||
|
und grep-ähnliche Operatoren. Beispiel:</p><pre class="programlisting">$main::lxdebug->message("Could not find file.");
|
||
|
%options = map { $_ => 1 } grep { !/^#/ } @config_file;</pre></li><li class="listitem"><p>Verschiedene Klammern, Ihre Ausdrücke und Leerzeichen:</p><p>Generell gilt: Hashkeys und Arrayindices sollten nicht durch
|
||
|
Leerzeichen abgesetzt werden. Logische Klammerungen ebensowenig,
|
||
|
Blöcke schon. Beispiel:</p><pre class="programlisting">if (($form->{debug} == 1) && ($form->{sum} - 100 < 0)) {
|
||
|
...
|
||
|
}
|
||
|
|
||
|
$array[$i + 1] = 4;
|
||
|
$form->{sum} += $form->{"row_$i"};
|
||
|
$form->{ $form->{index} } += 1;
|
||
|
|
||
|
map { $form->{sum} += $form->{"row_$_"} } 1..$rowcount;</pre></li><li class="listitem"><p>Mehrzeilige Befehle</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Werden die Parameter eines Funktionsaufrufes auf mehrere
|
||
|
Zeilen aufgeteilt, so sollten diese bis zu der Spalte eingerückt
|
||
|
werden, in der die ersten Funktionsparameter in der ersten Zeile
|
||
|
stehen. Beispiel:</p><pre class="programlisting">$sth = $dbh->prepare("SELECT * FROM some_table WHERE col = ?",
|
||
|
$form->{some_col_value});</pre></li><li class="listitem"><p>Ein Spezialfall ist der ternäre Operator "?:", der am
|
||
|
besten in einer übersichtlichen Tabellenstruktur organisiert
|
||
|
wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form->{"row_$i"} ? $i
|
||
|
: $form->{oldcount} ? $form->{oldcount} + 1
|
||
|
: $form->{rowcount} - $form->{rowbase};</pre></li></ol></div></li><li class="listitem"><p>Kommentare</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Kommentare, die alleine in einer Zeile stehen, sollten
|
||
|
soweit wie der Code eingerückt sein.</p></li><li class="listitem"><p>Seitliche hängende Kommentare sollten einheitlich
|
||
|
formatiert werden.</p></li><li class="listitem"><p>Sämtliche Kommentare und Sonstiges im Quellcode ist bitte
|
||
|
auf Englisch zu verfassen. So wie ich keine Lust habe,
|
||
|
französischen Quelltext zu lesen, sollte auch der kivitendo
|
||
|
Quelltext für nicht-Deutschsprachige lesbar sein.
|
||
|
Beispiel:</p><pre class="programlisting">my $found = 0;
|
||
|
while (1) {
|
||
|
last if $found;
|
||
|
|
||
|
# complicated check
|
||
|
$found = 1 if //
|
||
|
}
|
||
|
|
||
|
$i = 0 # initialize $i
|
||
|
$n = $i; # save $i
|
||
|
$i *= $const; # do something crazy
|
||
|
$i = $n; # recover $i</pre></li></ol></div></li><li class="listitem"><p>Hashkeys sollten nur in Anführungszeichen stehen, wenn die
|
||
|
Interpolation gewünscht ist. Beispiel:</p><pre class="programlisting">$form->{sum} = 0;
|
||
|
$form->{"row_$i"} = $form->{"row_$i"} - 5;
|
||
|
$some_hash{42} = 54;</pre></li><li class="listitem"><p>Die maximale Zeilenlänge ist nicht beschränkt. Zeilenlängen
|
||
|
unterhalb von 79 Zeichen helfen unter bestimmten Bedingungen, aber
|
||
|
wenn die Lesbarkeit unter kurzen Zeilen leidet (wie zum Biespiel in
|
||
|
grossen Tabellen), dann ist Lesbarkeit vorzuziehen.</p><p>Als Beispiel sei die Funktion
|
||
|
<code class="function">print_options</code> aus
|
||
|
<code class="filename">bin/mozilla/io.pl</code> angeführt.</p></li><li class="listitem"><p>Trailing Whitespace, d.h. Leerzeichen am Ende von Zeilen sind
|
||
|
unerwünscht. Sie führen zu unnötigen Whitespaceänderungen, die diffs
|
||
|
verfälschen.</p><p>Emacs und vim haben beide recht einfache Methoden zur
|
||
|
Entfernung von trailing whitespace. Emacs kennt das Kommande
|
||
|
<span class="command"><strong>nuke-trailing-whitespace</strong></span>, vim macht das gleiche
|
||
|
manuell über <code class="literal">:%s/\s\+$//e</code> Mit <code class="literal">:au
|
||
|
BufWritePre * :%s/\s\+$//e</code> wird das an Speichern
|
||
|
gebunden.</p></li><li class="listitem"><p>Es wird kein <span class="command"><strong>perltidy</strong></span> verwendet.</p><p>In der Vergangenheit wurde versucht,
|
||
|
<span class="command"><strong>perltidy</strong></span> zu verwenden, um einen einheitlichen
|
||
|
Stil zu erlangen. Es hat sich aber gezeigt, dass
|
||
|
<span class="command"><strong>perltidy</strong></span>s sehr eigenwilliges Verhalten, was
|
||
|
Zeilenumbrüche angeht, oftmals gut formatierten Code zerstört. Für
|
||
|
den Interessierten sind hier die
|
||
|
<span class="command"><strong>perltidy</strong></span>-Optionen, die grob den beschriebenen
|
||
|
Richtlinien entsprechen:</p><pre class="programlisting">-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm
|
||
|
-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79
|
||
|
-lp -vt=1 -vtc=1</pre></li><li class="listitem"><p>
|
||
|
<code class="varname">STDERR</code> ist tabu. Unkonditionale
|
||
|
Debugmeldungen auch.</p><p>kivitendo bietet mit dem Modul <code class="classname">LXDebug</code>
|
||
|
einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen
|
||
|
Grund, nach <code class="varname">STDERR</code> zu schreiben.</p><p>Die <code class="classname">LXDebug</code>-Methode
|
||
|
"<code class="function">message</code>" nimmt als ersten Paramter außerdem
|
||
|
eine Flagmaske, für die die Meldung angezeigt wird, wobei "0" immer
|
||
|
angezeigt wird. Solche Meldungen sollten nicht eingecheckt werden
|
||
|
und werden in den meisten Fällen auch vom Repository
|
||
|
zurückgewiesen.</p></li><li class="listitem"><p>Alle neuen Module müssen use strict verwenden.</p><p>
|
||
|
<code class="varname">$form</code>, <code class="varname">$auth</code>,
|
||
|
<code class="varname">$locale</code>, <code class="varname">$lxdebug</code> und
|
||
|
<code class="varname">%myconfig</code> werden derzeit aus dem main package
|
||
|
importiert (siehe <a class="xref" href="ch04.html#devel.globals" title="4.1. Globale Variablen">Globale Variablen</a>. Alle anderen
|
||
|
Konstrukte sollten lexikalisch lokal gehalten werden.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.5. Die kivitendo-Test-Suite </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.7. Dokumentation erstellen</td></tr></table></div></body></html>
|
||
|
Support::TestSetup::login();</pre><p>Wird eine vollständig initialisierte kivitendo-Umgebung
|
||
|
benötigt (Stichwort: alle globalen Variablen wie
|
||
|
<code class="varname">$::auth</code>, <code class="varname">$::form</code> oder
|
||
|
<code class="varname">$::lxdebug</code>), so muss in der Konfigurationsdatei
|
||
|
<code class="filename">config/kivitendo.conf</code> im Abschnitt
|
||
|
<code class="literal">testing.login</code> ein gültiger Login-Name eingetragen
|
||
|
sein. Dieser wird für die Datenbankverbindung benötigt.</p><p>Wir keine vollständig initialisierte Umgebung benötigt, so
|
||
|
kann die letzte Zeile </p><pre class="programlisting">Support::TestSetup::login();</pre><p>
|
||
|
weggelassen werden, was die Ausführungszeit des Scripts leicht
|
||
|
verringert.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s05.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s07.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.5. Translations and languages </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.7. Stil-Richtlinien</td></tr></table></div></body></html>
|
||
| doc/html/ch04s07.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.7. Dokumentation erstellen</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s06.html" title="4.6. Stil-Richtlinien"></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">4.7. Dokumentation erstellen</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="4.7. Dokumentation erstellen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.build-doc"></a>4.7. Dokumentation erstellen</h2></div></div></div><div class="sect2" title="4.7.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.introduction"></a>4.7.1. Einführung</h3></div></div></div><p>Diese Dokumentation ist in <span class="productname">DocBook</span>™
|
||
|
XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor.
|
||
|
Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen
|
||
|
Editor nutzt, der spezielle Unterstützung für
|
||
|
<span class="productname">DocBook</span>™ mitbringt. Wir empfehlen dafür den
|
||
|
<a class="ulink" href="http://www.xmlmind.com/xmleditor/" target="_top">XMLmind XML
|
||
|
Editor</a>, der bei nicht kommerzieller Nutzung kostenlos
|
||
|
ist.</p></div><div class="sect2" title="4.7.2. Benötigte Software"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.required-software"></a>4.7.2. Benötigte Software</h3></div></div></div><p>Bei <span class="productname">DocBook</span>™ ist Prinzip, dass
|
||
|
ausschließlich die XML-Quelldatei bearbeitet wird. Aus dieser werden
|
||
|
dann mit entsprechenden Stylesheets andere Formate wie PDF oder HTML
|
||
|
erzeugt. Bei kivitendo übernimmt diese Aufgabe das Shell-Script
|
||
|
<span class="command"><strong>scripts/build_doc.sh</strong></span>.</p><p>Das Script benötigt zur Konvertierung verschiedene
|
||
|
Softwarekomponenten, die im normalen kivitendo-Betrieb nicht benötigt
|
||
|
werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<a class="ulink" href="http://www.oracle.com/technetwork/java/index.html" target="_top">Java</a>
|
||
|
in einer halbwegs aktuellen Version</p></li><li class="listitem"><p>Das Java-Build-System <a class="ulink" href="http://ant.apache.org/" target="_top">Apache Ant</a>
|
||
|
</p></li><li class="listitem"><p>Das Dokumentations-System Dobudish für
|
||
|
<span class="productname">DocBook</span>™ 4.5, eine Zusammenstellung
|
||
|
diverser Stylesheets und Grafiken zur Konvertierung von
|
||
|
<span class="productname">DocBook</span>™ XML in andere Formate. Das
|
||
|
Paket, das benötigt wird, ist zum Zeitpunkt der
|
||
|
Dokumentationserstellung
|
||
|
<code class="filename">dobudish-nojre-1.1.4.zip</code>, aus auf <a class="ulink" href="http://code.google.com/p/dobudish/downloads/list" target="_top">code.google.com</a>
|
||
|
bereitsteht.</p></li></ul></div><p>Apache Ant sowie ein dazu passendes Java Runtime Environment
|
||
|
sind auf allen gängigen Plattformen verfügbar. Beispiel für
|
||
|
Debian/Ubuntu:</p><pre class="programlisting">apt-get install ant openjdk-7-jre</pre><p>Nach dem Download von Dobudish muss Dobudish im Unterverzeichnis
|
||
|
<code class="filename">doc/build</code> entpackt werden. Beispiel unter der
|
||
|
Annahme, das <span class="productname">Dobudish</span>™ in
|
||
|
<code class="filename">$HOME/Downloads</code> heruntergeladen wurde:</p><pre class="programlisting">cd doc/build
|
||
|
unzip $HOME/Downloads/dobudish-nojre-1.1.4.zip</pre></div><div class="sect2" title="4.7.3. PDFs und HTML-Seiten erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.build"></a>4.7.3. PDFs und HTML-Seiten erstellen</h3></div></div></div><p>Die eigentliche Konvertierung erfolgt nach Installation der
|
||
|
benötigten Software mit einem einfachen Aufruf direkt aus dem
|
||
|
kivitendo-Installationsverzeichnis heraus:</p><pre class="programlisting">./scripts/build_doc.sh</pre></div><div class="sect2" title="4.7.4. Einchecken in das Git-Repository"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.repository"></a>4.7.4. Einchecken in das Git-Repository</h3></div></div></div><p>Sowohl die XML-Datei als auch die erzeugten PDF- und
|
||
|
HTML-Dateien sind Bestandteil des Git-Repositories. Daraus folgt, dass
|
||
|
nach Änderungen am XML die PDF- und HTML-Dokumente ebenfalls gebaut
|
||
|
und alles zusammen in einem Commit eingecheckt werden sollten.</p><p>Die "<code class="filename">dobudish</code>"-Verzeichnisse bzw.
|
||
|
symbolischen Links gehören hingegen nicht in das Repository.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">4.6. Stil-Richtlinien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
|
||
|
<title>4.7. Stil-Richtlinien</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s06.html" title="4.6. Die kivitendo-Test-Suite"><link rel="next" href="ch04s08.html" title="4.8. Dokumentation erstellen"></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">4.7. Stil-Richtlinien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s08.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.7. Stil-Richtlinien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.style-guide"></a>4.7. Stil-Richtlinien</h2></div></div></div><p>Die folgenden Regeln haben das Ziel, den Code möglichst gut les-
|
||
|
und wartbar zu machen. Dazu gehört zum Einen, dass der Code einheitlich
|
||
|
eingerückt ist, aber auch, dass Mehrdeutigkeit so weit es geht vermieden
|
||
|
wird (Stichworte "Klammern" oder "Hash-Keys").</p><p>Diese Regeln sind keine Schikane sondern erleichtern allen das
|
||
|
Leben!</p><p>Jeder, der einen Patch schickt, sollte seinen Code vorher
|
||
|
überprüfen. Einige der Regeln lassen sich automatisch überprüfen, andere
|
||
|
nicht.</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Es werden keine echten Tabs sondern Leerzeichen
|
||
|
verwendet.</p></li><li class="listitem"><p>Die Einrückung beträgt zwei Leerzeichen. Beispiel:</p><pre class="programlisting">foreach my $row (@data) {
|
||
|
if ($flag) {
|
||
|
# do something with $row
|
||
|
}
|
||
|
|
||
|
if ($use_modules) {
|
||
|
$row->{modules} = MODULE->retrieve(
|
||
|
id => $row->{id},
|
||
|
date => $use_now ? localtime() : $row->{time},
|
||
|
);
|
||
|
}
|
||
|
|
||
|
$report->add($row);
|
||
|
}</pre></li><li class="listitem"><p>Öffnende geschweifte Klammern befinden sich auf der gleichen
|
||
|
Zeile wie der letzte Befehl. Beispiele:</p><pre class="programlisting">sub debug {
|
||
|
...
|
||
|
}</pre><p>oder</p><pre class="programlisting">if ($form->{item_rows} > 0) {
|
||
|
...
|
||
|
}</pre></li><li class="listitem"><p>Schließende geschweifte Klammern sind so weit eingerückt wie
|
||
|
der Befehl / die öffnende schließende Klammer, die den Block
|
||
|
gestartet hat, und nicht auf der Ebene des Inhalts. Die gleichen
|
||
|
Beispiele wie bei 3. gelten.</p></li><li class="listitem"><p>Die Wörter "<code class="function">else</code>",
|
||
|
"<code class="function">elsif</code>", "<code class="function">while</code>" befinden
|
||
|
sich auf der gleichen Zeile wie schließende geschweifte Klammern.
|
||
|
Beispiele:</p><pre class="programlisting">if ($form->{sum} > 1000) {
|
||
|
...
|
||
|
} elsif ($form->{sum} > 0) {
|
||
|
...
|
||
|
} else {
|
||
|
...
|
||
|
}
|
||
|
|
||
|
do {
|
||
|
...
|
||
|
} until ($a > 0);</pre></li><li class="listitem"><p>Parameter von Funktionsaufrufen müssen mit runden Klammern
|
||
|
versehen werden. Davon nicht betroffen sind interne Perl-Funktionen,
|
||
|
und grep-ähnliche Operatoren. Beispiel:</p><pre class="programlisting">$main::lxdebug->message("Could not find file.");
|
||
|
%options = map { $_ => 1 } grep { !/^#/ } @config_file;</pre></li><li class="listitem"><p>Verschiedene Klammern, Ihre Ausdrücke und Leerzeichen:</p><p>Generell gilt: Hashkeys und Arrayindices sollten nicht durch
|
||
|
Leerzeichen abgesetzt werden. Logische Klammerungen ebensowenig,
|
||
|
Blöcke schon. Beispiel:</p><pre class="programlisting">if (($form->{debug} == 1) && ($form->{sum} - 100 < 0)) {
|
||
|
...
|
||
|
}
|
||
|
|
||
|
$array[$i + 1] = 4;
|
||
|
$form->{sum} += $form->{"row_$i"};
|
||
|
$form->{ $form->{index} } += 1;
|
||
|
|
||
|
map { $form->{sum} += $form->{"row_$_"} } 1..$rowcount;</pre></li><li class="listitem"><p>Mehrzeilige Befehle</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Werden die Parameter eines Funktionsaufrufes auf mehrere
|
||
|
Zeilen aufgeteilt, so sollten diese bis zu der Spalte eingerückt
|
||
|
werden, in der die ersten Funktionsparameter in der ersten Zeile
|
||
|
stehen. Beispiel:</p><pre class="programlisting">$sth = $dbh->prepare("SELECT * FROM some_table WHERE col = ?",
|
||
|
$form->{some_col_value});</pre></li><li class="listitem"><p>Ein Spezialfall ist der ternäre Operator "?:", der am
|
||
|
besten in einer übersichtlichen Tabellenstruktur organisiert
|
||
|
wird. Beispiel:</p><pre class="programlisting">my $rowcount = $form->{"row_$i"} ? $i
|
||
|
: $form->{oldcount} ? $form->{oldcount} + 1
|
||
|
: $form->{rowcount} - $form->{rowbase};</pre></li></ol></div></li><li class="listitem"><p>Kommentare</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>Kommentare, die alleine in einer Zeile stehen, sollten
|
||
|
soweit wie der Code eingerückt sein.</p></li><li class="listitem"><p>Seitliche hängende Kommentare sollten einheitlich
|
||
|
formatiert werden.</p></li><li class="listitem"><p>Sämtliche Kommentare und Sonstiges im Quellcode ist bitte
|
||
|
auf Englisch zu verfassen. So wie ich keine Lust habe,
|
||
|
französischen Quelltext zu lesen, sollte auch der kivitendo
|
||
|
Quelltext für nicht-Deutschsprachige lesbar sein.
|
||
|
Beispiel:</p><pre class="programlisting">my $found = 0;
|
||
|
while (1) {
|
||
|
last if $found;
|
||
|
|
||
|
# complicated check
|
||
|
$found = 1 if //
|
||
|
}
|
||
|
|
||
|
$i = 0 # initialize $i
|
||
|
$n = $i; # save $i
|
||
|
$i *= $const; # do something crazy
|
||
|
$i = $n; # recover $i</pre></li></ol></div></li><li class="listitem"><p>Hashkeys sollten nur in Anführungszeichen stehen, wenn die
|
||
|
Interpolation gewünscht ist. Beispiel:</p><pre class="programlisting">$form->{sum} = 0;
|
||
|
$form->{"row_$i"} = $form->{"row_$i"} - 5;
|
||
|
$some_hash{42} = 54;</pre></li><li class="listitem"><p>Die maximale Zeilenlänge ist nicht beschränkt. Zeilenlängen
|
||
|
unterhalb von 79 Zeichen helfen unter bestimmten Bedingungen, aber
|
||
|
wenn die Lesbarkeit unter kurzen Zeilen leidet (wie zum Biespiel in
|
||
|
grossen Tabellen), dann ist Lesbarkeit vorzuziehen.</p><p>Als Beispiel sei die Funktion
|
||
|
<code class="function">print_options</code> aus
|
||
|
<code class="filename">bin/mozilla/io.pl</code> angeführt.</p></li><li class="listitem"><p>Trailing Whitespace, d.h. Leerzeichen am Ende von Zeilen sind
|
||
|
unerwünscht. Sie führen zu unnötigen Whitespaceänderungen, die diffs
|
||
|
verfälschen.</p><p>Emacs und vim haben beide recht einfache Methoden zur
|
||
|
Entfernung von trailing whitespace. Emacs kennt das Kommande
|
||
|
<span class="command"><strong>nuke-trailing-whitespace</strong></span>, vim macht das gleiche
|
||
|
manuell über <code class="literal">:%s/\s\+$//e</code> Mit <code class="literal">:au
|
||
|
BufWritePre * :%s/\s\+$//e</code> wird das an Speichern
|
||
|
gebunden.</p></li><li class="listitem"><p>Es wird kein <span class="command"><strong>perltidy</strong></span> verwendet.</p><p>In der Vergangenheit wurde versucht,
|
||
|
<span class="command"><strong>perltidy</strong></span> zu verwenden, um einen einheitlichen
|
||
|
Stil zu erlangen. Es hat sich aber gezeigt, dass
|
||
|
<span class="command"><strong>perltidy</strong></span>s sehr eigenwilliges Verhalten, was
|
||
|
Zeilenumbrüche angeht, oftmals gut formatierten Code zerstört. Für
|
||
|
den Interessierten sind hier die
|
||
|
<span class="command"><strong>perltidy</strong></span>-Optionen, die grob den beschriebenen
|
||
|
Richtlinien entsprechen:</p><pre class="programlisting">-syn -i=2 -nt -pt=2 -sbt=2 -ci=2 -ibc -hsc -noll -nsts -nsfs -asc -dsm
|
||
|
-aws -bbc -bbs -bbb -mbl=1 -nsob -ce -nbl -nsbl -cti=0 -bbt=0 -bar -l=79
|
||
|
-lp -vt=1 -vtc=1</pre></li><li class="listitem"><p>
|
||
|
<code class="varname">STDERR</code> ist tabu. Unkonditionale
|
||
|
Debugmeldungen auch.</p><p>kivitendo bietet mit dem Modul <code class="classname">LXDebug</code>
|
||
|
einen brauchbaren Trace-/Debug-Mechanismus. Es gibt also keinen
|
||
|
Grund, nach <code class="varname">STDERR</code> zu schreiben.</p><p>Die <code class="classname">LXDebug</code>-Methode
|
||
|
"<code class="function">message</code>" nimmt als ersten Paramter außerdem
|
||
|
eine Flagmaske, für die die Meldung angezeigt wird, wobei "0" immer
|
||
|
angezeigt wird. Solche Meldungen sollten nicht eingecheckt werden
|
||
|
und werden in den meisten Fällen auch vom Repository
|
||
|
zurückgewiesen.</p></li><li class="listitem"><p>Alle neuen Module müssen use strict verwenden.</p><p>
|
||
|
<code class="varname">$form</code>, <code class="varname">$auth</code>,
|
||
|
<code class="varname">$locale</code>, <code class="varname">$lxdebug</code> und
|
||
|
<code class="varname">%myconfig</code> werden derzeit aus dem main package
|
||
|
importiert (siehe <a class="xref" href="ch04.html#devel.globals" title="4.1. Globale Variablen">Globale Variablen</a>. Alle anderen
|
||
|
Konstrukte sollten lexikalisch lokal gehalten werden.</p></li></ol></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s06.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s08.html">Weiter</a></td></tr><tr><td width="40%" align="left" valign="top">4.6. Die kivitendo-Test-Suite </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> 4.8. Dokumentation erstellen</td></tr></table></div></body></html>
|
||
| doc/html/ch04s08.html | ||
|---|---|---|
|
<html><head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>4.8. Dokumentation erstellen</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s07.html" title="4.7. Stil-Richtlinien"></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">4.8. Dokumentation erstellen</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s07.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="4.8. Dokumentation erstellen"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="devel.build-doc"></a>4.8. Dokumentation erstellen</h2></div></div></div><div class="sect2" title="4.8.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.introduction"></a>4.8.1. Einführung</h3></div></div></div><p>Diese Dokumentation ist in <span class="productname">DocBook</span>™
|
||
|
XML geschrieben. Zum Bearbeiten reicht grundsätzlich ein Text-Editor.
|
||
|
Mehr Komfort bekommt man, wenn man einen dedizierten XML-fähigen
|
||
|
Editor nutzt, der spezielle Unterstützung für
|
||
|
<span class="productname">DocBook</span>™ mitbringt. Wir empfehlen dafür den
|
||
|
<a class="ulink" href="http://www.xmlmind.com/xmleditor/" target="_top">XMLmind XML
|
||
|
Editor</a>, der bei nicht kommerzieller Nutzung kostenlos
|
||
|
ist.</p></div><div class="sect2" title="4.8.2. Benötigte Software"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.required-software"></a>4.8.2. Benötigte Software</h3></div></div></div><p>Bei <span class="productname">DocBook</span>™ ist Prinzip, dass
|
||
|
ausschließlich die XML-Quelldatei bearbeitet wird. Aus dieser werden
|
||
|
dann mit entsprechenden Stylesheets andere Formate wie PDF oder HTML
|
||
|
erzeugt. Bei kivitendo übernimmt diese Aufgabe das Shell-Script
|
||
|
<span class="command"><strong>scripts/build_doc.sh</strong></span>.</p><p>Das Script benötigt zur Konvertierung verschiedene
|
||
|
Softwarekomponenten, die im normalen kivitendo-Betrieb nicht benötigt
|
||
|
werden:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
|
||
|
<a class="ulink" href="http://www.oracle.com/technetwork/java/index.html" target="_top">Java</a>
|
||
|
in einer halbwegs aktuellen Version</p></li><li class="listitem"><p>Das Java-Build-System <a class="ulink" href="http://ant.apache.org/" target="_top">Apache Ant</a>
|
||
|
</p></li><li class="listitem"><p>Das Dokumentations-System Dobudish für
|
||
|
<span class="productname">DocBook</span>™ 4.5, eine Zusammenstellung
|
||
|
diverser Stylesheets und Grafiken zur Konvertierung von
|
||
|
<span class="productname">DocBook</span>™ XML in andere Formate. Das
|
||
|
Paket, das benötigt wird, ist zum Zeitpunkt der
|
||
|
Dokumentationserstellung
|
||
|
<code class="filename">dobudish-nojre-1.1.4.zip</code>, aus auf <a class="ulink" href="http://code.google.com/p/dobudish/downloads/list" target="_top">code.google.com</a>
|
||
|
bereitsteht.</p></li></ul></div><p>Apache Ant sowie ein dazu passendes Java Runtime Environment
|
||
|
sind auf allen gängigen Plattformen verfügbar. Beispiel für
|
||
|
Debian/Ubuntu:</p><pre class="programlisting">apt-get install ant openjdk-7-jre</pre><p>Nach dem Download von Dobudish muss Dobudish im Unterverzeichnis
|
||
|
<code class="filename">doc/build</code> entpackt werden. Beispiel unter der
|
||
|
Annahme, das <span class="productname">Dobudish</span>™ in
|
||
|
<code class="filename">$HOME/Downloads</code> heruntergeladen wurde:</p><pre class="programlisting">cd doc/build
|
||
|
unzip $HOME/Downloads/dobudish-nojre-1.1.4.zip</pre></div><div class="sect2" title="4.8.3. PDFs und HTML-Seiten erstellen"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.build"></a>4.8.3. PDFs und HTML-Seiten erstellen</h3></div></div></div><p>Die eigentliche Konvertierung erfolgt nach Installation der
|
||
|
benötigten Software mit einem einfachen Aufruf direkt aus dem
|
||
|
kivitendo-Installationsverzeichnis heraus:</p><pre class="programlisting">./scripts/build_doc.sh</pre></div><div class="sect2" title="4.8.4. Einchecken in das Git-Repository"><div class="titlepage"><div><div><h3 class="title"><a name="devel.build-doc.repository"></a>4.8.4. Einchecken in das Git-Repository</h3></div></div></div><p>Sowohl die XML-Datei als auch die erzeugten PDF- und
|
||
|
HTML-Dateien sind Bestandteil des Git-Repositories. Daraus folgt, dass
|
||
|
nach Änderungen am XML die PDF- und HTML-Dokumente ebenfalls gebaut
|
||
|
und alles zusammen in einem Commit eingecheckt werden sollten.</p><p>Die "<code class="filename">dobudish</code>"-Verzeichnisse bzw.
|
||
|
symbolischen Links gehören hingegen nicht in das Repository.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s07.html">Zurück</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Nach oben</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">4.7. Stil-Richtlinien </td><td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
|
||
| doc/html/index.html | ||
|---|---|---|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
<title>kivitendo 3.5.3: Installation, Konfiguration, Entwicklung</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.5.3: Installation, Konfiguration, Entwicklung"><link rel="next" href="ch01.html" title="Kapitel 1. Aktuelle Hinweise"></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">kivitendo 3.5.3: Installation, Konfiguration,
|
||
|
Entwicklung</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch01.html">Weiter</a></td></tr></table><hr></div><div lang="de" class="book" title="kivitendo 3.5.3: Installation, Konfiguration, Entwicklung"><div class="titlepage"><div><div><h1 class="title"><a name="kivitendo-documentation"></a>kivitendo 3.5.3: Installation, Konfiguration,
|
||
|
Entwicklung</h1></div></div><hr></div><div class="toc"><p><b>Inhaltsverzeichnis</b></p><dl><dt><span class="chapter"><a href="ch01.html">1. Aktuelle Hinweise</a></span></dt><dt><span class="chapter"><a href="ch02.html">2. Installation und Grundkonfiguration</a></span></dt><dd><dl><dt><span class="sect1"><a href="ch02.html#Installation-%C3%9Cbersicht">2.1. Übersicht</a></span></dt><dt><span class="sect1"><a href="ch02s02.html">2.2. Benötigte Software und Pakete</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s02.html#Betriebssystem">2.2.1. Betriebssystem</a></span></dt><dt><span class="sect2"><a href="ch02s02.html#Pakete">2.2.2. Benötigte Perl-Pakete installieren</a></span></dt><dt><span class="sect2"><a href="ch02s02.html#d0e574">2.2.3. Andere Pakete installieren</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s03.html">2.3. Manuelle Installation des Programmpaketes</a></span></dt><dt><span class="sect1"><a href="ch02s04.html">2.4. kivitendo-Konfigurationsdatei</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s04.html#config.config-file.introduction">2.4.1. Einführung</a></span></dt><dt><span class="sect2"><a href="ch02s04.html#config.config-file.sections-parameters">2.4.2. Abschnitte und Parameter</a></span></dt><dt><span class="sect2"><a href="ch02s04.html#config.config-file.prior-versions">2.4.3. Versionen vor 2.6.3</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s05.html">2.5. Anpassung der PostgreSQL-Konfiguration</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s05.html#Zeichens%C3%A4tze-die-Verwendung-von-UTF-8">2.5.1. Zeichensätze/die Verwendung von Unicode/UTF-8</a></span></dt><dt><span class="sect2"><a href="ch02s05.html#%C3%84nderungen-an-Konfigurationsdateien">2.5.2. Änderungen an Konfigurationsdateien</a></span></dt><dt><span class="sect2"><a href="ch02s05.html#Erweiterung-f%C3%BCr-servergespeicherte-Prozeduren">2.5.3. Erweiterung für servergespeicherte Prozeduren</a></span></dt><dt><span class="sect2"><a href="ch02s05.html#Erweiterung-f%C3%BCr-trigram">2.5.4. Erweiterung für Trigram Prozeduren</a></span></dt><dt><span class="sect2"><a href="ch02s05.html#Datenbankbenutzer-anlegen">2.5.5. Datenbankbenutzer anlegen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s06.html">2.6. Webserver-Konfiguration</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s06.html#d0e1042">2.6.1. Grundkonfiguration mittels CGI</a></span></dt><dt><span class="sect2"><a href="ch02s06.html#Apache-Konfiguration.FCGI">2.6.2. Konfiguration für FastCGI/FCGI</a></span></dt><dt><span class="sect2"><a href="ch02s06.html#d0e1193">2.6.3. Authentifizierung mittels HTTP Basic Authentication</a></span></dt><dt><span class="sect2"><a href="ch02s06.html#d0e1209">2.6.4. Weitergehende Konfiguration</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s07.html">2.7. Der Task-Server</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s07.html#Konfiguration-des-Task-Servers">2.7.1. Verfügbare und notwendige Konfigurationsoptionen</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Konfiguration-der-Mandanten-fuer-den-Task-Servers">2.7.2. Konfiguration der Mandanten für den Task-Server</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Einbinden-in-den-Boot-Prozess">2.7.3. Automatisches Starten des Task-Servers beim Booten</a></span></dt><dt><span class="sect2"><a href="ch02s07.html#Prozesskontrolle">2.7.4. Wie der Task-Server gestartet und beendet wird</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s08.html">2.8. Benutzerauthentifizierung und Administratorpasswort</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s08.html#Grundlagen-zur-Benutzerauthentifizierung">2.8.1. Grundlagen zur Benutzerauthentifizierung</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Administratorpasswort">2.8.2. Administratorpasswort</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Authentifizierungsdatenbank">2.8.3. Authentifizierungsdatenbank</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Passwort%C3%BCberpr%C3%BCfung">2.8.4. Passwortüberprüfung</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Name-des-Session-Cookies">2.8.5. Name des Session-Cookies</a></span></dt><dt><span class="sect2"><a href="ch02s08.html#Anlegen-der-Authentifizierungsdatenbank">2.8.6. Anlegen der Authentifizierungsdatenbank</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s09.html">2.9. Mandanten-, Benutzer- und Gruppenverwaltung</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s09.html#Zusammenh%C3%A4nge">2.9.1. Zusammenhänge</a></span></dt><dt><span class="sect2"><a href="ch02s09.html#Mandanten-Benutzer-Gruppen">2.9.2. Mandanten, Benutzer und Gruppen</a></span></dt><dt><span class="sect2"><a href="ch02s09.html#Datenbanken-anlegen">2.9.3. Datenbanken anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s09.html#Gruppen-anlegen">2.9.4. Gruppen anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s09.html#Benutzer-anlegen">2.9.5. Benutzer anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s09.html#Mandanten-anlegen">2.9.6. Mandanten anlegen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s10.html">2.10. Drucker- und Systemverwaltung</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s10.html#Druckeradministration">2.10.1. Druckeradministration</a></span></dt><dt><span class="sect2"><a href="ch02s10.html#System">2.10.2. System sperren / entsperren</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s11.html">2.11. E-Mail-Versand aus kivitendo heraus</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s11.html#config.sending-email.sendmail">2.11.1. Versand über lokalen E-Mail-Server</a></span></dt><dt><span class="sect2"><a href="ch02s11.html#config.sending-email.smtp">2.11.2. Versand über einen SMTP-Server</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s12.html">2.12. Drucken mit kivitendo</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s12.html#Vorlagenverzeichnis-anlegen">2.12.1. Vorlagenverzeichnis anlegen</a></span></dt><dt><span class="sect2"><a href="ch02s12.html#Vorlagen-RB">2.12.2. Der Druckvorlagensatz RB</a></span></dt><dt><span class="sect2"><a href="ch02s12.html#f-tex">2.12.3. f-tex</a></span></dt><dt><span class="sect2"><a href="ch02s12.html#Vorlagen-rev-odt">2.12.4. Der Druckvorlagensatz rev-odt</a></span></dt><dt><span class="sect2"><a href="ch02s12.html#allgemeine-hinweise-zu-latex">2.12.5. Allgemeine Hinweise zu LaTeX Vorlagen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s13.html">2.13. OpenDocument-Vorlagen</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s13.html#d0e2374">2.13.1. OpenDocument (odt) Druckvorlagen mit Makros</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s14.html">2.14. Nomenklatur</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch02s14.html#booking.dates">2.14.1. Datum bei Buchungen</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch02s15.html">2.15. Konfiguration zur Einnahmenüberschussrechnung/Bilanzierung:
|
||
Auch abrufbar als: Unified diff
Dokumentation: HTML & PDF gebaut