feat: implement next feedback

chapters/konzeption-entwicklung.tex

@@ -65,30 +65,30 @@ Unterkategorien \enquote{Trockener Riesling} und \enquote{Halbtrockener Riesling
 \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ü
+Ziel dessen 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,
+Je 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,
+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
+Um $m,n$-Beziehungen, wie beispielsweise der Menge der für eine Probe zugelassenen Kategorien
-\enquote{allowedCategories} zwischen $m$ \enquote{Jahresauswahlprobe}-Objekten und
+\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.
+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}.
-Mit Abschluss der Digitization können alle Datenstrukturen im TYPO3-Backend händisch angelegt,
+Mit Abschluss der Phase der Digitization können alle Datenstrukturen im TYPO3-Backend händisch angelegt,
 eingesehen, gelöscht und bearbeitet werden.
 
 
@@ -119,8 +119,8 @@ Der mit dem \ac{PO} ausgearbeitete UX-Flow der Registrierung sieht vor, dass der
 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
+Wählt der Nutzer \enquote{Nein, ich bin kein Mitglied} aus, wird er auf ein Registrierungsformular
-weitergeleitet, auf um sich einen Nicht-Mitgliederaccount anzulegen. Im Zuge dieser Registrierung werden
+weitergeleitet, um 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}.
@@ -138,7 +138,6 @@ werden auf diese Lösungen zurückgegriffen, um einen einheitlichen Workflow bei
 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}
@@ -167,7 +166,7 @@ Teilnehmer-Eintrag für den Frontend-Nutzer und fügt den Frontend-Nutzer der Nu
 Damit ist die Teilnehmerregistrierung abgeschlossen.
 
 \subsubsection*{Mitglied, ohne Konto}
-Ist ein Nutzer ein Mitglied und hat noch kein Mitgliedskonto, muss dieser auf der Registrierungsseite
+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.
@@ -180,34 +179,34 @@ freigegeben und es öffnet sich ein Login-Formular, beschrieben in \enpointy{Mit
 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
+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 Femanager.
-Weiterleitungen zu bestimmten Seiten nachdem ein Nutzer spezielle Events ausgelöst hat können über TypoScript
+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.
 \cite{bib:typo3-docs-felogin}.
-Für alle funktionalen Belange wurde ein TYPO3-Plugin registriert. Dieses Plugin verfügt über einen
+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 wird Fehlerbehandlung durchgeführt, Datenmodelle der Domäne erstellt und in der
+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}.
+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
+Als problematisch erweisen sich hierbei bidirektionale Verbindungen zwischen Datenmodellen, wenn die Foreign Keys
-über das SQL-Schlüsselwort \enquote{AUTO\_INCREMENT} in der Datenbank definiert werden.
+über das SQL-Schlüsselwort \enquote{AUTO\_INCREMENT} in der Datenbank generiert werden.
-In diesem Fall wollen wir
+Beispielsweise, muss ein MasterRecord, der Betriebsinformationen speichert, bidirektional an ein Teilnehmerobjekt
-einen MasterRecord, der Betriebsinformationen speichert, bidirektional an ein Teilnehmerobjekt linken.
+gebunden werden. Hierzu wird jedem der Elemente jeweils der Foreign Key des anderen übergeben.
-Als ForeignKeys werden hierfür ihre jeweiligen Uids herangezogen, da diese Werte durch
+Als Foreign Keys werden hierfür die jeweiligen \acp{UID} herangezogen, da diese Werte durch
-\enquote{AUTO\_INCREMENT} auf der Datenbankebene gehandhabt werden.
+\enquote{AUTO\_INCREMENT} auf der Datenbankebene erzeugt werden und garantiert einzigartig je Datenbanktabelle sind
-Es gilt also, dass ein MasterRecord $a$ die TeilnehmerUid von einem Teilnehmer $b$ hält und dass
+\cite{bib:w3schools-auto-increment}.
-$b$ die MasterRecordUid von $a$ hält.
+Es gilt also, dass ein MasterRecord $a$ die Teilnehmer\ac{UID} von einem Teilnehmer $b$ hält und dass
-Die Problematik hierbei ist, dass diese Uids erst nach dem persistieren in der Datenbank bekannt sind,
+$b$ die MasterRecord\ac{UID} von $a$ hält.
-da diese Werte erst im Zuge der Persistierung erstellt werden. Das ist so, da das
+Die Problematik hierbei ist, dass diese \acp{UID} erst nach dem Persistieren in der Datenbank bekannt sind,
-\enquote{AUTO\_INCREMENT}-Schlüsselwort lediglich zu SQL gehört und SQL nur von der Datenbank ausgeführt wird.
+da diese Werte erst im Zuge der Persistierung erstellt werden \cite{bib:w3schools-auto-increment}.
-Die Lösung hierfür ist es, beide Elemente zu erstellen und zu persistieren, danach ihre Uids gegenseitig
+Die Lösung hierfür ist, beide Elemente zu erstellen und zu persistieren, erst danach ihre \acp{UID} gegenseitig
 bekannt machen um sie danach erneut zu persistieren.
 
 \subsection{Weinregistrierung}

config.tex

@@ -10,7 +10,7 @@
 \newcommand{\cfgDocClassification}{Abschlussarbeit}
 
 % Document version
-\newcommand{\cfgDocVersion}{1.4}
+\newcommand{\cfgDocVersion}{1.5}
 
 % Last modification date
 \newcommand{\cfgDateLastModification}{22. Dezember 2022}

dexes/literature.bib

@@ -162,6 +162,15 @@
   note         = {Zugriff: Januar 2023}
 }
 
+
+@misc{bib:w3schools-auto-increment,
+  author       = {{W3Schools}},
+  howpublished = "\url{https://www.w3schools.com/sql/sql_autoincrement.asp}",
+  title        = {{SQL AUTO INCREMENT Field}},
+  year         = {2023},
+  note         = {Zugriff: März 2023}
+}
+
 @misc{bib:larsjung-jquery-qrcode,
   author       = {Lars Jung},
   howpublished = "\url{https://github.com/lrsjng/jquery-qrcode/blob/master/README.md}",