HSWO_BSC_BACHELORS_THESIS/chapters/konzeption-entwicklung.tex

\chapter{Umsetzung}
\label{chap:umsetzung}
Infolge der Anforderungsanalyse befasst sich das Kapitel \enquote{Umsetzung} mit der Implementation der Anforderungen in dem
Brown-Field Projekt \cite{bib:schwarzer-vorlesung-swa} in Form einer TYPO3-Extension.

\section{Setup einer TYPO3-Extension}
TYPO3-Extensions werden via Composer installiert \cite{bib:typo3-docs-managing-extensions}.
Um eine TYPO3-Extension zu erstellen, muss also ein Composer-Paket erstellt werden.
Um vermeidbare Komplexität zu verhindern, wird das Composer-Paket, welches die hier betrachtete
TYPO3-Extension darstellt, lokal in den versionierten Ordner \enquote{packages} gelegt.
Dieses Verzeichnis wird als Quelle für Composer-Pakete in der
Haupt-composer.json-Datei hinterlegt.
Somit wird ein Composer-Paket nur für dieses Projekt bereitgestellt,
ohne den Aufwand zu haben, der üblicherweise mit dem Bereitstellen eines Paketes einhergeht.
\\
\\
Um das grundlegende Setup einer Extension effizient durchzuführen, wurde eine
existierende Extension mit vergleichbarem Funktionsumfang kopiert, umbenannt und eingefügt.
Spezifisch ist der \enquote{vergleichbare Funktionsumfang}, dass es Datenmodelle und hochpersonalisierte
Frontendlogik in Bezug auf die zuvor genannten Datenmodelle gibt.

\section{Digitization}
Die Phase der Digitazion nach Verhoef et al. befasst sich mit der digitalen Abbildung von Objekten der realen Welt
in einer Art und Weise, sodass diese elektronisch weiterverarbeitet werden können \cite{bib:verhoef, bib:dougherty, bib:loebbecke}.
Das bedeutet, dass in dieser Phase Datenobjekte definiert und implementiert werden.
Ein Datenobjekt besteht nach firmeninternen Konventionen aus zumindest
vier Komponenten:
\begin{description}
  \item{Datenbanktabelle} \\
    Die Datenbanktabelle persistiert Informationen.
  \item{Domain Model} \\
    Das Domain Model (auch Model genannt) ist eine PHP-Klasse,
    die jeweils die Daten einer Zeile der Datenbanktabelle abbildet.
  \item{Repository} \\
    Ein Repository ist eine PHP-Klasse, die die Schnittstelle
    zwischen der Datenbank und der Model-Klasse darstellt.
  \item{\ac{TCA}} \\
    Der \ac{TCA} des Modells definiert, wie diese Objekte im TYPO3-Backend dargestellt werden
    und bearbeitbar sind.
\end{description}
\cite{bib:typo3-docs-extbase-reference}.

Im Folgenden wurde ein semiformales Diagramm der Objekte und ihren Relationen
angefertigt und in Rücksprache mit dem \ac{PO} finalisiert.

\begin{nicepic}
    \includegraphics[width=1\textwidth]{images/objektrelationen-weinlandmosel-einlieferungswerkzeug.png}
    \captionof{figure}{Objektrelationen}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:objektrelationen}
\end{nicepic}

Nachdem in Erfahrung gebracht wurde, welche konkreten Datenobjekte benötigt werden,
wurden Attribute dieser Objekte dem Pflichtenheft entnommen. Diese wurden in einem
formalen Klassendiagramm festgehalten und in Rücksprache mit dem \ac{PO}
weiter bis zu festen Datentypen und Auswahlmöglichkeiten konkretisiert.
Beispielsweise, dass Wettbewerbskategorien durch TYPO3-Categories repräsentiert werden sollen.
Das hat den Vorteil, dass TYPO3-Categories bereits native Bestandteile eines TYPO3-Redaktionssystemes sind
und alle relevanten Attribute anbieten. Diese sind ein Titel,
eine Parentkategorie und eine Beschreibung.
Das Parent-Attribut ist benötigt, da $n$ dieser Attribute einen Attributbaum bilden
\cite{bib:typo3-docs-sys-category}.
Somit ist es möglich, Unterkategorien zu erstellen. Beispiele hierfür sind die
Unterkategorien \enquote{Trockener Riesling} und \enquote{Halbtrockener Riesling} für die Überkategorie
\enquote{Riesling}.
Rebsorten, Geschmack, Weineigenschaften und Qualität sollen eigene Datentypen
anstatt einfacher Zeichenfolgen sein.
Ziel davon ist, dass sich Nutzer für einen vorgefertigten, nominalen Eintrag in einem Dropdown-Menü
entscheiden müssen und diese Auswahlmöglichkeiten immer noch im TYPO3-Backend pflegbar sind.
Weinlagen sind im Brown-Field-Projekt bereits vorhanden, also sollen hierfür existierenden Daten
eingebunden werden.
Pro Wein sollen beliebig viele Weineigenschaften auswählbar sein, Wettbewerbskategorien,
Geschmacksrichtung, etc, jeweils nur ein Element.
Weitere Notizen zu diesem Gespräch sind im Anhang unter \fullref{chap:anhang-notizen-digitization}
zu finden.
\\
\\
Da das Klassendiagramm gegeben lesbare Schrift nicht auf eine Textseite passt,
befindet es sich vollseitig im Anhang unter \fullref{chap:anhang-class-diagram}.
Die weitere Implementation der Datenobjekte ist unkompliziert und besteht hauptsächlich aus
repetitivem Schreiben von SQL-Tabellen, Domain-Model-Klassen und \acp{TCA}.
Um $m,n$-Beziehungen wie Beispielsweise der Menge der für eine Probe zugelassenen Kategorien
\enquote{allowedCategories} zwischen $m$ \enquote{Jahresauswahlprobe}-Objekten und
$n$ \enquote{Category}-Objekten zu ermöglichen, werden MM-Tabellen (many-to-many) benötigt,
diese Beziehungen in Form zweier Foreign Keys speichern.
Die Repository-Klassen können \enquote{leer} gelassen werden,
da zu diesem Zeitpunkt keine erweiterte Auswahllogik für Datenbankanfragen benötigt wird.
Wichtig ist hierbei, dass eine Repository-Klasse existiert. Alle unverzichtbaren
Schnittstellen werden über die Basisklasse \enquote{Repository} geerbt
\cite{bib:typo3-docs-extdev-tut-tea-repositories}.
Mit Abschluss der Digitization können alle Datenstrukturen im TYPO3-Backend händisch angelegt,
eingesehen, gelöscht und bearbeitet werden.


\section{Digitalization}
In der Phase \textit{Digitalization} werden bestehende Geschäftsprozesse so verändert,
dass mit digitalen Werkzeugen und Datenmodellen gearbeitet werden kann \cite{bib:fengli}.
Damit baut diese Phase auf der vorherigen Phase \enquote{Digitization} auf, um mit den dort
implementierten Datenmodellen zu arbeiten. Im Folgenden werden die Umsetzungen der
erforderlichen Geschäftsprozesse beschrieben.

\subsection{Teilnehmerregistrierung}
Ein essenzieller Teil des Jahresauswahlprobenwerkzeuges ist die Registrierung von Teilnehmern.
Dieses Modul repräsentiert den ersten Berührungspunkt der Winzer mit dem System.
Hiervon profitiert \ac{WM}, weil registrierte Benutzer der Webseite eine Grundvorausetzung
für die Onlineregistrierung von Weinen zu \acp{JAP} sind.
Dem Pflichtenheft ist zu entnehmen, dass es zwei Kategorien von Teilnehmerregistrierungen gibt:
\begin{enumerate}
  \item Nutzer ist \ac{WM}-Mitglied
  \item Nutzer ist kein \ac{WM}-Mitglied
\end{enumerate}
Der primäre Unterschied zwischen Mitgliedern und Nicht-Mitgliedern ist, dass Mitglieder bereits einen
Stammdatensatz hinterlegt haben.
Dieser Stammdatensatz bildet die Angaben zum Weingut des zu digitalisierendem Anmeldeformulares ab.
Nicht-Mitglieder sind dem System noch gänzlich unbekannt und müssen im Zuge der Registrierung ihres Nutzers
ihre Stammdaten angeben, während sich Mitglieder lediglich einloggen müssen und eine Schaltfläche
\enquote{Teilnehmer werden} betätigen.
Der mit dem \ac{PO} ausgearbeitete UX-Flow der Registrierung sieht vor, dass der Nutzer zunächst gefragt wird,
ob er Mitglied sei oder nicht. Hierzu gibt es je einen Button. Ist der Nutzer ein Mitglied,
wird er auf ein Loginform, mit der Option zur Registrierung weitergeleitet.
Nach erfolgreichem Login, wird ein Teilnehmerobjekt erstellt.
Wählt der Nutzer \enquote{Nein, ich bin kein Mitglied} aus, würde er auf ein Registrierungsformular
weitergeleitet, auf um sich einen Nicht-Mitgliederaccount anzulegen. Im Zuge dieser Registrierung werden
Stammdaten zum Weingut angefragt.
Dieser Schritt übersetzt unter anderem den \enquote{Einreicher}-Teil des ursprünglichen Anmeldeformulares,
anbei in \fullref{chap:anhang-anmeldeformular}.

\begin{nicepic}
    \includegraphics[width=0.9\textwidth]{images/ux-flow-registrierung.png}
    \captionof{figure}{UX-Flow: Registrierung}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:uxflow-registrierung}
\end{nicepic}

Da das Brown-Field-Projekt bereits Accountlogins und -Registrierungen implementiert und nutzt,
werden auf diese Lösungen zurückgegriffen, um einen einheitlichen Workflow beizubehalten. Accountregistrierungen werden über den
\enquote{femanager} \cite{bib:typo3-docs-femanager} realisiert, während Logins via TYPO3's nativem
Frontend-Nutzer-Login gelöst werden. Das ist explizit von femanager so angedacht:
\quotecite{Note: Login and a I forgot my password function is part of the core and not part of femanager.}
\cite{bib:typo3-docs-femanager}.

Im Folgenden wird der Registrierungsprozess im Detail beschrieben:\\
Grundlegend gibt es drei relevante Nutzerzustände vor der Registrierung:
\begin{enumerate}
  \item Kein Mitglied
  \item Mitglied, mit Konto
  \item Mitglied, ohne Konto
\end{enumerate}

Diese Prozesse sehen wie folgt aus:
\subsubsection*{Kein Mitglied}
Ist ein Nutzer kein Mitglied, so muss er zunächst einen Account erstellen.
Anfangs wählt dieser Nutzer \enquote{Ich bin kein Mitglied} auf der Registrierungsseite aus.
Daraufhin navigiert der Browser zu einem Registrierungs-Formular.
Hierfür muss eine Email-Adresse und ein Passwort vergeben und den Nutzungsbestimmungen zugestimmt werden.
Im Anschluss erhält der Nutzer eine Bestätigungsemail mit einem Aktivierungslink.
Wird dieser Link geöffnet, wird der Account freigeschalten und ein Login-Feld erscheint.
Nach erfolgreichem Login wird der Nutzer mit einem
Stammdatenformular konfrontiert. Dabei handelt es sich um Angaben zum teilnehmenden Weingut.
Wird dieses Formular abgeschickt, ist die Teilnehmerregistrierung abgeschlossen.

\subsubsection*{Mitglied, mit Konto}
Ist ein Nutzer ein Weinland-Mosel-Mitglied und hat bereits ein Mitgliedskonto, muss dieser auf der Registrierungsseite
\enquote{Ich bin ein Mitglied} auswählen. An dieser Stelle navigiert der Browser zu einem Login-Formular.
Hier kann sich das Mitglied anmelden. Tut es dies erfolgreich, erstellt der Controller einen neuen
Teilnehmer-Eintrag für den Frontend-Nutzer und fügt den Frontend-Nutzer der Nutzergruppe \enquote{Teilnehmer} hinzu.
Damit ist die Teilnehmerregistrierung abgeschlossen.

\subsubsection*{Mitglied, ohne Konto}
Ist ein Nutzer ein Mitglied und hat noch kein Mitgliedskonto, muss dieser auf der Registrierungsseite
\enquote{Ich bin ein Mitglied} auswählen. An dieser Stelle navigiert der Browser zu einem Login-Formular.
Auf diesem Login-Formular existiert ein Button \enquote{Jetzt registrieren}, sowie ein Hinsweistext dazu.
Da der Nutzer noch keinen Account hat, muss dieser auf \enquote{Jetzt registrieren} klicken.
Daraufhin navigiert der Browser zu einem Registrierungsformular, das eine Email-Adresse, ein Passwort
und die Zustimmung zur Datenverarbeitung benötigt. Ist dieses Formular abgeschickt, erhält das Mitglied
eine Email mit einem Bestätigungslink. Wird dieser Bestätigungslink angeklickt, wird das Mitgliedskonto
freigegeben und es öffnet sich ein Login-Formular, beschrieben in \enpointy{Mitglied, mit Konto}.

\subsubsection*{Umsetzung}
Zunächst wurde ein simples Weichen-Content-Element erstellt.
Dieses Content-Element hat die Parameter \enquote{question}, \enquote{answ-1-link}, \enquote{answ-1-text},
\enquote{answ-2-link} sowie \enquote{answ-2-text}.
Der Zweck dieses Content-Elementes ist es, Nutzer basierend auf einer ausformilierten Frage auf eine
von zwei Seiten weiterzuleiten. Anschließend wurden Registrierungen über Femanager-Plugin-Content-Elemente
realisiert.
Anpassungen der versendeten Emails erfolgen durch Überschreiben der Email-Templates von Femanager.
Weiterleitungen zu bestimmten Seiten nachdem ein Nutzer spezielle Events ausgelöst hat können über TypoScript
konfiguriert werden \cite{bib:typo3-docs-femanager}. Logins werden über das TYPO3-Native Loginformular
gelöst. Im TYPO3-Loginformular kann man Weiterleitungen zu spezialisierten Seiten im Backend-UI festlegen
\cite{bib:typo3-docs-felogin}.
Für alle funktionalen Belange wurde ein TYPO3-Plugin registriert. Dieses Plugin verfügt über einen
ActionController, der Nutzeranfragen an PHP-Funktionen (\enquote{Actions})
bindet.
In diesen Actions wird Fehlerbehandlung durchgeführt, Datenmodelle der Domäne erstellt und in der
Datenbank persistiert sowie Daten für die Anzeige im Frontend aufbereitet \cite{bib:typo3-docs-extbase}.
Neue Datenobjekte werden in Repositories registriert \cite{bib:typo3-docs-extdev-tut-tea-repositories}. Diese Repositories sind Aggregate des Controllers,
werden jedoch nach dem \enquote{Inversion of Control}-Prinzip via Dependency Injection instanziiert und
der ActionController-Klasse über Methode übergeben \cite{bib:typo3-docs-di}.
Als problematisch erweisen sich bidirektionale Verbindungen zwischen Datenmodellen, wenn die Foreign Keys
über das SQL-Schlüsselwort \enquote{AUTO\_INCREMENT} in der Datenbank definiert werden.
In diesem Fall wollen wir
einen MasterRecord, der Betriebsinformationen speichert, bidirektional an ein Teilnehmerobjekt linken.
Als ForeignKeys werden hierfür ihre jeweiligen Uids herangezogen, da diese Werte durch
\enquote{AUTO\_INCREMENT} auf der Datenbankebene gehandhabt werden.
Es gilt also, dass ein MasterRecord $a$ die TeilnehmerUid von einem Teilnehmer $b$ hält und dass
$b$ die MasterRecordUid von $a$ hält.
Die Problematik hierbei ist, dass diese Uids erst nach dem persistieren in der Datenbank bekannt sind,
da diese Werte erst im Zuge der Persistierung erstellt werden. Das ist so, da das
\enquote{AUTO\_INCREMENT}-Schlüsselwort lediglich zu SQL gehört und SQL nur von der Datenbank ausgeführt wird.
Die Lösung hierfür ist es, beide Elemente zu erstellen und zu persistieren, danach ihre Uids gegenseitig
bekannt machen um sie danach erneut zu persistieren.

\subsection{Weinregistrierung}
Ein Basismerkmal des Jahresauswahlprobenwerkzeuges ist die Möglichkeit, Weine zu Jahresauswahlproben
anzumelden. Dieser Schritt übersetzt unter anderem die verbleibenden Formfelder des
ursprünglichen Anmeldeformulares, anbei in \fullref{chap:anhang-anmeldeformular} in den digitalen Workflow.
Für die Weinanmeldung spielt die Mitgliedsschaft eines Teilnehmers keine Rolle. Es wird lediglich ein
Frontend-Nutzer der Nutzergruppe \enquote{Teilnehmer} benötigt. Dieser Nutzer hat, wenn angemeldet,
Zugriff auf eine Auflistung aller zeitlich freigegebenen Jahresauswahlproben.
Soweit der Registrierungszeitraum dieser Jahresauswahlprobe den aktuellen Zeitpunkt miteinschließt,
wird eine \enquote{Jetzt Wein anmelden}-Schaltfläche angeboten.
Dadurch, dass Anmeldeformulare elektronisch und automatisiert verarbeitet werden, sinkt der Aufwand,
der seitens \ac{WM} für Anmeldungen gestemmt werden muss. Das ist so, da diese Formular nun nicht mehr von
Mitarbeitern bearbeitet werden müssen. Davon profitiert \ac{WM}, da diese Zeit nun anderweitig genutzt werden kann.

\begin{nicepic}
    \includegraphics[width=0.9\textwidth]{images/ux-flow-teilnahme.png}
    \captionof{figure}{UX-Flow: Weinanmeldung}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:uxflow-weinanmeldung}
\end{nicepic}

\subsubsection*{IT-Sicherheit}
Es ist wichtig zu erwähnen, dass solche Überprüfungen,
wie das Aktivsein eines Registrierungszeitraumes einer \ac{JAP}, grundsätzlich im Backend, d.h. serverseitig
auf der betroffenen Webseite (in diesem Beispiel der Weinanmeldungsseite) durchgeführt werden.
Das Verstecken der zugehörigen
Schaltfläche im Frontend dient lediglich der User-Experience und stellt keine Sicherheitsvorkehrung dar.
Das ist essenziell, da eine URL, auch wenn für sie keine Schaltfläche existiert, dennoch aufgerufen werden kann.
Da Jahresauswahlprobennummern (\acp{UID}) fortlaufend sind, ist es trivial URLs für Weinanmeldungen
beliebiger Jahresauswahlproben herzuleiten. Insofern ist es von großer Wichtigkeit sicherzustellen,
dass der Server solche Anfragen grundsätzlich selbst prüft und gegebenenfalls verneint.

\subsubsection*{Das Formular}
Aufgrund dessen, dass TYPO3 die Fluid Templating Engine verwendet \cite{bib:typo3-fluid},
werden Formulare und Formfelder mit den entsprechenden Fluid-Form-ViewHelpern aufgebaut.
Diese ViewHelper repräsentieren und erstellen gleichnamige HTML-Tags und fügen diesen spezielle
Attribute zur Identifizierung in Submit-Aufrufen hinzu \cite{bib:typo3-docs-fluid-form-viewhelpers}.
Grundsätzlich entstehen hierbei drei Kategorien von Werten, die es im Formular abzubilden gilt:

\paragraph*{Inputfelder} sind triviale Formfelder, die nicht durch andere Datensätze beschränkt werden.
Beispiele für Inputfelder sind: Weinbeschreibung, Jahrgang und Alkoholgehalt.
Inputfelder wurden mit simplen Input-Tags umgesetzt und erhielten nach Bedarf \textit{required} und
\textit{pattern}-Attribute. Diese Attribute beschreiben jeweils, ob ein Formfeld ein Pflichtfeld ist und
mit welcher Regular Expression der Formfeldinhalt abzugleichen ist \cite{bib:w3schools-input}.
Die Formfeldwerte können unverändert in der Datenbank persistiert werden.

\paragraph*{SelectSingle} sind Formfelder, die dem Nutzer eine Auswahl aus $n$ Elementen aus
anderen Datenbanktabellen geben. Der Nutzer muss sich für genau ein Element entscheiden.
Beispiele für SelectSingle-Formfelder sind: Weinlage, Qualitätsstufe, Rebsorte und Geschmacksangabe.
SelectSingle-Formfelder werden durch Select-HTML-Tags abgebildet. Der TYPO3-Form-ViewHelper für
\enquote{Select} akzeptiert eine Liste an Auswahlmöglichkeiten und erstellt selbstständig Option-HTML-Tags
für diese.
Die Formfeldwerte von SelectSingle-Formfeldern sind die
\acp{UID} des jeweils ausgewähltem Elementes \cite{bib:typo3-docs-fluid-form-viewhelpers}.
\\
\\
Aufgrund dessen, dass das Weinlagen-Drop-Down-Menü über 170 Einträge führt, wurde eine Suchmöglichkeit implementiert. Diese ist lediglich ein Textfeld, das bei jeder Eingabe allen Option-Tags der Weinlage,
deren Anzeigewert nicht der Suche entspricht, das Stilattribut \enquote{display: none;} auferlegt.
Somit sind diese nicht mehr sichtbar.
\\
\\
Eine komplexe Ausnahme stellt das SelectSingle-Formfeld \enquote{Category} dar, da TYPO3-Kategorien
Baumstrukturen sind \cite{bib:typo3-docs-sys-category}.
Um die Eltern-Kind-Beziehung der Baumstruktur erstichtlich zu machen, werden die Option-HTML-Tags einzeln rekursiv gerendert. Zunächst werden sämtliche Kategorien, deren
\ac{PID} 0 ist, dargestellt. Diese Elemente sind direkte Kinder des unsichtbaren Wurzelelementes. Für jede dieser Kategorien $a$ wird nun ein
Fluid-Partial aufgerufen,
das alle Kategorien $b$ darstellt, für die gilt: $b.pid = a.uid$. Diese Darstellung erfolgt durch einen erneuten rekursiven Aufruf dieses Partials.
In jeder Darstellung wird der Kategoriename, geprefixt mit
$n$ Leerzeichen, dargestellt, mit $n = Rekursionstiefe$. Somit entsteht ein Drop-Down-Menü, das
alle Kategorien in einer eindimensionalen Liste darstellt. Diese Liste ist nach einer Preorder-Traversierung
des Kategoriebaumes sortiert und desto tiefer ein Element im Baum ist, desto weiter ist es eingerückt.
Damit sieht das Drop-Down-Menü aus wie eine Baumstruktur.
\\
\\
Diese Herangehensweise erzeugt schlüssigen und lesbaren Programmcode und lässt sich unkompliziert umsetzen.
Das senkt Entwicklungskosten und erhöht den Profit des Endkunden, da hierdurch weniger Zeit aufgewandt wird.
Rekursiv aufgerufene For-Schleifen, die sich selbst erneut für alle Elemente aufrufen,
können jedoch zu einem Performanzproblem führen \cite{bib:schwarzer-vorlesung-alg}.
Daher wird im Folgenden die Zeitkomplexität dieser Rekursionsfunktion betrachtet.
Grundlegend, kann für diese Funktion kein Master-Theorem angewandt werden,
da es sich hierbei nicht um einen Divide-and-Conquer-Algorithmus handelt \cite{bib:schwarzer-vorlesung-alg}.
Das ist so, da das in der Rekursion weitergereichte Problem nicht kleiner wird,
sondern gleich groß bleibt.
Das verletzt die Bedingung $b>1$ des Master-Theorem, dargestellt als $T(n) = a*T(\frac{n}{b})+f(n)$.
Betrachten wir den Algortihmus, besteht er aus $m, m \in \mathbb{N}$ verschachtelten For-Schleifen
gleicher Länge.
Somit ist die Zeitkomplexität $O(n^m)$. Normiert dargestellt beträgt die Zeitkomplexität $O(n^2)$. Das lässt sich experimentell bestätigen.

\begin{nicepic}
    \includegraphics[width=0.70\textwidth]{images/timecomplexity-category.png}
    \captionof{figure}{Stichprobenartige Laufzeitanalyse des\\Kategorie-Renderers, gegenüber einer\\ quadratischen Kurve}
    \caption*{Quelle: Eigene Darstellung}
    \label{fig:timecomplexity-category}
\end{nicepic}


Auf Optgroup-HTML-Tags wurde bewusst verzichtetet.
Grund dafür ist, dass Optgroup-Titel an sich nicht als Option auswählbar sind.
Das stellt ein Problem dar, da beispielsweise die Kategorie \enquote{Riesling},
die die Unterkategorien \enquote{Trockener Riesling} und \enquote{Halbtrockener Riesling} beinhalten könnte,
auch direkt auswählbar sein sollte. Zudem besitzen Kategorie-Elemente kein Attribut das auf die Präsenz
von Unterkategorien hindeutet \cite{bib:typo3-docs-sys-category}, womit eine Unterscheidung zwischen
Baumblättern und -Zweigen nicht ohne weiteres möglich ist. Diese Entscheidung wäre jedoch
benötigt, um zwischen einem Optgroup-Tag und einem Option-Tag abzuwägen.

\paragraph*{SelectMultiple} sind Formfelder, die dem Nutzer eine Auswahl aus $n$ Elementen aus einer anderen
Datenbanktabelle geben. Der Nutzer kann sich für eine beliebige Anzahl dieser, eingeschlossen null, entscheiden.
Ein Beispiel für SelectMultiple-Formfelder ist: Weineigenschaften.
TYPO3-Fluid implementiert hierfür keinen ViewHelper \cite{bib:typo3-docs-fluid-form-viewhelpers},
also wurde eine eigene Lösung entworfen: Der Nutzer soll aus einer Menge $A$ wählen.
Für alle Elemente $a \in A$
wird ein Checkbox-Feld erstellt. Dieses Element trägt den Anzeigewert \enquote{<a.title>} und den
Wert \enquote{<formfeldname>-true}.
Ist also eine dieser Checkboxen angehakt, hat sie den zuvor genannten Wert. Falls nicht, trägt sie keinen Wert.
Weil alle angehakten Checkboxen dieses Formfeldes den selben Wert tragen, ist es PHP-Seitig trivial
eine Liste aller angehakten Checkbox-Ids dieses Formfeldes aus der Liste aller Formfeldparameter zu extrahieren.
Hierfür wird die eingebaute PHP-Funktion \enquote{array\_keys} verwendet. Diese Funktion gibt alle
Keys eines Arrays in Form eines numerisch indizierten Arrays zurück.
Der optionale Parameter \enquote{filter\_values} bestimmt, dass ausschließlich die Keys
der Key-Value-Pairs, die einen bestimmten
Wert tragen, extrahiert werden \cite{bib:php-array-keys}. D.h., der Funktionsaufruf filtert alle Keys und somit alle
Formfeld-IDs des Formfeldparameter-Arrays heraus, die den Wert \enquote{<formfeldname>-true} haben. Das ist eine Liste
aller Formfeld-IDs der Checkboxen des SelectMultiples, die angehakt wurden.
Mit der eingebauten PHP-Funktion \enquote{array\_map} wenden wir nun eine Operation auf alle Schlüssel
der Liste an, die \enquote{strlen('formfeldname-')} Zeichen, von links ausgehend, von der Formfeld-ID
entfernt. Somit wird beispielsweise die Formfeld-ID \enquote{winekind-18} zu \enquote{18} transformiert. Übrig bleiben die \acp{UID} aller angehakten Elemente $a$, in Form einer Zeichenkente.
Über die eingebaute PHP-Funktion \enquote{intval} ist es trivial diese zu Zahlen zu übersetzen,
wodurch die tatsächlichen Objekte aus der Datenbank angefragt werden können.

\subsection{PDF- und QR-Code-Generierung}
Das dynamische Erstellen und Ausgeben des Versandbeilageblattes als PDF ist ein essenzieller Bestandteil des
Jahresauswahlprobenwerkzeuges, da dieses PDF die Schnittstelle zwischen ankommenden Weinen und dem System darstellt.
Daher ist der Profit, der durch dieses Werkzeug generiert wird, ohne dieses PDF stark eingeschränkt, da
einkommende Weine händisch, von Mitarbeitern, zugeordnet werden müssten.
Wie im \fullref{chap:stand-der-forschung} erläutert, werden für die dynamische
Generierung dieses PDFs die Bibliotheken \enquote{chillerlan/php-qrcode} und
\enquote{mpdf/mpdf} herangezogen und über Composer installiert.

\subsubsection{QR-Code-Generierung}
Der QR-Code beinhaltet lediglich die Wein-\ac{UID} anstatt einer vollständigen URL. Hintergrund dessen ist, dass
die URL, die benötigt ist, um einen Wein einzuscannen, bis auf die Wein-\ac{UID} immer identisch ist.
Somit wird redundanz vermieden.
Es ist Aufgabe der QR-Code-App, die den Code einscannt, aus der Wein-\ac{UID} eine vollständige URL herzuleiten.
Um Resourcen zu sparen und somit den Profit zu erhöhen, wird der QR-Code zu einem Base64-kodiertem Bild gerendert.
Das ist der Standardrückgabewert des QR-Code-Generators
und erfordert somit keine nähere Konfiguration. Ebenfalls lässt sich ein Base64-kodiertes Bild als Quellurl eines
IMG-HTML-Tags angeben, womit das Bild eingebettet ist. Hier wird der Profit erhöht, indem Arbeitszeit gespart wird,
die sonst in das anderweitige Einbetten eines Bildes in einem PDF mit \enquote{mpdf} fließen müsste.
Die QR-Codegenerierung funktioniert konkret, indem ein neues QRCode-Objekt der QRCode-Klasse erstellt wird.
Diese Klasse nimmt ein QROptions-Objekt im Konstruktor, das in diesem Falle einige Stilattribute mit sich trägt.
Das QRCode-Objekt bietet nun eine Methode \enquote{render} an, die, sofern nicht anders konfiguriert, den QR-Code als
Base64-kodiertes Bild zurückgibt \cite{bib:chillerlan-php-qrcode}.

\subsubsection{PDF-Generierung}
Firmenintern ist es Standard das Aussehen sowie die Inhalte der PDF-Dokumente, die \enquote{mpdf} erzeugt, mit HTML zu definieren,
das an \enquote{mpdf} gereicht wird. Um die Gestaltung und die Präsentation von Variablen in der HTML-Zeichenfolge technisch
kontinuierlich mit dem restlichen Projekt zu halten und um eine gute Wartbarkeit zu gewährleisten,
wird diese HTML-Zeichenfolge mit TYPO3-Fluid getemplated. Das heißt, dass eine HTML-Templatedatei bereitgestellt wird,
diese mit TYPO3-Fluid befüllt wird und in PHP gerendert wird, um eine HTML-Zeichenkette als Ergebnis zu erhalten.
Hierfür wird ein TYPO3-StandaloneView instanziiert, mit einem Pfad zur Template-Datei ausgestattet, Variablen angegeben,
die in Fluid verfügbar sein sollen und anschließend über die \enquote{render}-Methode zu einem String gerendert
\cite{bib:typo3-ref-standalone-view}.
Anschließend wird ein \enquote{mpdf}-Objekt erstellt und mit einer rudimentären Konfiguration in Form eines Arrays im Konstruktor
konfiguriert. Diese Konfiguration definiert in diesem Falle Seitenabstände, Papierformat, Zeichenkodierung und Schriftarten.
Abschließend wird dem \enquote{mpdf}-Objekt das zuvor generierte HTML übergeben und über die Methode \enquote{OutputBinaryData}
als Bytes zurückgegeben und in einer Variable gespeichert \cite{bib:mpdf-ref}.
Um dieses PDF-Dokument über die Verbindung an den Nutzer zu übertragen, wird ein TYPO3-Response-Objekt erstellt.
Über dieses Response-Objekt werden einige Header gesetzt und direkt übertragen. Dieser Header sind Content-Type und Content-Length.
Abschließend werden als Response-Body die Bytes des generierten PDFs abgeschickt. Damit ist die Verbindung beendet und das
PDF zum Nutzer übertragen.