Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md aktualisiert

Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md

@@ -157,15 +157,25 @@ Die Meldefunktion in der Detailseite ist nicht direkt im Hall-of-Fame-Modul impl
 Für die Generierung der PDF-Dokumente wird die Open-Source-Bibliothek QuestPDF in der Community-Edition eingesetzt. Im Server-Projekt wurde ein benutzerdefiniertes MSBuild-Target erstellt, das nach jedem Build automatisch die QuestPDF-DLL sowie die plattformspezifischen nativen Bibliotheken in das bin-Verzeichnis des Oqtane-Servers kopiert. Dies ist notwendig, weil Oqtane Module zur Laufzeit dynamisch lädt und QuestPDF native Abhängigkeiten (unter anderem die SkiaSharp-Rendering-Engine) benötigt.
 Das PDF-Design folgt einem Glasmorphismus-Ansatz. Jede Seite hat das Format DIN A4 ohne Ränder. Über die Layers-API von QuestPDF wird das Hintergrundbild von der Inhaltsebene getrennt. Der Name wird in 36 Punkt ExtraBold mit Großbuchstaben und Zeichenabstand dargestellt, der Jahrgang in 15 Punkt mit erhöhtem Zeichenabstand und die Beschreibung in 11 Punkt mit 1,5-fachem Zeilenabstand. Der Glaseffekt wird durch halbtransparente dunkle Hintergründe mit mehrschichtigen Rahmen unterschiedlicher Transparenz erzeugt.
 #### Implementierungsdetails und Problemlösungen
+
 Während der Entwicklung traten mehrere technische Herausforderungen auf, die im Folgenden zusammen mit ihren Lösungen beschrieben werden.
-**Bild-Upload-System**
-In der ursprünglichen Version des Moduls mussten Benutzerinnen und Benutzer eine Bild-URL manuell in ein Textfeld eingeben. Das implementierte Bild-Upload-System ersetzt dies durch eine Blazor-InputFile-Komponente mit Live-Vorschau, Fortschrittsanzeige und Lösch-Button. Die Upload-Methode prüft die Dateigröße (maximal 5 MB), öffnet die Datei als Stream und übermittelt sie als MultipartFormDataContent an den Server, der den Dateityp serverseitig validiert, einen UUID-Dateinamen generiert und die Datei speichert. Das System unterstützt beide Blazor-Rendering-Modi.
-**Concurrency Exception beim Löschen**
+
+##### Bild-Upload-System
+
+In der ursprünglichen Version des Moduls mussten Benutzerinnen und Benutzer eine Bild-URL manuell in ein Textfeld eingeben. Das implementierte Bild-Upload-System ersetzt dies durch eine Blazor-`InputFile`-Komponente mit Live-Vorschau, Fortschrittsanzeige und Lösch-Button. Die Upload-Methode prüft die Dateigröße (maximal 5 MB), öffnet die Datei als Stream und übermittelt sie als `MultipartFormDataContent` an den Server, der den Dateityp serverseitig validiert, einen UUID-Dateinamen generiert und die Datei speichert. Das System unterstützt beide Blazor-Rendering-Modi.
+
+##### Concurrency Exception beim Löschen
+
 Beim Löschen von Einträgen mit vorhandenen Meldungen trat eine `DbUpdateConcurrencyException` auf, verursacht durch Konflikte im Entity Framework Change Tracker. Die Lösung bestand in der Aufteilung der Löschoperation in zwei separate Transaktionen mit jeweils eigenem DbContext: zuerst werden alle zugehörigen Meldungen gelöscht, danach der Haupteintrag.
-**Kartendesign-Optimierung**
+
+##### Kartendesign-Optimierung
+
 Karten hatten ursprünglich unterschiedliche Höhen durch variierende Beschreibungslängen. Die Lösung kombiniert CSS-Flexbox auf dem Kartenelement mit einer Maximalhöhe von 150 Pixeln und `overflow: hidden` auf dem Beschreibungscontainer, sodass alle Karten einer Zeile dieselbe Höhe aufweisen.
-**Sortier-Toggle**
+
+##### Sortier-Toggle
+
 Die ursprünglich fest codierten Sortierrichtungen wurden durch einen Toggle-Button neben dem Sortier-Dropdown ersetzt, der mit einem dynamischen Pfeil-Icon zwischen aufsteigender und absteigender Sortierung umschaltet. Die Sortierlogik ist in einer berechneten Eigenschaft gekapselt, die Suche und Sortierung kombiniert.
+
 ---
 ## 8. Projektorganisation & Teamarbeit
 ### 8.1 Planung & Meilensteine
@@ -178,16 +188,46 @@ Die ursprünglich fest codierten Sortierrichtungen wurden durch einen Toggle-But
 #### Auswirkungen auf Theme-Entwicklung, Module und Zeitplanung
 ---
 ## 9. Übergangslösung, Probleme & Learnings
+
 ### 9.1 Übergangslösung (Sommer 2025)
+
 #### Gründe & Technische Umsetzung
+
+Da AlumniHub zum Zeitpunkt des ersten Absolventenstreffens im Sommer 2025 noch nicht fertig war und das Hosting von Oqtane auf dem Hetzner-Server zu Problemen geführt hat, wurde im Team eine einfache Übergangslösung entwickelt. Ziel war es, pünktlich zur Veranstaltung eine funktionierende Lösung bereitzustellen, über die Absolventinnen und Absolventen ihre Teilnahme bestätigen oder absagen sowie Feedback zum Projekt abgeben konnten.
+
+Das Frontend wurde mit HTML, CSS und JavaScript umgesetzt. Die Hauptseite (`index.html`) zeigt einen Button, über den ein modales Overlay-Formular geöffnet wird. Darüber konnten Nutzer ihre E-Mail-Adresse und ihr Feedback eingeben und absenden. Für Zu- und Absagen wurden separate Bestätigungsseiten erstellt (`zusage.html` und `absage.html`). Das Overlay schließt sich automatisch beim Klick außerhalb des Formulars. Das Design orientiert sich am Erscheinungsbild der HTL Ungargasse.
+
 #### Differenzen zur finalen Lösung
+
+Im Vergleich zu AlumniHub ist die Übergangslösung deutlich schlichter gehalten. Es gibt keine Benutzerkonten, keine Datenbank und keine Verwaltungsfunktionen. Nach dem Absolvententreffen wurde die Seite nicht abgeschaltet, sondern als Feedback-Seite für das Diplomprojekt weitergenutzt. Lehrkräfte, Mitschülerinnen und Mitschüler sowie externe Besucher konnten darüber Feedback abgeben, bis AlumniHub diese Funktion selbst übernahm.
+
+---
+
 ### 9.2 Probleme
+
 #### Technische Probleme
+
+Ein großes Problem war der Zeitdruck vor dem ersten Absolvententreffen. Da AlumniHub zu dem Zeitpunkt noch nicht einsatzbereit war, musste die Übergangslösung schnell entwickelt und in Betrieb genommen werden. Außerdem gab es beim Hosting von Oqtane auf dem Hetzner-Server technische Schwierigkeiten, die den Entwicklungsfortschritt gebremst haben.
+
 #### Organisatorische Probleme
+
+Im Sommer 2025 war die Mitarbeit im Team sehr ungleich verteilt. Viele Teammitglieder waren nicht erreichbar oder haben nicht aktiv am Projekt weitergearbeitet. Nur ein kleiner Teil des Teams hat in dieser Zeit wirklich weitergemacht. Das hat zu einer ungleichen Arbeitsbelastung geführt und den Fortschritt in dieser Phase deutlich verlangsamt.
+
+---
+
 ### 9.3 Learnings
+
 #### Technisch
+
+Durch das Projekt wurden praktische Kenntnisse in Git zur Versionskontrolle gewonnen, was besonders für die Zusammenarbeit im Team wichtig war. Außerdem wurde Responsive Design vertieft – also wie man Layouts baut, die auf verschiedenen Bildschirmgrößen gut aussehen. Auch der Umgang mit JavaScript für UI-Elemente wie Overlays und Menüs wurde durch die praktische Arbeit besser verstanden.
+
 #### Methodisch
+
+Es hat sich gezeigt, dass eine klare Aufgabenverteilung von Anfang an wichtig ist. Wenn nicht klar ist, wer was macht, entstehen Verzögerungen. Regelmäßige Team-Meetings wären hilfreich gewesen, um den Stand abzugleichen und Probleme früh zu erkennen.
+
 #### Persönlich
+
+Eine wichtige persönliche Erkenntnis war, dass Eigeninitiative in einem Teamprojekt entscheidend ist. Besonders in Phasen, wo nicht alle aktiv waren, hat sich gezeigt, dass man Aufgaben selbst in die Hand nehmen muss, damit das Projekt vorankommt.
 ---
 ## 10. Testen & Qualitätssicherung
 ### Funktionstests der Module