HSWO_BSC_BACHELORS_THESIS/chapters/konzeption-entwicklung.tex

\chapter{Konzeption und Umsetzung}
\label{chap:umsetzung}
Infolge der Anforderungsanalyse befasst sich das Kapitel \enquote{Konzeption und Umsetzung}
mit der Implementation der Anforderungen in dem
Brown-Field Projekt \cite{bib:schwarzer-vorlesung-swa} in Form einer TYPO3-Erweiterung.
Es ist anzumerken, dass das aus \fullref{chap:anforderungserfassung} hervorgehende Pflichtenheft im Rahmen geplanter und
opportunistischer Gespräche mit dem \ac{PO} geringfügige Änderungen erfahren wird.

\section{Setup der TYPO3-Erweiterung}
TYPO3-Erweiterungen werden via Composer installiert \break\cite{bib:typo3-docs-managing-extensions}.
Um eine TYPO3-Erweiterung zu erstellen, muss also ein Composer-Paket erstellt werden.
Um vermeidbare Komplexität zu verhindern, wird das Composer-Paket, welches die hier betrachtete
TYPO3-Erweiterung 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 betreiben, der üblicherweise mit dem Bereitstellen eines Paketes einhergeht.
\\
\\
Um das grundlegende Setup einer TYPO3-Erweiterung effizient durchzuführen, wird eine
existierende Erweiterung mit vergleichbarem Funktionsumfang kopiert, umbenannt und eingefügt.
Spezifisch ist dieser \enquote{vergleichbare Funktionsumfang}, dass es ebenfalls Datenmodelle und hochpersonalisierte
Frontendlogik in Bezug auf die zuvor genannten Datenmodelle gibt.

\section{Digitization}
Die Phase der Digitization nach Verhoef et al. befasst sich mit der digitalen Abbildung von Objekten aus der realen Welt
in einer Art und Weise, die ermöglicht, dass diese elektronisch weiterverarbeitet werden können\break\cite{bib:dougherty, bib:loebbecke}.
Des Weiteren befasst sich diese Phase mit der Automatisierung und Befüllung dieser Daten,
wie zum Beispiel durch Web-Formulare \cite{bib:verhoef}.
Das bedeutet, dass in dieser Phase Datenobjekte definiert und implementiert werden.
Ebenfalls werden anhand der Papier-Formulare Web-Formulare gebaut, damit Nutzer diese Datenobjekte erstellen können.
Ein Datenobjekt besteht nach firmeninternen Konventionen aus zumindest
vier Komponenten:
\begin{description}
  \item{\textbf{Datenbanktabelle}} \\
    Die Datenbanktabelle persistiert Informationen.
  \item{\textbf{Domain Model}} \\
    Das Domain Model (auch Model genannt) ist eine PHP-Klasse,
    die jeweils die Daten einer Zeile der Datenbanktabelle abbildet.
  \item\textbf{{Repository}} \\
    Ein Repository ist eine PHP-Klasse, die die Schnittstelle
    zwischen der Datenbank und der Model-Klasse darstellt.
  \item{\textbf{\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: Weinland Mosel Einlieferungswerkzeug, Quelle: Eigene Darstellung}
    \label{fig:objektrelationen}
\end{nicepic}

Nachdem in Erfahrung gebracht wird, welche konkreten Datenobjekte benötigt werden,
werden Attribute dieser Objekte dem Pflichtenheft entnommen. Diese werden 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.
Das hat den Vorteil, dass TYPO3-Categories bereits native Bestandteile eines TYPO3-Redaktionssystemes sind
und alle relevanten Attribute anbieten. Diese sind Titel,
Parentkategorie und Beschreibung.
Das Parent-Attribut ist nötig, 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}.
Rebsorte, Geschmacksangabe, Weineigenschaften und Qualitätsstufe sollen eigene Datentypen,
anstatt einfacher Zeichenfolgen sein.
Ziel dessen ist, dass sich Nutzer für einen vorgefertigten, nominalen Eintrag in einem Dropdown-Menü
entscheiden müssen und dass diese Auswahlmöglichkeiten im TYPO3-Backend pflegbar sind.
Weinlagen sind im Brown-Field-Projekt bereits vorhanden, also sollen hierfür existierende Daten
wiederverwendet werden.
Je Wein sollen beliebig viele Weineigenschaften auswählbar sein. Wettbewerbskategorien,
Geschmacksrichtung, etc, sind jeweils nur ein Element.
Weitere Notizen zu diesem Gespräch sind im Anhang unter \fullref{chap:anhang-notizen-digitization}
zu finden.
\\
\\
Da das Klassendiagramm 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,
um diese Beziehungen in Form zweier Foreign Keys zu 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}.


\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.
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 Nichtmitgliedern ist, dass Mitglieder bereits einen
Stammdatensatz hinterlegt haben.
Dieser Stammdatensatz bildet die Angaben zum Weingut des zu digitalisierenden Anmeldeformulares ab.
Nichtmitglieder 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 Loginformular, mit der Option zur Registrierung weitergeleitet.
Nach erfolgreichem Login, wird ein Teilnehmerobjekt erstellt.
Wählt der Nutzer \enquote{Nein, ich bin kein Mitglied}, wird er auf ein Registrierungsformular
weitergeleitet, um einen Nichtmitgliederaccount 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.6\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,
wird 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 TYPO3s nativem
Frontend-Nutzer-Login gelöst werden. Das ist explizit von \enquote{femanager} 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, 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}
\label{chap:umsetzung-mitglied-mit-konto}
Ist ein Nutzer ein \ac{WM}-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, hat aber 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, eine Mitgliedsnummer, 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,
öffnet sich ein Login-Formular, beschrieben in \enpointy{\textit{\nameref{chap:umsetzung-mitglied-mit-konto}}}.
Da es sich hierbei um einen Mitgliederzugang handelt, muss dieser zunächst von einem
\ac{WM}-Mitarbeiter freigegeben werden, bevor ein Login möglich ist.


\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 ausformulierten 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 \enquote{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 können Weiterleitungen zu spezialisierten Seiten im Backend-UI festgelegt werden
\break\cite{bib:typo3-docs-felogin}.
Für alle funktionalen Belange wird ein TYPO3-Plugin registriert. Dieses Plugin verfügt über einen
ActionController, der Nutzeranfragen an PHP-Funktionen (\enquote{Actions})
bindet.
In diesen Actions werden Fehlerbehandlungen 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 Repository-Objekten registriert
\break\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
ActionController-Objekten über Methoden übergeben \cite{bib:typo3-docs-di}.
Als problematisch erweisen sich hierbei bidirektionale Verbindungen zwischen Datenmodellen, wenn die Foreign Keys
über das SQL-Schlüsselwort
\break\enquote{AUTO\_INCREMENT} in der Datenbank generiert werden.
Beispielsweise muss ein Masterrecord, der Betriebsinformationen speichert, bidirektional an ein Teilnehmerobjekt
gebunden werden. Hierzu wird jedem der Elemente jeweils der Foreign Key des anderen übergeben.
Als Foreign Keys werden hierfür die jeweiligen \acp{UID} herangezogen, da diese Werte durch
\enquote{AUTO\_INCREMENT} auf der Datenbankebene erzeugt werden und garantiert einzigartig je Datenbanktabelle sind
\cite{bib:w3schools-auto-increment}.
Es gilt also, dass ein Masterrecord $a$ die Teilnehmer\ac{UID} von einem Teilnehmer $b$ hält und dass
$b$ die Masterrecord\ac{UID} von $a$ hält.
Die Problematik hierbei ist, dass diese \acp{UID} erst nach dem Persistieren in der Datenbank bekannt sind,
da diese Werte erst im Zuge der Persistierung erstellt werden \cite{bib:w3schools-auto-increment}.
Die Lösung hierfür ist, beide Elemente zu erstellen und zu persistieren und erst danach ihre \acp{UID} gegenseitig
bekannt zu machen um sie anschließend 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} erfordert. 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 geleistet werden muss. Das ist so, da diese Formulare nun nicht mehr von
Mitarbeitern bearbeitet werden müssen. Davon profitiert \ac{WM}, da diese Zeit nun für andere Aufgaben 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 Jahresauswahlprobe, 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, also \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 werden mit simplen Input-Tags umgesetzt und erhalten 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.
\break{}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ählten Elementes \cite{bib:typo3-docs-fluid-form-viewhelpers}.
\clearpage

Aufgrund dessen, dass das Weinlagen-Dropdown-Menü über 170 Einträge führt, wird eine Suchmöglichkeit implementiert.
Diese ist lediglich ein Textfeld, das bei jeder Eingabe allen Option-Tags der Weinlage,
deren Anzeigewert nicht dem Suchwert 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
als Baumstrukturen abgebildet werden
\break\cite{bib:typo3-docs-sys-category}.
Um die Eltern-Kind-Beziehungen der
\break{}Baumstruktur ersichtlich zu machen, werden die Option-HTML-Tags 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 Dropdown-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 Dropdown-Menü aus wie eine Baumstruktur.
\\
\\
Diese Herangehensweise erzeugt schlüssigen, lesbaren Programmcode und lässt sich unkompliziert umsetzen.
Das senkt Entwicklungskosten, wovon \ac{WM} profitiert.
Rekursiv aufgerufene For-Schleifen, die sich selbst erneut für alle Elemente aufrufen,
können zu Performanzproblemen führen \cite{bib:schwarzer-vorlesung-alg}.
Daher wird im Folgenden die Zeitkomplexität dieser Rekursionsfunktion betrachtet.
Für diese Funktion kann kein Master-Theorem angewandt werden,
da es sich hierbei nicht um einen \enquote{Divide-and-Conquer-Algorithmus} handelt.
Das ist so, da das in der Rekursion weitergereichte Problem nicht kleiner wird,
sondern gleich groß bleibt. Demnach ist $b = 1$.
Das verletzt die Bedingung $b>1$ des Master-Theorems, definiert als $T(n) = a*T(\frac{n}{b})+f(n)$
\cite{bib:schwarzer-vorlesung-alg}.
Der Algorithmus besteht aus $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 wird bewusst verzichtetet.
Grund dafür ist, dass Optgroup-Elemente an sich nicht im Dropdown-Menü 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 wäre. 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$ verschiedenen Elementen aus einer anderen
Datenbanktabelle geben. Der Nutzer kann sich für eine beliebige Auswahl dieser, eingeschlossen keinen, entscheiden.
Ein Beispiel für SelectMultiple-Formfelder sind Weineigenschaften.
TYPO3-Fluid implementiert hierfür keinen ViewHelper
\cite{bib:typo3-docs-fluid-form-viewhelpers},
also wird 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>},
den ID- und Namenswert \enquote{<formfeldname>-<a.uid>} und den
Formularwert \enquote{<formfeldname>-true}.
Ist also eine dieser Checkboxen angehakt, hat sie den zuvor genannten Formularwert. Falls nicht, trägt sie keinen Formularwert.
Weil alle angehakten Checkboxen dieses Formfeldes den selben Namenswert tragen, ist es phpseitig trivial
eine Liste aller angehakten Checkbox-Namen 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 (der Formwert) 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-Namen der Checkboxen des SelectMultiples, die angehakt wurden.
Mit der eingebauten PHP-Funktion \enquote{array\_map} wird nun eine Operation auf alle Werte
der Liste angewandt, die
\break\enquote{strlen('<formfeldname>-')} Zeichen, von links ausgehend, vom Formfeld-Name
entfernt. Somit wird beispielsweise der Formfeld-Name \enquote{winekind-18} zu \enquote{18} transformiert.
Übrig bleiben die extrahierten \acp{UID} aller angehakten Elemente $a$, in Form einer Zeichenkette.
Ü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 Datenblattes als PDF ist ein essenzieller Bestandteil des
Jahresauswahlprobenwerkzeuges, da dieses PDF die Schnittstelle zwischen ankommenden Weinen und dem System darstellt.
Daher ist der Gewinn, der durch dieses Werkzeug generiert wird, ohne dieses Dokument stark eingeschränkt, da
einkommende Weine händisch, von Mitarbeitern, zugeordnet werden müssten.
Wie im \fullref{chap:stand-der-forschung} erläutert wird, 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 benötigte URL, 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 effizient zu arbeiten, wird der QR-Code zu einem base64-kodierten Bild gerendert.
Das ist der Standardrückgabewert des QR-Code-\break{}Generators
und erfordert somit keine nähere Konfiguration. Ebenfalls lässt sich ein base64-kodiertes Bild als Quell-URL eines
IMG-HTML-Tags angeben, womit das Bild eingebettet ist. Das spart Arbeitszeit,
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 mit \enquote{mpdf} erzeugt werden,
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 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 konfiguriert, Variablen angegeben,
die in Fluid verfügbar sein sollen und anschließend über die \enquote{render}-Methode zu einer Zeichenkette 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, über die Methode \enquote{OutputBinaryData}
in Form von 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. Diese Header sind Content-Type und Content-Length.
Abschließend werden als Response-Body die Bytes des generierten PDFs übertragen. Damit ist die Verbindung beendet und das
PDF zum Nutzer übertragen.
\clearpage

\subsection{Jahresauswahlproben- und Wein-Detailansichten}
Weine und Jahresauswahlproben sollen unter bestimmten Gegebenheiten einsehbar sein.
Hierzu gibt es eine Auflistung aller Jahresauswahlproben. Diese sind anklickbar, um eine Detailansicht der ausgewählten
Jahresauswahlprobe zu öffnen. Hier wird neben Metadaten der Jahresauswahlprobe auch eine Liste aller zur Einsicht berechtigen Weine
angezeigt. Diese Weine sind anklickbar, um auf eine Detailansicht der Weine zu gelangen.
Die Detailansichten für Jahresauswahlproben und Weine benötigen spezielle Autorisierung.
Diese sind: Jahresauswahlproben sind nur einsichtig, wenn sich das aktuelle Datum innerhalb des
Sichtbarkeitszeitraumes der Jahresauswahlprobe befindet.
Detailansichten für Weine sind immer für den zugehörigen Teilnehmer einsichtig.
Nach Abschluss einer Jahresauswahlprobe sind alle ihr angehörigen Weine öffentlich einsichtig.
Das hat den Hintergrund, dass Jahresauswahlproben Blindverkostungen sind
und niemand die Möglichkeit haben sollte, im Voraus Informationen über die teilnehmenden Weine in Erfahrung zu bringen.
Die Ergebnisse der Jahresauswahlproben sind öffentlich, also sind es die Weine nach Abschluss einer Jahresauswahlprobe auch.
Mitarbeiter von \ac{WM}, wenn sie mit einem solchen Account angemeldet sind, haben immer Einsicht in Wein-Detailansichten.
Die Wein-Detailseite verfügt außerdem über einen \enquote{Datenblatt drucken}-Button, der auf das Datenblatt-PDF verlinkt.
Dieser Button ist nur für den zugehörigen Teilnehmer und Mitarbeiter verfügbar.
Diese Daten, Fakten und Restriktionen werden serverseitig kontrolliert, um Manipulationen des Nutzers auszuschließen.
Um das zu realisieren werden Daten mit Fluid-Templates konditionell dargestellt und über Fluid-ViewHelper Links
zu anderen Ansichten generiert. Diese ViewHelper übergeben Parameter. Die hierfür relevanten Parameter der verschiedenen
Ansichten sind beispielsweise Wein-\acp{UID} und Jahresauswahlproben-\acp{UID}. Um Informationen über den angemeldeten Nutzer,
wie beispielsweise seiner Teilnehmernummer oder seiner Nutzergruppenzugehörigkeit, zu erlangen, wird sich
der Extbase-nativen Domain-Model-FrontendUser-Klasse bedient \cite{bib:typo3-ref-extbase-model-feuser}.

Mit Abschluss der Phase der Digitization können alle Datenstrukturen im TYPO3-Backend händisch angelegt,
eingesehen, gelöscht, bearbeitet und im Frontend von Nutzern befüllt 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{Schnittstelle QR-Code-Scanner}
Es ist angedacht, dass Mitarbeiter über die App \enquote{QRBot} den QR-Code auf dem Datenblatt einscannen.
Diese App ermöglicht es Nutzern für jeden eingescannten Code eine URL zu öffnen und den Wert des QR-Codes anstelle eines Platzhalters
in der URL einzufügen.
Hierfür bietet das Jahresauswahlprobenwerkzeug eine Schnittstelle bzw. eine Seite an, die eine Wein-\ac{UID} als
URL-kodierten GET-Parameter annimmt und diesen Wein als \enquote{eingegangen} markiert.
Um sicherzustellen, dass Weine nicht unautorisiert markiert werden, müssen sich Mitarbeiter mit einem Nutzerkonto
authentifizieren. Dieses Nutzerkonto muss Teil einer Mitarbeiter-Nutzergruppe sein.
Das Nutzerkonto wird von Redakteuren oder Administratoren im TYPO3-Backend erstellt und benötigt keiner Registrierung.
Nach einer Anmeldung bleibt diese Sitzung aktiv und verfällt erst nach längerer Inaktivität.
Wird ein Wein als \enquote{eingegangen} markiert, wird der betroffene Teilnehmer per Email informiert.
Hierzu wird die FluidEmail-Klasse des TYPO3-Cores herangezogen.
Sollte ein Wein bereits als \enquote{eingegangen} markiert sein, wird keine Email verschickt und dem Mitarbeiter kommuniziert,
dass keine Änderungen vorgenommen wurden.
Abschließend werden im Frontend allgemeine Daten zum Wein angezeigt, damit sich Mitarbeiter sicher sein können,
den richtigen Wein eingescanned zu haben.

\subsection{CSV-Export}
Das letzte Glied des analogen Prozesses, den es zu digitalisieren gilt, ist der Datenexport der Weindaten je Jahresauswahlprobe.
TYPO3s ListView bietet einen nativen CSV-Exporter an \cite{bib:pixelant-typo3-data-export},
jedoch kommt dieser nicht den Anforderungen gerecht, da das CSV-Dokument Daten verschiedener Datenbanktabellen im Verein
beinhalten muss.
Um eine reibungslose Integration in die restlichen Prozesse von \ac{WM} zu gewährleisten, muss das exportierte CSV
das selbe Format haben, wie bisher bestehende Excel-Dateien. Dieses Format ist durch genaue Spaltennamen,
Spalteneihenfolgen und den Arten von Daten, die angefragt werden, definiert.
Um einen benutzerdefinierten Exporter im Backend bereitzustellen, wird ein Backendmodul registriert, das immer im linken
Reitermenü verfügbar ist.
Dieses Bankendmodul stellt eine Listenansicht aller Jahresauswahlproben bereit.
Restriktionen gibt es hierbei keine, da diese Listenansicht
nur im Backend, nur für Administratoren und Redakteure, verfügbar ist.
Jeder Listeneintrag ist eine Verlinkung auf eine Detailansicht der jeweiligen Jahresauswahlprobe.
Diese Detailansicht ist der CSV-Exporter. Hierfür werden alle Weine aus der Datenbank angefragt,
die der jeweiligen Jahresauswahlprobe zugeordnet sind. Zusammenhängende Relationen, wie zum Beispiel Teilnehmerdatensätze,
die Attribute dieser Weine sind, werden automatisch von Extbase angefragt \cite{bib:typo3-docs-model-explained}.
Das CSV-Dokument wird über die PHP-native Funktion \enquote{fputcsv} generiert. Diese Funktion nimmt einen
numerisch indizierten Array und schreibt eine darauf basierende CSV-Zeile in eine Datei \cite{bib:php-fputcsv}.
Um gut wartbaren PHP-Code zu erzeugen, werden alle CSV-Zeilen in einem zweidimensionalen Array,
der das gesamte CSV-Dokument darstellt,
durch alphanumerisch indizierte, innere Arrays abgebildet. Somit ist bei jeder Wertzuweisung der zugehörige Spaltenname als Array-Key ersichtlich.
Über die nativen PHP-Funktionen \enquote{array\_keys} und \enquote{array\_values} wird dieser zwar gut lesbare,
aber mit \enquote{fputcsv} inkompatible
Array zu einer Reihe kompatibler Array konvertiert. Hierbei werden durch \enquote{array\_keys} die Kopfzeile und durch
\enquote{array\_values} die Datenzeilen extrahiert. Diese Zeilen werden anschließend mit \enquote{fputcsv}
in die Zieldatei geschrieben. Als Zieldatei wird eine temporäre Datei im Arbeitsspeicher angegeben,
um das fertig erzeugte CSV-Dokument als Zeichenkette in PHP zu erhalten. Das spart vermeidbare Festplattenschreib- und Lesezugriffe.
Im Fluid-Template des Backendmoduls wird das generierte CSV-Dokument in einem nicht beschreibbaren Textarea-Feld präsentiert.
Um \ac{WM} weitere Arbeitszeit zu ersparen, wird eine Download-Funktion für CSV-Dateien
angeboten. Das erspart das manuelle Kopieren und Abspeichern von CSV-Zeichenketten durch IT-Fachfremde, reduziert damit die Anzahl
an benötigten Übergangsschritten in weitere Prozesse und reduziert somit die Komplexität der Umstellung.
Auch im Interesse, Arbeitszeit in der Umsetzung zu sparen,
wird diese Downloadfunktion javascript-seitig umgesetzt.
Dadurch ist der Download in derselben Action, die CSV für das Textarea-Feld generiert, implementiert.
Somit muss weder abstrahiert werden, noch ein weiterer CSV-Exporter gebaut werden.
Hierfür wird ein EventHandler auf den Download-Button angewandt, der bei Betätigung ein vestecktes
\enquote{a}-Element erstellt, über das HTML-Attribut \enquote{download} des \enquote{a}-Elementes den Download-Dateinamen
festlegt und als \enquote{href}-HTML-Attribut
eine Blob-URL zuweist. Diese Blob-URL wird über ein Blob-Objekt generiert.
Wird nun der Download-Button gedrückt, wird javascript-seitig eine Datei erzeugt und gespeichert
\cite{bib:tutorialspoint-js-save-text}.