From 151c2fa7d724ebe208ae3a42de5a255d69f1ce0a Mon Sep 17 00:00:00 2001 From: Leon Etienne Date: Fri, 24 Mar 2023 17:32:59 +0100 Subject: [PATCH] feat: implement next feedback --- chapters/konzeption-entwicklung.tex | 55 ++++++++++++++--------------- config.tex | 2 +- dexes/literature.bib | 9 +++++ 3 files changed, 37 insertions(+), 29 deletions(-) diff --git a/chapters/konzeption-entwicklung.tex b/chapters/konzeption-entwicklung.tex index 5cd1300..3bda5ea 100644 --- a/chapters/konzeption-entwicklung.tex +++ b/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 -\enquote{allowedCategories} zwischen $m$ \enquote{Jahresauswahlprobe}-Objekten und +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. +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 -weitergeleitet, auf um sich einen Nicht-Mitgliederaccount anzulegen. Im Zuge dieser Registrierung werden +Wählt der Nutzer \enquote{Nein, ich bin kein Mitglied} aus, wird er auf ein Registrierungsformular +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 -Datenbank persistiert sowie Daten für die Anzeige im Frontend aufbereitet \cite{bib:typo3-docs-extbase}. +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 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 +Als problematisch erweisen sich hierbei bidirektionale Verbindungen zwischen Datenmodellen, wenn die Foreign Keys +über das SQL-Schlüsselwort \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, erst danach ihre \acp{UID} gegenseitig bekannt machen um sie danach erneut zu persistieren. \subsection{Weinregistrierung} diff --git a/config.tex b/config.tex index b37659a..1ab568d 100644 --- a/config.tex +++ b/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} diff --git a/dexes/literature.bib b/dexes/literature.bib index 2c79459..9c089fc 100644 --- a/dexes/literature.bib +++ b/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}",