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.
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.
\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 könnte.
Da Jahresauswahlprobennummern (uids) fortlaufend generiert werden, 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
UIDs 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.
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.
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. 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 UIDs 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.
