Dassler...

New: Danksagung
Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md aktualisiert
2026-03-19 07:23:43 +00:00 · 2026-03-13 22:25:12 +00:00 · 2026-03-12 14:09:34 +00:00 · 2026-03-09 14:08:03 +00:00 · 2026-03-08 15:42:16 +00:00 · 2026-03-07 14:18:27 +00:00
3 changed files with 221 additions and 465 deletions
--- a/Allgemein.md
+++ b/Allgemein.md
@@ -0,0 +1,13 @@
 ## Danksagung
 Obwohl die Umsetzung dieses Projektes durch das Projektteam selbst erfolgte, gab es eine Reihe an Personen, die uns tatkräftig unterstützt haben.
 An erster Stelle möchten wir uns bei Herrn Prof. Thomas Gürth und Herrn Prof. Johannes Kreuzer bedanken. Ohne Ihre umfangreiche Unterstützung, Kreativität und fachliche Kompetenz wäre das Projekt in dieser Form nicht realisierbar gewesen. Sie beide haben uns durch dieses Projekt begleitet, uns mit wertvollen Ideen und Hilfestellungen versorgt und uns gleichzeitig den notwendigen Freiraum für eigenständiges Lernen und Arbeiten gelassen.
 Neben einer exzellenten Betreuung bedarf eine Diplomarbeit auch eines engagierten Auftraggebers. Bei Lukas Aigner bedanken wir uns für das Vertrauen in unser Team und die Ermöglichung dieses Projektes. Trotz zeitlicher Verzögerungen im Rahmen der Arbeit, erfuhren wir von seiner Seite großes Verständnis und fanden stets eine konstruktive Basis für Diskussionen vor.
 Ein besonders komplexer Aspekt dieser Arbeit war die Infrastruktur, für die im Prozess drei verschiedene Lösungen evaluiert wurden. Wir danken Stefan Reinel und dem Team von LiveDesign für die bereitwillige Unterstützung. Ohne die aktuelle Infrastruktur hätten wir bis heute keine zufriedenstellende Lösung für unsere Homepage gefunden.
 Als wir im Oktober kurzfristig eine neue Produktionsumgebung benötigten, wurde uns unbürokratisch durch die Schule geholfen. Herr Prof. Harald Dassler und Herr Prof. Andreas Resch haben uns zur Weiterentwicklung eine virtuelle Maschine zur Verfügung gestellt und den externen Zugriff ermöglicht. Es ist nicht selbstverständlich, dass in einer Institution dieser Größe ein solcher Wunsch so schnell und unkompliziert umgesetzt wird.
 Für den „frischen Wind“ und das sorgfältige Korrekturlesen der Arbeit bedanken wir uns herzlich bei Frau Prof. Gertrude Brindlmayer. Ihr geschulter Blick auf Details, die dem Team im Arbeitsprozess entgangen waren, stellte eine große Bereicherung für die finale Qualität dieser Arbeit dar.
--- a/Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md
+++ b/Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md
@@ -80,15 +80,23 @@ Das Projektteam wurde im Verlauf des Projekts von sechs auf drei Personen reduzi
 ### 6.1 Ziel des Themes
-Im Rahmen des Projekts AlumniHub wurde ein eigenes Theme für das Content-Management-System Oqtane entwickelt. Ziel dieser Entwicklung war es, das Standarddesign von Oqtane vollständig durch eine projektspezifische Benutzeroberfläche zu ersetzen, die den Anforderungen des Absolventenvereins entspricht. Dabei standen Übersichtlichkeit, Benutzerfreundlichkeit sowie eine moderne und konsistente Gestaltung im Vordergrund. Das Theme sollte zudem auf unterschiedlichen Endgeräten – sowohl Desktop als auch mobil – optimal dargestellt werden.
+Im Rahmen des Projekts AlumniHub wurde ein eigenes Theme für das Content-Management-System Oqtane entwickelt. Ziel dieser Entwicklung war es, das Standarddesign von Oqtane vollständig durch eine projektspezifische Benutzeroberfläche zu ersetzen, die den Anforderungen des Absolventenvereins der HTL Ungargasse entspricht. Das Standardtheme von Oqtane ist funktional, jedoch generisch gehalten und bietet keinen Bezug zur Schule oder zum Projekt. Aus diesem Grund wurde frühzeitig die Entscheidung getroffen, ein vollständig eigenes Theme zu entwickeln, das sowohl optisch als auch technisch auf die Bedürfnisse der Plattform zugeschnitten ist.
 Das visuelle Design orientiert sich dabei am bestehenden Erscheinungsbild der offiziellen Schulwebseite szu.at. Es wurde bewusst ein schlichtes Grau-Weiß-Farbschema gewählt, das eine klare, professionelle und zeitlose Optik erzeugt. Auf auffällige Farben oder komplexe Animationen wurde verzichtet, um die Inhalte in den Vordergrund zu stellen und eine ruhige Benutzeroberfläche zu schaffen, die für ein breites Publikum – von Schülerinnen und Schülern über Lehrkräfte bis hin zu ehemaligen Absolventinnen und Absolventen – zugänglich ist.
 Neben der visuellen Gestaltung standen auch technische Anforderungen im Mittelpunkt. Das Theme sollte auf unterschiedlichen Endgeräten – sowohl auf Desktop-Computern als auch auf Smartphones und Tablets – zuverlässig und benutzerfreundlich funktionieren. Responsive Design war daher von Anfang an eine zentrale Anforderung. Darüber hinaus sollte das Theme vollständig in die Oqtane-Architektur integriert sein, sodass alle Standardfunktionen des CMS wie Benutzerverwaltung, Seitenverwaltung und Modulintegration weiterhin ohne Einschränkungen genutzt werden können.
 ### 6.2 Technische Umsetzung
-Als technische Grundlage diente die Theme-Architektur von Oqtane. Das Layout wurde in einer Razor-Datei (`Theme.razor`) definiert, welche von der Basisklasse `ThemeBase` erbt. Dadurch stehen zentrale Funktionen wie Seitenzustand (`PageState`), Navigation und Systemeinstellungen automatisch zur Verfügung.
+Als technische Grundlage diente die Theme-Architektur von Oqtane. Das Layout wurde in einer zentralen Razor-Datei (`Theme.razor`) definiert, welche von der Basisklasse `ThemeBase` erbt. Durch diese Vererbung stehen im Theme automatisch zentrale Funktionen des Frameworks zur Verfügung, darunter der Seitenzustand (`PageState`), Navigationsdaten, Systemeinstellungen sowie Informationen über den aktuell angemeldeten Benutzer. Dies ermöglicht eine tiefe Integration des Themes in das CMS, ohne dass zusätzliche Schnittstellen oder externe Datenzugriffe notwendig sind.
 #### Navigationsleiste
-Im oberen Bereich wurde eine fixierte Navigationsleiste implementiert, die drei Hauptbereiche umfasst: links das Logo der Schule, in der Mitte die dynamisch generierten Navigationspunkte und rechts die Benutzerfunktionen (Login, Registrierung, Profil). Da die Standardkomponente `<Menu>` von Oqtane auch interne Systemseiten wie Login, Register oder NotFound ausgibt, wurde auf diese verzichtet. Stattdessen wurden eigene Komponenten implementiert, die von `MenuBase` bzw. `MenuItemsBase` erben. Die Seitenliste wird dabei über `PageState.Pages` abgerufen und mittels LINQ gefiltert – es werden nur Root-Seiten (`ParentId == null`) angezeigt, die als Navigationsseite markiert sind und nicht in einer definierten Ausschlussliste (`hiddenNames`) stehen.
+Ein zentrales Element des Themes ist die fixierte Navigationsleiste am oberen Rand der Seite. Sie ist in drei klar voneinander getrennte Bereiche gegliedert: Auf der linken Seite befindet sich das Logo der HTL Ungargasse, das als visuelles Erkennungsmerkmal der Schule dient und beim Klick zur Startseite führt. In der Mitte werden die Navigationspunkte der Plattform angezeigt, die dynamisch aus der Seitenstruktur des CMS generiert werden. Auf der rechten Seite befinden sich die Benutzerfunktionen, also Login, Registrierung und bei angemeldeten Benutzern ein Link zum eigenen Profil.
 Die dynamische Generierung der Navigationspunkte stellte dabei eine besondere Herausforderung dar. Das Oqtane-Framework stellt standardmäßig eine `<Menu>`-Komponente bereit, die automatisch alle im System registrierten Seiten in der Navigation anzeigt. Diese Komponente gibt jedoch nicht nur öffentlich sichtbare Inhaltsseiten aus, sondern auch interne Systemseiten wie Login, Register, Reset, Profile, Search, Privacy, Terms, Not Found oder Admin. Diese Seiten sind für den normalen Benutzer nicht relevant und sollten daher nicht in der Hauptnavigation erscheinen.
 Da die Standardkomponente das Burger-Menü automatisch generierte und keine Möglichkeit bot, dieses individuell anzupassen, wurde auf sie verzichtet. Da ein eigenes, maßgeschneidertes Burger-Menü benötigt wurde, wurde stattdessen eine vollständig eigene Navigation implementiert. Dabei wurde auf die Basisklassen `MenuBase` und `MenuItemsBase` zurückgegriffen, die von Oqtane bereitgestellt werden und den Zugriff auf die Seitenliste ermöglichen. Die Navigationspunkte werden direkt über `PageState.Pages` abgerufen und anschließend mittels LINQ gefiltert. Dabei werden nur Root-Seiten berücksichtigt, also Seiten ohne übergeordnete Seite (`ParentId == null`), die als Navigationsseite markiert sind und nicht in einer manuell definierten Ausschlussliste (`hiddenNames`) stehen.
 ```csharp
 var hiddenNames = new[]
@@ -101,27 +109,35 @@ foreach (var item in PageState.Pages
             .Where(p => p.ParentId == null
                         && !hiddenNames.Contains(p.Name)))
 {
-    <a class="nav-link text-white" href="@item.Path">
+    @item.Name
        @item.Name
    </a>
 }
 ```
-#### Responsive Design / Burger-Menü
+Durch diesen Ansatz werden ausschließlich die für Benutzer relevanten Inhaltsseiten in der Navigation angezeigt. Gleichzeitig bleibt die Navigation vollständig dynamisch: Werden im CMS neue Seiten angelegt und als Navigationsseiten markiert, erscheinen diese automatisch im Menü, ohne dass eine Anpassung am Theme-Code notwendig ist. Dies reduziert den Wartungsaufwand erheblich und stellt sicher, dass die Navigation stets dem aktuellen Stand der Plattform entspricht.
-Für mobile Endgeräte wurde ein Burger-Menü implementiert. Das Öffnen und Schließen der Sidebar erfolgt über eine CSS-Checkbox-Lösung ohne zusätzliche Frameworks. Die Sidebar zeigt alle Navigationspunkte vertikal untereinander an, wobei Login- und Registrierungsfunktionen am unteren Rand fixiert sind und unabhängig von der Anzahl der Menüpunkte stets sichtbar bleiben.
+#### Responsive Design und Burger-Menü
 Da die Plattform auch auf mobilen Endgeräten genutzt werden soll, war die Umsetzung eines responsiven Layouts eine wichtige Anforderung. Auf Desktop-Geräten werden alle Navigationspunkte direkt in der Navigationsleiste angezeigt. Auf kleineren Bildschirmen wie Smartphones oder Tablets würde dies jedoch zu Platzproblemen führen, da die Anzahl der Navigationspunkte die verfügbare Breite überschreiten kann.
 Aus diesem Grund wurde für mobile Endgeräte ein sogenanntes Burger-Menü implementiert. Dabei handelt es sich um ein Icon mit drei horizontalen Linien, das auf kleinen Bildschirmen anstelle der ausgeschriebenen Navigationspunkte angezeigt wird. Beim Anklicken öffnet sich eine seitliche Sidebar, in der alle Navigationspunkte vertikal untereinander dargestellt werden. Die Sidebar ist so aufgebaut, dass der obere Bereich die Navigationspunkte enthält und bei einer großen Anzahl von Einträgen gescrollt werden kann. Am unteren Rand der Sidebar sind die Login- und Registrierungsfunktionen fixiert, sodass diese unabhängig von der Anzahl der Navigationspunkte immer sichtbar und erreichbar sind.
 Die technische Umsetzung des Burger-Menüs basiert auf einer CSS-Checkbox-Lösung. Das Öffnen und Schließen der Sidebar wird über den Zustand einer versteckten Checkbox gesteuert, der mittels CSS-Selektoren ausgewertet wird. Dieser Ansatz ermöglicht eine funktionsfähige mobile Navigation ohne den Einsatz zusätzlicher JavaScript-Frameworks oder komplexer Logik. Die gesamte Darstellungslogik – also welche Elemente auf welcher Bildschirmgröße sichtbar sind – wird über CSS Media Queries gesteuert, die zwischen der Desktop- und der mobilen Ansicht unterscheiden.
 #### Pane-Struktur
-Für den Inhaltsbereich wurden mehrere Panes definiert (z.B. `Top 100%`, `Left 50%`, `Right Sidebar 33%`, `Bottom 100%`), die als flexible Platzhalter für Module dienen. Dadurch können Seiteninhalte ohne Änderungen am Theme-Code strukturiert werden.
+Für den Inhaltsbereich der Plattform wurden mehrere sogenannte Panes definiert. Panes sind in Oqtane Platzhalter-Bereiche innerhalb eines Themes, in die später Module oder Inhalte eingefügt werden können. Durch die Definition mehrerer Panes mit unterschiedlichen Breiten und Positionen können Seiten sehr flexibel und ohne Änderungen am Theme-Code strukturiert werden.
 Im entwickelten Theme stehen unter anderem folgende Panes zur Verfügung: ein vollbreiter Bereich oben (`Top 100%`), ein linker Bereich (`Left 50%`), eine rechte Seitenleiste (`Right Sidebar 33%`) sowie ein vollbreiter Bereich am unteren Rand (`Bottom 100%`). Diese Struktur ermöglicht es, Seiten sowohl ein- als auch mehrspaltig aufzubauen, je nach den Anforderungen des jeweiligen Inhalts.
 #### Weitere Integrationen
-Zusätzlich wurden die Cookie-Consent-Komponente sowie das ControlPanel für Administratoren integriert. Login- und Registrierungsoptionen werden über den `SettingService` aus den Site-Einstellungen geladen, sodass diese ohne Code-Anpassung gesteuert werden können.
+Neben Navigation und Layout wurden weitere Funktionen in das Theme integriert. Die Cookie-Consent-Komponente von Oqtane wurde eingebunden, sodass beim ersten Besuch der Plattform ein Hinweis zur Verwendung von Cookies angezeigt wird. Diese Funktion ist über die Site-Einstellungen von Oqtane steuerbar, das Theme rendert lediglich die entsprechende Komponente.
 Darüber hinaus wurde das ControlPanel von Oqtane integriert, das Administratorinnen und Administratoren direkten Zugriff auf Verwaltungsfunktionen bietet. Login- und Registrierungsoptionen werden über den `SettingService` aus den Site-Einstellungen geladen, sodass diese Funktionen ohne Anpassungen am Code aktiviert oder deaktiviert werden können.
 ### 6.3 Herausforderungen
-Eine der zentralen Herausforderungen bei der Entwicklung des Themes war die korrekte Filterung der Navigationsseiten. Die von Oqtane bereitgestellten Blazor-Standardkomponenten für die Navigation verhielten sich dabei nicht wie erwartet, da sie auch interne Systemseiten wie Login, Register oder NotFound in der Hauptnavigation ausgaben und keine ausreichende Möglichkeit boten, diese gezielt auszublenden. Aus diesem Grund wurde auf die Standardkomponenten verzichtet und stattdessen eine eigene Implementierung entwickelt. Durch den direkten Zugriff auf `PageState.Pages` sowie eine LINQ-basierte Filterlogik konnten die anzuzeigenden Seiten vollständig kontrolliert und Systemseiten zuverlässig ausgeblendet werden.
+Die größte Herausforderung bei der Theme-Entwicklung war die Umsetzung einer individuellen Navigation. Die von Oqtane bereitgestellte Standardkomponente generierte das Burger-Menü automatisch und bot keine Möglichkeit, dieses individuell anzupassen. Da ein eigenes, maßgeschneidertes Burger-Menü benötigt wurde, das sich nahtlos in das Theme-Design einfügt, wurde die Standardkomponente vollständig ersetzt und eine eigene Navigation implementiert. Durch den direkten Zugriff auf `PageState.Pages` und eine LINQ-basierte Filterlogik konnte eine vollständig kontrollierbare und flexibel gestaltbare Navigation realisiert werden. Dieser Ansatz erforderte zwar mehr Entwicklungsaufwand, ermöglichte dafür aber die gewünschte individuelle Gestaltung des Burger-Menüs.
 ---
@@ -129,21 +145,87 @@ Eine der zentralen Herausforderungen bei der Entwicklung des Themes war die korr
 ### 7.1 Anmeldetool
-#### Ziel des Moduls
+#### 7.1.1 Ziel des Moduls
-#### Frontend (Eingabemaske)
+Das Anmeldetool wurde entwickelt, um Mitgliedern des Absolventenvereins eine einfache und strukturierte Möglichkeit zu bieten, sich zu Veranstaltungen und Treffen an- oder abzumelden. Ziel des Moduls ist es, den organisatorischen Aufwand bei der Planung und Verwaltung von Treffen deutlich zu reduzieren und gleichzeitig eine benutzerfreundliche Oberfläche für alle Beteiligten bereitzustellen.
-#### Backend-Logik
+Das Modul wurde als zusätzliche Funktionserweiterung in das bestehende Content-Management-System integriert. Es ermöglicht sowohl die Verwaltung der Veranstaltungen auf Seiten der Organisatoren als auch eine intuitive Interaktion für die Teilnehmerinnen und Teilnehmer. Durch den Einsatz moderner Webtechnologien konnte dabei eine reaktionsschnelle und geräteübergreifend nutzbare Lösung geschaffen werden.
-#### API-Schnittstelle
+#### 7.1.2 Frontend (Eingabemaske)
-#### Datenauswertung
+Die Benutzeroberfläche des Anmeldetools wurde mithilfe von Blazor realisiert, einem Framework der ASP.NET-Technologieplattform, das die Entwicklung interaktiver Weboberflächen in C# ermöglicht. Die Eingabemaske wurde als eigenständige Blazor-Komponente implementiert, die flexibel in verschiedene Seiten der Anwendung eingebettet werden kann.
-#### UX-Überlegungen
+Beim Aufruf der Seite wird dem Benutzer zunächst eine kurze Beschreibung der jeweiligen Veranstaltung angezeigt. Im Anschluss stehen zwei klar gekennzeichnete Schaltflächen zur Verfügung: Zusagen zur Bestätigung der Teilnahme sowie Absagen zur Ablehnung. Die Schaltflächen wurden farblich differenziert gestaltet – eine grüne Hervorhebung signalisiert die Zusage, eine rote Darstellung steht für die Absage. Diese Gestaltung orientiert sich an etablierten Designkonventionen moderner Webanwendungen und verbessert die intuitive Bedienbarkeit erheblich. Darüber hinaus wurde besonderer Wert auf eine responsive Darstellung gelegt, damit das Tool sowohl auf Desktop-Geräten als auch auf Smartphones und Tablets problemlos genutzt werden kann.
 #### 7.1.3 API-Schnittstelle
 Die Anbindung des Anmeldetools an das bestehende CMS erfolgt über klar definierte Schnittstellen innerhalb der ASP.NET-Architektur. Die Komponente kommuniziert mit dem Backend, um Veranstaltungsdaten abzurufen sowie Anmelde- und Absagestatus der Teilnehmenden zu übermitteln und zu persistieren.
 Die Datenübertragung erfolgt nach dem Prinzip der sauberen Komponentenarchitektur: Die Blazor-Komponente ist als eigenständige Einheit konzipiert, die über Parameter und Rückruffunktionen mit übergeordneten Seitenkomponenten kommuniziert. Diese Struktur gewährleistet eine klare Trennung zwischen Darstellungslogik und Datenzugriff und erleichtert zukünftige Erweiterungen der Schnittstelle erheblich.
 #### 7.1.4 Datenauswertung
 Die im Anmeldetool erfassten Daten bilden die Grundlage für die Verwaltung und Auswertung von Veranstaltungsteilnahmen. Organisatoren können auf Basis der gespeicherten An- und Abmeldungen die Teilnehmerzahlen einsehen und die Planung entsprechend anpassen.
 Die Architektur des Moduls ist bereits auf zukünftige Erweiterungen ausgelegt. Geplante Erweiterungen umfassen eine übersichtliche Teilnehmerliste mit Namen und Anmeldestatus, die Möglichkeit eine maximale Teilnehmeranzahl je Veranstaltung festzulegen sowie eine direkte Speicherung und Auswertung der Anmeldedaten in einer Datenbank. Durch diese Erweiterungen soll das Anmeldetool künftig nicht nur als Interaktionselement für Teilnehmer, sondern auch als vollwertiges Verwaltungswerkzeug für Veranstaltungsorganisatoren dienen.
 #### 7.1.5 UX-Überlegungen (User Experience)
 Ein zentraler Aspekt bei der Entwicklung des Anmeldetools war die Benutzerfreundlichkeit der Oberfläche. UX (User Experience) bezeichnet dabei die Gesamtheit aller Erfahrungen, die ein Benutzer bei der Interaktion mit einer Anwendung macht – von der visuellen Gestaltung über die Bedienbarkeit bis hin zur allgemeinen Zufriedenheit mit dem System. Die Module wurden so gestaltet, dass Nutzerinnen und Nutzer die Funktionen ohne zusätzliche Schulung verwenden können. Eine klare Struktur, eine intuitive Bedienung sowie ein konsistentes Erscheinungsbild innerhalb des bestehenden Systems standen dabei im Vordergrund.
 Während der Testphase wurden mehrere visuelle Darstellungsprobleme identifiziert und behoben. Dazu zählten Fehler bei der Overlay-Darstellung – insbesondere in Bezug auf Hintergrundfarben, Transparenzen und z-Index-Ebenen – sowie sogenannte Clipping-Fehler auf mobilen Endgeräten, bei denen Inhalte teilweise abgeschnitten oder außerhalb des sichtbaren Bereichs angezeigt wurden. Die Layoutstruktur und Elementgrößen wurden angepasst, ausreichende Abstände zu Seitenrändern sichergestellt und Tests auf verschiedenen Browser- und Gerätevarianten durchgeführt.
 Diese Maßnahmen stellen einen ersten Schritt in der kontinuierlichen Verbesserung der mobilen Benutzeroberfläche dar. Weitere Feinabstimmungen sind geplant, um das Anmeldetool langfristig als stabile, benutzerfreundliche und geräteübergreifend konsistente Lösung zu etablieren.
 ### 7.2 Hall of Fame
-Das Hall-of-Fame-Modul ist ein Oqtane-Modul, das ehemalige Absolventinnen und Absolventen der Schule auf der Vereinswebseite präsentiert. Es wurde als eigenständiges, wiederverwendbares Modul innerhalb des Oqtane-Frameworks entwickelt und ermöglicht registrierten Benutzerinnen und Benutzern, sich selbst mit einem persönlichen Profil einzutragen. Die Einträge werden erst nach bewusster Veröffentlichung durch die jeweilige Person auf der öffentlichen Seite angezeigt, können als PDF exportiert werden und unterliegen einem Meldesystem zur Qualitätssicherung.
+Das Hall-of-Fame-Modul ist ein zentrales Modul der AlumniHub-Plattform. Es dient dazu, ehemalige Absolventinnen und Absolventen der HTL Ungargasse sichtbar zu machen und ihre beruflichen Werdegänge zu präsentieren. Das Modul wurde als eigenständiges, wiederverwendbares Oqtane-Modul entwickelt und ermöglicht es registrierten Benutzerinnen und Benutzern, sich selbst mit einem persönlichen Profil einzutragen.
 #### Benutzeroberfläche
 Die Benutzeroberfläche des Moduls besteht aus mehreren Komponenten, die zusammen eine vollständige und benutzerfreundliche Verwaltung der Hall-of-Fame-Einträge ermöglichen.
 ##### Übersichtsseite (Index.razor)
 Die Hauptseite der Hall of Fame ist die erste Seite, die Besucherinnen und Besucher zu sehen bekommen. Sie zeigt alle veröffentlichten Einträge in einem responsiven Kartenlayout. Auf Desktop-Geräten werden die Karten in drei Spalten nebeneinander dargestellt, auf kleineren Bildschirmen passt sich das Layout automatisch an und zeigt die Karten einspaltig untereinander an.
 Jede Karte enthält das Foto der jeweiligen Person als großes Vorschaubild im oberen Bereich. Darunter werden Name und Abschlussjahrgang als Überschrift angezeigt. Im unteren Bereich der Karte befindet sich ein Teaser der Beschreibung, also ein kurzer Ausschnitt aus dem Werdegang der Person. Da Beschreibungen unterschiedlich lang sein können, wurde die Kartenhöhe durch eine Kombination aus CSS-Flexbox und einer Maximalhöhe mit `overflow: hidden` vereinheitlicht. Dadurch weisen alle Karten in einer Zeile dieselbe Höhe auf, was ein sauberes und gleichmäßiges Erscheinungsbild der Übersichtsseite gewährleistet. Am unteren Rand jeder Karte befindet sich ein „Details ansehen"-Button, der die Besucherin oder den Besucher zur vollständigen Detailseite des Eintrags weiterleitet.
 Über der Kartenliste befindet sich eine Filterleiste mit einer Suchfunktion und einer Sortieroption. Die Suchleiste ermöglicht eine Echtzeit-Suche über Name und Beschreibung aller Einträge – die Ergebnisse aktualisieren sich direkt beim Tippen, ohne dass die Seite neu geladen werden muss. Neben der Suchleiste befindet sich ein Sortier-Dropdown, über das zwischen verschiedenen Sortierkriterien gewählt werden kann, darunter Datum, Name und Jahrgang. Ein Toggle-Button mit dynamischem Pfeil-Icon ermöglicht das Umschalten zwischen aufsteigender und absteigender Sortierrichtung.
 Für angemeldete Benutzerinnen und Benutzer wird im oberen rechten Bereich der Seite ein zusätzlicher Button angezeigt. Hat die Person noch keinen eigenen Eintrag erstellt, erscheint ein „Eintragen"-Button. Existiert bereits ein Eintrag, ändert sich der Button automatisch zu „Mein Eintrag", über den der bestehende Eintrag bearbeitet werden kann. Administratorinnen und Administratoren sehen zusätzlich Warnhinweise bei gemeldeten Einträgen sowie einen Lösch-Button bei jedem Eintrag.
 ##### Detailseite (Details.razor)
 Die Detailseite zeigt einen einzelnen Hall-of-Fame-Eintrag in seiner vollständigen Form. Das Layout ist zweispaltig aufgebaut: Auf der linken Seite befindet sich das Foto der Person, eingebettet in einen unscharfen Bildhintergrund, der dasselbe Foto in einer größeren, weichgezeichneten Version als Hintergrund verwendet. Dieser Effekt verleiht der Seite eine moderne und ansprechende Optik. Das eigentliche Foto ist dabei als klar umrandetes Porträtbild in der Mitte des linken Bereichs positioniert.
 Auf der rechten Seite werden zunächst eine Breadcrumb-Navigation („Hall of Fame / Details") sowie Name und Jahrgang der Person angezeigt. Der Jahrgang wird in blauer Schrift als „Absolvent des Jahrgangs [Jahr]" dargestellt, was einen visuellen Akzent setzt und den Jahrgang klar hervorhebt. Darunter folgt die vollständige Beschreibung unter der Überschrift „Werdegang & Erfolge".
 Am unteren Rand der Seite befinden sich je nach Konfiguration des Eintrags bis zu vier Buttons. Der „PDF Vorschau"-Button öffnet einen modalen Dialog mit einer vollständigen Vorschau des generierten PDFs sowie einem „Herunterladen"-Button. Der „Zurück"-Button führt zurück zur Übersichtsseite. Falls die Person einen optionalen Link hinterlegt hat, wird zusätzlich ein „Webseite besuchen"-Button angezeigt, der die Besucherin oder den Besucher direkt zur externen Webseite der Person führt. Für eingeloggte Benutzer gibt es außerdem einen „Melden"-Button, über den ein Eintrag gemeldet werden kann.
 ##### Edit-Seite (Edit.razor)
 Die Edit-Komponente dient sowohl zum Erstellen eines neuen Eintrags als auch zum Bearbeiten eines bestehenden. Das Formular ist klar strukturiert und enthält alle notwendigen Felder für einen vollständigen Hall-of-Fame-Eintrag.
 Das Formular enthält zunächst ein Textfeld für den Namen der Person sowie ein Zahlenfeld für den Abschlussjahrgang. Für die Beschreibung wird ein Rich-Text-Editor eingesetzt, der Formatierungsmöglichkeiten wie Fett, Kursiv, Listen und weitere Optionen bietet. Unterhalb des Editors wird ein Live-Zeichenzähler angezeigt, der die aktuelle Zeichenanzahl in Echtzeit aktualisiert und die maximal erlaubte Zeichenanzahl von 504 Zeichen anzeigt. Dadurch sehen Benutzerinnen und Benutzer jederzeit, wie viel Platz noch zur Verfügung steht.
 Für das Foto gibt es ein Upload-Feld mit einer Vorschaufunktion. Wird ein Bild ausgewählt, wird es sofort als Vorschau angezeigt, bevor der Eintrag gespeichert wird. Erlaubt sind nur JPG- und PNG-Dateien mit einer maximalen Größe von 5 MB. Zusätzlich gibt es ein optionales Link-Feld, in das eine externe Webseite der Person eingetragen werden kann.
 Am unteren Rand des Formulars befinden sich zwei Speicheroptionen: „Als Entwurf speichern" und „Veröffentlichen". Einträge im Entwurfsmodus sind nur für die eigene Person sichtbar und erscheinen nicht in der öffentlichen Übersicht. Erst durch das Veröffentlichen wird der Eintrag für alle Besucherinnen und Besucher sichtbar. Eine Eigentümerprüfung verhindert, dass Benutzerinnen und Benutzer fremde Einträge bearbeiten, und eine Duplikatprüfung stellt sicher, dass pro Person nur ein Eintrag erstellt werden kann.
 ##### Meldefunktion
 Die Meldefunktion ermöglicht es angemeldeten Benutzerinnen und Benutzern, einen Hall-of-Fame-Eintrag zu melden, wenn dieser unangemessene oder falsche Inhalte enthält. Durch Klicken auf den „Melden"-Button auf der Detailseite öffnet sich ein kleines Popup-Fenster, in das der Meldegrund eingetragen werden kann. Nach dem Absenden wird die Meldung in der Datenbank gespeichert und im Admin-Modul angezeigt. Administratorinnen und Administratoren können dort alle eingegangenen Meldungen einsehen und bei Bedarf den betreffenden Eintrag löschen oder freigeben.
 Die Meldefunktion ist dabei nicht direkt im Hall-of-Fame-Modul implementiert, sondern wird über eine zentrale Schnittstelle aus einem gemeinsamen Interfaces-Paket eingebunden. Dieses Konzept ermöglicht es, dieselbe Melde-Oberfläche in beliebig vielen weiteren Modulen wiederzuverwenden, ohne die Logik mehrfach implementieren zu müssen.
 ##### PDF-Export
 Der PDF-Export ist eine besondere Funktion des Hall-of-Fame-Moduls. Er ermöglicht es Benutzerinnen und Benutzern, ihren Eintrag als visuell ansprechendes PDF-Dokument herunterzuladen. Die PDF-Generierung wird über die Open-Source-Bibliothek QuestPDF in der Community-Edition realisiert.
 Das generierte PDF folgt einem Glasmorphismus-Design und ist im Format DIN A4 gehalten. Das Foto der Person wird als vollflächiges Hintergrundbild verwendet, das die gesamte Seite ausfüllt. Im oberen Bereich der Seite befindet sich ein halbtransparenter dunkler Bereich, in dem der Name der Person in großen Großbuchstaben mit weitem Zeichenabstand dargestellt wird. Darunter wird der Jahrgang mit erhöhtem Zeichenabstand angezeigt. Im unteren Bereich der Seite befindet sich ein weiterer halbtransparenter Bereich mit der vollständigen Beschreibung. Der charakteristische Glaseffekt wird durch mehrschichtige halbtransparente Hintergründe mit abgerundeten Ecken erzeugt, die dem Dokument ein modernes und professionelles Erscheinungsbild verleihen.
 Die PDF-Vorschau kann direkt auf der Detailseite über den „PDF Vorschau"-Button geöffnet werden. Es öffnet sich ein modaler Dialog, der das generierte PDF in einer Vorschau anzeigt. Über einen „Herunterladen"-Button kann das PDF direkt auf das Gerät gespeichert werden.
 #### Datenmodell
@@ -171,7 +253,7 @@ Die zentrale Entität repräsentiert einen einzelnen Absolventeneintrag und wird
 | `ModifiedBy` | `string` | Zuletzt geändert von (Audit) |
 | `ModifiedOn` | `DateTime` | Zeitpunkt der letzten Änderung (Audit) |
-Die Entität implementiert das Oqtane-Interface `IAuditable`, wodurch die Audit-Felder automatisch vom Framework befüllt werden. Der Fremdschlüssel `ModuleId` verknüpft jeden Eintrag mit einer bestimmten Modulinstanz und ermöglicht so den Multi-Tenant-Betrieb: Mehrere Hall-of-Fame-Module auf verschiedenen Seiten der Website verwalten jeweils unabhängige Datensätze.
+Die Entität implementiert das Oqtane-Interface `IAuditable`, wodurch die Audit-Felder automatisch vom Framework befüllt werden. Der Fremdschlüssel `ModuleId` verknüpft jeden Eintrag mit einer bestimmten Modulinstanz und ermöglicht so den Multi-Tenant-Betrieb.
 **Entität HallOfFameReport**
@@ -187,57 +269,25 @@ Die zweite Entität bildet einzelne Meldungen zu einem Eintrag ab und wird in de
 | `ModifiedBy` | `string` | Zuletzt geändert von (Audit) |
 | `ModifiedOn` | `DateTime` | Zeitpunkt der letzten Änderung (Audit) |
-Der Fremdschlüssel zu `SZUAbsolventenvereinHallOfFame` ist mit kaskadierendem Löschen konfiguriert, sodass beim Löschen eines Eintrags automatisch alle zugehörigen Meldungen entfernt werden. Zwischen den beiden Entitäten besteht somit eine 1:n-Beziehung: Ein Eintrag kann beliebig viele Meldungen besitzen.
+Der Fremdschlüssel zu `SZUAbsolventenvereinHallOfFame` ist mit kaskadierendem Löschen konfiguriert, sodass beim Löschen eines Eintrags automatisch alle zugehörigen Meldungen entfernt werden. Zwischen den beiden Entitäten besteht eine 1:n-Beziehung: Ein Eintrag kann beliebig viele Meldungen besitzen.
 #### Datenbankmigrationen
-Die Datenbankstruktur wird über Entity Framework Core Migrationen versioniert verwaltet. Oqtane verwendet ein eigenes Migrationssystem, das auf der Klasse `MultiDatabaseMigration` basiert und die Kompatibilität mit verschiedenen Datenbankanbietern sicherstellt.
+Die Datenbankstruktur wird über Entity Framework Core Migrationen versioniert verwaltet.
 | Migration | Versionsnummer | Inhalt |
 |-----------|----------------|--------|
-| `InitializeModule` | `01.00.00.00` | Erstellt die Haupttabelle mit allen Grundspalten (Name, Year, Description, Image, Link, Status, UserId) sowie den Audit-Spalten |
+| `InitializeModule` | `01.00.00.00` | Erstellt die Haupttabelle mit allen Grundspalten sowie den Audit-Spalten |
 | `AddReportingColumns` | `01.00.00.02` | Erweitert die Haupttabelle um die Spalten `IsReported` und `ReportReason` |
 | `AddReportTable` | `01.00.00.03` | Erstellt die eigenständige Report-Tabelle mit Fremdschlüssel zur Haupttabelle |
 Jede Migration definiert sowohl eine Aufwärts- als auch eine Abwärtsmethode, sodass ein Rollback möglich ist.
 #### Benutzeroberfläche (Razor-Komponenten)
 Das Modul umfasst vier Blazor-Razor-Komponenten.
 **Index.razor – Übersichtsseite**
 Die Übersichtsseite zeigt alle veröffentlichten Einträge in einem responsiven Kartenlayout mit drei Spalten auf Desktop-Breite. Die Funktionalität umfasst eine Echtzeit-Textsuche über Name und Beschreibung, eine umschaltbare Sortierung nach Datum, Name oder Jahrgang sowie eine Kartenanzeige mit Bild, Name, Jahrgang und gekürzter Beschreibung. Administratorinnen und Administratoren sehen zusätzlich Warnmeldungen bei gemeldeten Einträgen und einen Lösch-Button. Angemeldete Benutzerinnen und Benutzer können über einen eigenen Button ihren Eintrag erstellen oder bearbeiten.
 **Edit.razor – Erstellungs- und Bearbeitungsseite**
 Die Edit-Komponente dient sowohl zum Erstellen als auch zum Bearbeiten eines Eintrags. Sie bietet Formularfelder für Name, Jahrgang, Beschreibung (mit Live-Zeichenzähler), Foto-Upload und Link. Über zwei Speicheroptionen kann zwischen Entwurf und Veröffentlichung gewählt werden. Eine Eigentümerprüfung verhindert das Bearbeiten fremder Einträge, und eine Duplikatprüfung verhindert das Erstellen mehrerer Einträge pro Person.
 **Details.razor – Detailseite**
 Die Details-Komponente zeigt einen einzelnen Eintrag in einem zweispaltigen Layout mit unscharfem Bildhintergrund. Administratorinnen und Administratoren sehen bei gemeldeten Einträgen eine Liste aller Meldungen mit Lösch-Button. Ein modaler Dialog ermöglicht die PDF-Vorschau sowie den Download. Die Meldefunktion wird über die zentrale `IReportUI`-Komponente eingebunden.
 **Settings.razor – Moduleinstellungen**
 Die Settings-Komponente bietet eine einfache Oberfläche für Moduleinstellungen über Oqtanes Setting-Service.
 #### Gemeinsame Melde-Komponente (IReportUI)
 Die Meldefunktion in der Detailseite ist nicht direkt im Hall-of-Fame-Modul implementiert, sondern wird über eine zentrale Schnittstelle aus dem Interfaces-Paket eingebunden. Das Hall-of-Fame-Modell implementiert das Interface `IReportable`, das eine Entität als meldbar kennzeichnet. In der Detailseite wird per Dependency Injection eine `IReportUI`-Implementierung injiziert – die konkrete `ReportComponent` stammt dabei aus dem Admin-Modul und stellt den Melden-Button samt modalem Dialog bereit. Die Komponente wird über Blazors `DynamicComponent` dynamisch gerendert. Ist keine Implementierung im Container registriert, wird die Meldefunktion schlicht nicht angezeigt. Dieses Konzept ermöglicht es, die Melde-Oberfläche zentral zu pflegen und in beliebig vielen weiteren Modulen wiederzuverwenden, ohne dass die einzelnen Module die Melde-Logik selbst implementieren müssen.
 #### PDF-Export mit QuestPDF
 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.
+In der ursprünglichen Version des Moduls mussten Benutzerinnen und Benutzer eine Bild-URL manuell in ein Textfeld eingeben. Dies war wenig benutzerfreundlich und erforderte, dass Bilder zunächst anderweitig hochgeladen und verlinkt werden mussten. 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**
@@ -279,37 +329,57 @@ Die ursprünglich fest codierten Sortierrichtungen wurden durch einen Toggle-But
 #### 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.
+Da AlumniHub zum Zeitpunkt des ersten Absolventenstreffens im Sommer 2025 noch nicht vollständig fertiggestellt war und das Hosting von Oqtane auf dem Hetzner-Server zu unerwarteten technischen Problemen geführt hatte, wurde im Team die Entscheidung getroffen, eine eigenständige Übergangslösung zu entwickeln. Diese sollte pünktlich zur Veranstaltung einsatzbereit sein und die wichtigsten Funktionen abdecken: die Möglichkeit für Absolventinnen und Absolventen, ihre Teilnahme am Treffen zu bestätigen oder abzusagen, sowie die Möglichkeit, direktes Feedback zum Diplomprojekt AlumniHub abzugeben.
-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.
+Da für die Entwicklung nur wenig Zeit zur Verfügung stand und eine vollständige Integration in die noch nicht fertige AlumniHub-Plattform nicht realistisch war, wurde bewusst auf einen schlanken, eigenständigen Technologie-Stack gesetzt. Dieser sollte schnell entwickelt, einfach deploybar und zuverlässig betreibbar sein – ohne die Komplexität eines vollständigen CMS-Systems.
 Das Frontend der Übergangslösung wurde mit den grundlegenden Webtechnologien HTML, CSS und JavaScript umgesetzt. Die Hauptseite (`index.html`) präsentiert den Besucherinnen und Besuchern eine übersichtliche und schlichte Oberfläche, die sich am Erscheinungsbild der HTL Ungargasse orientiert – mit dem Schullogo im Header und einem Grau-Weiß-Farbschema. Im Mittelpunkt der Seite befindet sich ein zentraler Button, über den ein modales Overlay-Formular geöffnet werden kann. Über dieses Formular konnten Nutzerinnen und Nutzer ihre E-Mail-Adresse eingeben und ihr Feedback zum Projekt abgeben. Die Steuerung des Overlays erfolgt über JavaScript: Das Formular öffnet sich beim Klick auf den Button und schließt sich automatisch, wenn außerhalb des Formularfensters geklickt wird. Dadurch ist eine intuitive Bedienung ohne zusätzliche Schaltflächen möglich.
 Für die Verarbeitung von Zu- und Absagen zum Absolvententreffen wurden zusätzlich zwei separate Bestätigungsseiten erstellt: `zusage.html` und `absage.html`. Diese Seiten werden dem Nutzer nach dem erfolgreichen Absenden des jeweiligen Formulars angezeigt und bestätigen den Eingang der Rückmeldung. Das Design aller drei Seiten ist einheitlich gehalten und folgt dem gleichen Layout-Prinzip mit Header, Logo und zentriertem Hauptinhalt.
 Das Backend der Lösung, das für die Verarbeitung der Formulardaten und den Versand von Bestätigungs-E-Mails zuständig war, wurde von einem Teammitglied entwickelt und war nicht Teil des eigenen Aufgabenbereichs. Es wurde mit Node.js und dem Framework Express umgesetzt und auf einem virtuellen Server bei Hetzner Cloud gehostet.
 #### 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.
+Im direkten Vergleich zur finalen AlumniHub-Plattform unterscheidet sich die Übergangslösung in mehreren wesentlichen Punkten. Während AlumniHub auf dem vollständigen CMS Oqtane basiert und eine umfangreiche Funktionspalette bietet – darunter Benutzerverwaltung, Hall of Fame, Anmeldetool, Datenauswertung und ein individuelles Theme – beschränkte sich die Übergangslösung bewusst auf das absolut Notwendige.
 Es gab keine Benutzerkonten und keine Authentifizierung. Jede Person, die die Seite aufrief, konnte das Formular ausfüllen und absenden, ohne sich vorher registrieren oder anmelden zu müssen. Es gab keine Datenbank im klassischen Sinne – die eingegangenen Formulardaten wurden serverseitig als einfache JSON-Dateien gespeichert. Es gab keine administrativen Funktionen, keine Übersichten und keine Möglichkeit, die Daten direkt über eine Benutzeroberfläche auszuwerten.
 Diese bewusste Reduktion auf das Wesentliche war jedoch kein Nachteil, sondern eine pragmatische Entscheidung: Die Lösung musste schnell funktionieren und zuverlässig sein – und das war sie. Nach dem Absolvententreffen wurde die Seite nicht einfach abgeschaltet, sondern zu einer reinen Feedback-Seite für das Diplomprojekt umfunktioniert. Über diese Seite konnten Interessierte – darunter Lehrkräfte, Mitschülerinnen und Mitschüler sowie externe Besucher der Präsentation – weiterhin direktes Feedback zum Projekt abgeben. Die Seite blieb so lange in Betrieb, bis die vollständig entwickelte AlumniHub-Plattform diese Funktion nativ ü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.
+Eine der größten technischen Herausforderungen im gesamten Projektverlauf war der Zeitdruck, der insbesondere im Vorfeld des ersten Absolventenstreffens spürbar war. Da AlumniHub zu diesem Zeitpunkt noch nicht einsatzbereit war, musste die Übergangslösung in sehr kurzer Zeit konzipiert, entwickelt und in Betrieb genommen werden. Dieser Zeitdruck führte dazu, dass keine ausreichende Zeit für gründliches Testen oder für die Umsetzung zusätzlicher Funktionen blieb.
 Ein weiteres technisches Problem betraf das Hosting von Oqtane auf dem Hetzner-Server. Die Einrichtung und der Betrieb von Oqtane auf dem Server bereiteten unerwartete Schwierigkeiten, die den regulären Entwicklungsfortschritt verlangsamten. Da dieser Bereich nicht zum eigenen Aufgabengebiet gehörte, konnten die genauen Ursachen nicht vollständig nachvollzogen werden. Die Probleme wirkten sich jedoch auf den gesamten Zeitplan des Projekts aus und waren mitverantwortlich dafür, dass AlumniHub zum Zeitpunkt des ersten Treffens noch nicht fertig war.
 #### 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.
+Neben den technischen Herausforderungen gab es auch auf organisatorischer Ebene ein zentrales Problem, das den Projektverlauf im Sommer 2025 erheblich beeinflusste. Während der Sommermonate war die aktive Mitarbeit innerhalb des Teams sehr ungleich verteilt. Ein Großteil der Teammitglieder war urlaubsbedingt nicht oder nur eingeschränkt erreichbar und beteiligte sich in dieser Zeit kaum am Projekt. Nur ein kleiner Teil des Teams arbeitete in dieser Phase aktiv weiter und trieb den Fortschritt voran.
 Diese Situation führte zu einer deutlichen Ungleichverteilung der Arbeitsbelastung. Wenige Personen mussten in dieser Zeit deutlich mehr Verantwortung übernehmen als ursprünglich geplant, was zu Frustration und Verzögerungen führte. Im Nachhinein zeigt sich, dass klarere Absprachen und verbindlichere Vereinbarungen zu Beginn des Sommers dazu beigetragen hätten, diese Situation zu vermeiden oder zumindest abzumildern.
 ### 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.
+Das Projekt hat auf technischer Ebene wertvolle praktische Kenntnisse vermittelt, die über den schulischen Rahmen hinausgehen. Der konsequente Einsatz von Git zur Versionskontrolle war dabei eine der wichtigsten Erfahrungen. Durch die tägliche Arbeit mit Branches, Commits und Merges wurde ein tiefes Verständnis für kollaborative Softwareentwicklung aufgebaut. Es wurde deutlich, wie wichtig aussagekräftige Commit-Nachrichten, regelmäßige Commits und eine saubere Branch-Struktur für die Zusammenarbeit im Team sind.
 Im Bereich Responsive Design wurden durch die praktische Umsetzung des Themes und der Übergangslösung wichtige Kenntnisse vertieft. Es wurde erfahren, wie man mit CSS Media Queries und Flexbox Layouts baut, die sich zuverlässig an unterschiedliche Bildschirmgrößen anpassen. Besonders die Umsetzung des Burger-Menüs für mobile Geräte war eine lehrreiche Erfahrung, die zeigte, wie man komplexe UI-Funktionen mit minimalem JavaScript-Einsatz realisieren kann.
 Auch der Umgang mit JavaScript zur Steuerung von UI-Elementen wurde durch die Arbeit am Projekt verbessert. Die Implementierung der Overlay-Steuerung in der Übergangslösung sowie die Menü-Logik im Theme haben gezeigt, wie JavaScript gezielt und effizient eingesetzt werden kann, um eine bessere Benutzererfahrung zu schaffen.
 #### 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.
+Auf methodischer Ebene hat das Projekt gezeigt, wie wichtig eine klare und verbindliche Aufgabenverteilung von Beginn an ist. In Phasen, in denen nicht klar war, wer welche Aufgaben übernimmt, entstanden Lücken und Verzögerungen. Eine strukturiertere Planung mit klar definierten Zuständigkeiten hätte in solchen Situationen geholfen, den Überblick zu behalten und die Arbeit effizienter aufzuteilen.
 Darüber hinaus hat sich gezeigt, dass regelmäßige Team-Meetings ein wichtiges Werkzeug für den Projekterfolg sind. In Phasen, in denen der Austausch im Team spärlicher war, dauerte es länger, bis Probleme erkannt und gelöst wurden. Kurze, regelmäßige Abstimmungen hätten dazu beigetragen, den aktuellen Stand besser zu kommunizieren und gemeinsam schneller auf Hindernisse zu reagieren.
 #### 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.
+Auf persönlicher Ebene war die wichtigste Erkenntnis aus diesem Projekt die Bedeutung von Eigeninitiative. In einem größeren Teamprojekt kann man sich nicht immer darauf verlassen, dass andere Aufgaben erledigen oder Entscheidungen treffen. Gerade in den Phasen, in denen nicht alle Teammitglieder aktiv waren, hat sich gezeigt, dass proaktives Handeln entscheidend ist, um das Projekt voranzubringen. Diese Erfahrung hat das Bewusstsein dafür gestärkt, Verantwortung nicht nur für den eigenen Bereich, sondern auch für das Gesamtprojekt zu übernehmen und bei Bedarf auch Aufgaben außerhalb des ursprünglich geplanten Bereichs zu übernehmen.
 ---
@@ -323,12 +393,4 @@ Eine wichtige persönliche Erkenntnis war, dass Eigeninitiative in einem Teampro
 ### Bekannte Einschränkungen
---
+---
 ## 11. Fazit & Ausblick
 ### Zielerreichung & Zusammenfassung
 ### Persönliche Reflexion
 ### Erweiterungsmöglichkeiten
--- a/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
+++ b/Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md
@@ -5,92 +5,75 @@ gitea: none
 ## 1. Einleitung des individuellen Teils
-In diesem Abschnitt wird meine persönliche Aufgabenstellung im Rahmen des Projektes (`Alumnihub`) beschrieben.
+In diesem Abschnitt wird meine persönliche Aufgabenstellung im Rahmen des Projektes (`Alumnihub`) beschrieben. 
 ### 1.1 Auftrag / persönliche Aufgabenstellungen
 ### Auftrag / persönliche Aufgabenstellungen
 Meine Zuständigkeiten und Verantwortlichkeiten:
 - Product Owner
 - Infrastruktur
 - Entwicklung
 - Auswertungen
 - Schwarzes Brett
-### 1.2 Motivation
+### Motivation
-Gegenstand der Diplomarbeit ist die Entwicklung modularer Webanwendungen mit Blazor und Oqtane. Aufbauend auf fundierten Kenntnissen in der Fullstack-Entwicklung (React, Node.js, Golang), welche privat bei diversen Projekten gesammelt worden sind, fokussiert sich die Arbeit auf die Architekturvorteile des .NET-Stacks. Besonders im Fokus stehen die Konsistenz durch statische Typisierung sowie das Zusammenspiel modularer Komponenten in verteilten Systemen.
+Lernen von ASP.NET und der Entwicklung mit Blazor und Oqtane. Ich habe Interesse an dem Thema Webentwicklung. Privat entwickle ich schon seit Jahren viel mit React.JS.
 Mein Untersuchungsanliegen: Inwieweit optimiert die Integration von Blazor und dem Oqtane-Framework die Konsistenz und Wartbarkeit modularer Web-Architekturen im Vergleich zu den für mich gewohnten Technologie-Stacks (React/Node.js)?
 ## 2. Anforderungen an das entwickelte Modul bzw. die Funktionalität
 ### 2.1 Modulanforderungen / funktionale Anforderungen
 ### 2.2 Infrastrukturanforderungen / nicht‑funktionale Anforderungen
 - funktionale / nicht‑funktionale Anforderungen
 - Use Cases
-## 3. Technisches Umfeld
+## 3. Technische Grundlagen
-
+Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services. Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht habe. 
 Mein Aufgabenbereich umfasst einerseits die Entwicklung eigener Module, sowie das Bereitstellen des Services.
 ### 3.1 Auswahlverfahren
 #### 3.1.1 Entscheidungsfindung CMS
 Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterricht fast ausschließlich mit C# entwickelt haben und nicht in eine komplett unbekannte Entwicklungsumgebung abdriften wollten, haben wir uns für die Webentwicklung mit ASP.NET Core 9 (Upgrade im Lauf der Diplomarbeit auf .NET Core 10) und dem CMS Oqtane entschieden. Auch hier gab es einige Kandidaten:
 (Diese Entscheidung wurde gemeinsam getroffen:)
 Auch steht die Wahl der Programmiersprache und des CMS an. Nachdem wir im Unterricht fast ausschließlich mit C# entwickelt haben und nicht in eine komplett unbekannte Entwicklungsumgebung abdriften wollten, haben wir uns für Webentwicklung mit ASP.NET Core 9 und (Upgrade im Lauf der Diplomarbeit auf .NET Core 10) dem CMS Oqtane entschieden. Auch hier gab es einige Kandidaten:
 - Piranha CMS
-  > Piranha erscheint auf den ersten Blick nicht so flexibel wie Oqtane, es basiert auf .NET 8.0 und wird nicht so aktiv gewartet.
+  >Piranha erscheint auf den ersten Blick nicht so flexibel wie Oqtane, basiert auf .NET 8.0 und wird nicht so aktiv gewartet.
 - Umbraco
-  > Bei Umbraco muss viel in der Admin Oberfläche von dem CMS gearbeitet werden, im Großen und Ganzen wirkt dieses CMS nicht so flexibel. Die Dokumentation wirkt auf den ersten Blick sehr gut!
+  >Viel Arbeit mit Partials, welche in der Admin Oberfläche geschieht, aber sehr gut dokumentiert. Im großen und ganzen wirkt Umbraco nicht so flexibel.
 - DNN / Dot Net Nuke
-  > Dieses CMS ist der Platzhirsch. Es wird von der DNN Foundation gewartet, arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server ist im Betrieb teurer und in der Absicherung aufwändiger.
+  >Platzhirsch. Kennt man, wird von der DNN Foundation gewartet. Arbeitet mit dem Dotnet Framework, welches nicht unter Linux läuft. Und ein Windows Server würde ich ich nicht einfach so ins Internet, abgesehen von den Lizenzkosten, die das kosten würde.
 - Oqtane
-  > Oqtane wirkt auf sehr modular und flexibel, auch innerhalb von Modulen kann man auf alle Funktionen des ASP.NET Core Frameworks verwenden. Die Dokumentation wirkt nicht besonders gut, aber ausreichend. Die enthaltenen Fehlinformationen und mangelnden Anleitungen für den Betrieb mit Linux sind erst im Nachhinein aufgefallen.
+  >Schlecht dokumentiert, auf den ersten Blick sehr modular und flexibel. 
-Insbesondere aufgrund seiner sehr hohen Flexibilität, haben wir uns am Ende für Oqtane entschieden.
+Am Ende haben wir uns für das Oqtane Framework trotz seiner schlechten Dokumentation entschieden.
-#### 3.1.2 Entscheidungsfindung restliche Infrastruktur
+Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen. 
 1. Auf welche Art Datenbank setzen wir? SQL, NoSQL, Graph, ... 
 2. Mit welcher speziellen implementiereung bekommen wir Support und haben Wissen im Team?
 3. Ist das auserkorene System kompatibel mit dem CMS auf dem wir aufbauen?
-Als Betriebssystem habe ich mich für Linux entschieden, einfach, da ich mit Linux im Serverumfeld die meisten und besten Erfahrungen gemacht habe.
+Es war von Anfang an klar, dass es ein SQL basiertes System wird, da wir im Team nur mit SQL-basierten Systemen erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbanken in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem DBMS, welche ich im Nebenjob errungen habe.
 Im Bereich der Datenbanken musste ich mir ein paar Fragen stellen:
 1. Auf welche Art Datenbank setzen wir? SQL, NoSQL, Graph, ...
 2. Mit welcher speziellen Implementierung bekommen wir Support und bei welcher haben wir Vorwissen im Team?
 3. Ist das auserkorene System kompatibel mit dem CMS, auf dem wir aufbauen?
 Es war von Anfang an klar, dass es ein SQL-basiertes System wird, da wir im Team nur mit SQL-basierten Systemen Erfahrungen haben. Außerdem unterstützt unser CMS (Oqtane) nur SQL-basierte Systeme. In der Linuxwelt kommen jetzt nur noch ein paar Datenbankmanagementsysteme in die Auswahl: PostgreSQL, MySQL / MariaDB, SQLite. Da ist die Wahl auf PostgreSQL gefallen. Grund dafür war meine Vorerfahrung mit diesem Datenbankmanagementsystem, welche ich in meinem Nebenjob erlangt habe.
 ### 3.2 Beschreibung und Architektur von Oqtane
 # Technologie
 ## Entwicklung mit ASP.NET (Was ist Blazor? / Was ist Razor? / Kestrel)
 ## Was ist Oqtane? Architektur von Oqtane?
 Oqtane ist ein Framework und CMS zur Entwicklung von Webseiten mithilfe von ASP.NET und Blazor. [^5] Ein Oqtane-System besteht aus mehreren Komponenten.
 In dieser Diplomarbeit fokussieren wir uns hauptsächlich auf `Themes` und `Modules`, aber es gibt auch `Language Packs` und `Pure Extensions`. [^6]
-Ein `Module` (Modul) soll neue Funktionalitäten in das CMS hinzufügen und ein `Theme` soll die ganze Gestaltung der Webseite (die Shell) festlegen. [^6]
+Ein `Module` (Modul) soll neue Funktionalitäten in das CMS hinzufügen und ein `Theme` soll die ganze Gestaltung der Website (die Shell) festlegen. [^6]
-#### 3.2.1 Architektur eines Moduls
+[^5]: https://www.oqtane.org/#about
 [^6]: https://docs.oqtane.org/dev/extensions/index.html
-Ein Modul in Oqtane besteht aus vier Projekten:
+### Architektur eines Moduls
 Ein Modul in Oqtane besteht aus 4 Projekten. Server, Client, Shared und Package.
- Im Server-Projekt liegt Sourcecode, welcher serverseitig ausgeführt werden soll. Dazu gehören unter anderem alle Repositories, Controller, Manager, Migrationen und Server-Services und Server-Startuplogik.
+Im Server-Projekt liegt Sourcecode, welcher serverseitig ausgeführt werden soll. In der Praxis bedeutet das: alle Repositories, Controller, Manager, Migrationen und Server-Services (entwickelt nach einem Interface definiert im Client) und Server-Startuplogik.
- Im Client-Projekt liegen Code und Razor-Komponenten für den Client. Also Client-Startuplogik, Client-Services, Ressourcendateien (.resx), die Komponenten / das User Interface und die Moduldefinitionen für jedes Modul.
+Im Client-Projekt liegen Code und Razor-Komponenten für den Client. Also Client-Staruplogik, Client-Services (+ Inferfaces dafür, die Services hier sollen lediglich die Server-Services über HTTP aufrufen), Ressourcendateien (.resx), die Komponenten / das User Interface und die Moduldefinitionen für jedes Modul.
- Im Shared-Projekt wird geteilter Sourcecode abgelegt, der server- und clientseitig verwendet wird. In der Praxis bleibt es hierbei bei den EntityFramework-Modellen zum Speichern der Daten im Arbeitsspeicher.
+Im Shared-Projekt wird geteilter Sourcecode abgelegt, der server- und clientseitig verwendet wird. In der Praxis bleibt es hierbei bei den EntityFramework-Modellen zum Speichern der Daten im Arbeitsspeicher.
- Im Package Projekt findet man Skripte zum Debuggen und Releasen eines Moduls und die NuGet-Spezifikation.
+Im Package Projekt findet man Skripte zum Debuggen und Releasen eines Moduls. Und die NuGet-Spezifikation.
-  - Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte und Stylesheets der drei anderen Projekte in den bereits gebauten Oqtane.Server `oqtane.framework/oqtane.server/bin/debug/net10.0/...` kopiert.
+- Beim Debug werden die DLLs, PDBs und statischen Assets wie Skripte und Stylesheets der 3 anderen Projekte in den bereits gebauten Oqtane.Server `oqtane.framework/oqtane.server/bin/debug/net10.0/...` kopiert.
-  - Beim Release wird ein NuGet-Paket erstellt und unter oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte NuGet-Pakete werden beim nächsten Start des Oqtane Servers installiert (Datenbank Migrationen werden gemacht und die Pakete entpackt).
+- Beim Release wird ein NuGet-Paket erstellt und unter oqtane.framework/oqtane.server/Packages abgelegt. Dort abgelegte NuGet-Pakete werden beim nächsten Start des Oqtane Servers installiert (DB Migrationen werden gemacht und die Pakete entpackt).
 ### 3.3 Zusammenspiel der Infrastruktur
 In diesem Kapitel erkläre ich wie die ausgewählten Komponenten zusammenspielen. Wir verwenden NginX als Reverse Proxy, welcher bei uns die SSL Terminierung macht. Das Zertifikat, welches verwendet wird, wird von Let's Encrypt bereit gestellt und mittels HTTP-Challenges und dem Certbot auf dem Server aktualisiert und verwaltet. Oqtane selber läuft als Systemd-Service im Kestrel Backend. Kestrel ist ein kleiner Webserver, welcher in das ASP.NET Core Framework eingebaut worden ist. Oqtane (bzw. der ASP.NET Core Server "Kestrel") hört auf der Loopback IP und Port 5000. Damit ist Oqtane nur durch NginX erreichbar. PostgreSQL ist die Datenbank in dem System: Sie hört wieder auf der Loopback IP und Port 5432. In der folgenden Grafik ist das System Schematisch dargestellt.
 ## Systemarchitektur (Postgres / Oqtane / Nginx )
 ```mermaid
 architecture-beta
    group server(server)[Server]
@@ -98,87 +81,22 @@ architecture-beta
    service db(database)[PostgreSQL] in server
    service oqtane(server)[Oqtane] in server
    service nginx(server)[NginX] in server
-
+    
-    service internet(cloud)[Internet]
+    service internet(cloud)[Internet] 
    internet:R <--> L:nginx
    nginx:R <--> L:oqtane
    oqtane:R <--> L:db
 ```
 ## Websockets und HTTP 1.1 
 Zusätzlich gab es einen Administrationszugang zu den Servern, welcher über SSH möglich war. Dieser wurde für die Installation und Konfiguration der einzelnen Komponenten verwendet. Der SSH Service ist in jeder Umgebung anders erreichbar gewesen.
-| Umgebung   | Administrationszugang |
+## Dependency injection
 | ---------- | --------------------- |
 | Hetzner    | Wireguard             |
 | Schule     | Highport              |
 | LiveDesign | IPSEC VPN             |
 Die VPN basierten Zugänge sind tendenziell schwieriger zu finden und auszunutzen, während die Lösung in der Schule mittels Highport den SSH Service öffentlich erreichbar macht. Durch den `Highport` ist der SSH Service schwieriger zu finden. Zur Authentifizierung mit SSH verwenden wir SSH-Keys, da diese durch ihre komplexität sicherer sind, als Passwörter.
 ### 3.4 Entwicklung mit ASP.NET
 #### 3.4.1 Blazor [^7]
 Blazor ist ein kostenloses und quelloffenes Web-Framework, welches es möglich macht Benutzeroberflächen für Web-Browser, basierend auf C# und HTML, zu erstellen. Es wird von Microsoft als teil des ASP.NET Core Frameworks entwickelt.
 Blazor hat mehrere Hosting-Modelle:
 - Blazor Web App: Hier wird die Web App als Teil einer ASP.NET Core Anwendung bereitgestellt. Dabei gibt es mehrere Render Modi:
  - Static Server: Die Komponente wird serverseitig gerendert und besitzt keine Interaktivität. Es ist der standardmäßige `RenderMode`
  - Interactive Server: Die Komponente wird serverseitig gerendert, diesmal ist sie jedoch interaktiv. Das bedeutet, man kann mithilfe von C# den Zustand der Seite dynamisch bearbeiten. Diese Zustandsänderungen werden serverseitig bearbeitet. Hierbei kommunizieren Server und Client mithilfe von SignalR über WebSockets miteinander.
  - Interactive WebAssembly: Die Komponente wird clientseitig, also im Browser, gerendert. Damit der Blazor C# Code auch im Browser ausgeführt werden kann, wird dieser in WebAssembly kompiliert.
  - Interactive Auto: Im `Interactive Auto` Modul wird bei dem initialen Besuch der Website der `Interactive  Server` Modus gewählt und im Hintergrund wird der WebAssembly-Build heruntergeladen, damit bei weiteren Besuchen der Seite der `Interactive WebAssembly` Modus gewählt werden kann.
 - Hybrid: Dieser Modus ist der Einzige, welcher nicht innerhalb einer Blazor Web App läuft, sondern in einem WebView in einer Nativen App. Dabei wird innerhalb des Mutterprozesses, ganz ohne WebServer, der C# und Razor-Code ausgeführt. Das Ganze funktioniert in WPF und WinForms Apps und in nativen mobilen Apps für Android und iOS mithilfe von .NET MAUI.
 Razor-Komponenten (in dieser Arbeit, sowie umgangssprachlich, auch oft nur Komponenten genannt) sind der Grundbaustein für Blazor Web Apps. Sie bestehen aus HTML, welches mit der Verwendung von inline C# beeinflusst werden kann. Das Blazor stellt sicher, dass das gerenderte Markup aktualisiert wird, wenn sich der Status der Komponente ändert. Dieser Code kann entweder vollständig in einer .razor Datei liegen, oder in einer seperaten Code-Behind-Datei. Inline C# Code wird mithilfe von `@`- Zeichen markiert. Hier ist ein Beispiel für einen einfachen Counter:
 ```razor
 <h1>Counter</h1>
 <p>Count: @count</p>
 <button @onclick="Increment">Increment</button>
@code
 {
    private int count = 0;
    private void Increment()
    {
        count++;
    }
 }
 ```
 Mit`@count` in Zeile 3 wird der Wert der Variablen count in den `<p>` Tag mit eingebaut. Mit `@onclick="Increment"` in Zeile 5 wird die onclick Property vom `<button>`Tag auf die Increment Methode im C# Code gesetzt. Der `@code` Block in Zeile 7 ist der C# Code, welcher diese Komponente dynamisch macht. Hier ist die Variable count und die Methode Increment definiert, welche dieser Komponente interaktiv macht.
 Razor hat auch eine Reihe an Keywords, wie zum Beispiel (nur Auszugsweise, bzw. die die wir verwendet haben):
 - namespace: Gibt den aktuellen Namespace in der Razor Datei an.
 - inherits: Gibt die Superklasse der generierten C# Klasse an.
 - using: Gibt die im C# Code benutzen/verfügbaren Namespaces an
 - foreach: Für Wiederholungen im Markup
 - if: Für Verzweigungen im Markup
 #### 3.4.2 Kommunikation zwischen Front- und Backend
 Wie Front- und Backend miteinander interagieren hängt hauptsächlich vom Render-Modus ab. Oqtane kann auf verschiedene Arten betrieben werden. Hierbei ist es dem Modulentwickler ziemlich egal, welche Art der Kommunikation (WebSockets, HTTP Long-Polling, REST) verwendet wird. SignalR ist eine Library aus dem ASP.NET Framework, welche es möglich macht, Server zu Client Kommunikation zu betreiben. Oqtane verwendet SignalR im `Interactive Server (SignalR)` Render-Modus.
 ### 3.5 Dependency Injection
 Dependency Injection ist ein Entwurfsmuster, bei dem die Abhängigkeiten eines Objekts nicht von diesem selbst erzeugt, sondern von außen „injiziert“ werden.
 Wie der Software-Architekt Martin Fowler, der den Begriff im Jahr 2004 maßgeblich prägte, beschreibt, geht es im Kern darum, die Erzeugung von Objekten von deren Nutzung zu trennen [^9]. Anstatt dass eine Klasse ihre Hilfsobjekte mittels des new-Operators selbst instanziiert, werden ihr diese meist über den Konstruktor zur Verfügung gestellt.
 In den folgenden beiden Kapiteln wird das Dependency Inversion Principle und das Microsoft Dependency Injection Framework genauer vorgestellt.
 #### 3.5.1 Dependency Inversion Principle [^1]
 ### Dependency Inversion Principle [^1]
 Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den fünf `SOLID` Prinzipien in der Softwareentwicklung.
 Das DIP unterscheidet zwischen high-level und low-level Modulen.
 - Die High-Level-Module beschreiben die Applikations- / Businesslogik, ohne direkt mit den Low-Level-Modulen zu interagieren, sondern lediglich auf Abstraktionen. [^3]
 - Die Abstraktionen sollen nicht von Implementierungsdetails abhängig sein, sondern die Low-Level-Implementierung sollen gemäß der Abstraktionsschicht implementiert werden. [^3]
@@ -186,37 +104,33 @@ Ausgangslage ist eine Softwarearchitektur im Direct-Dependency-Graph-Modell.
 ```mermaid
 architecture-beta
-    service a(mdi:package-variant-closed)[Klasse A]
+    service a(mdi:package-variant-closed)[Klasse A] 
    service b(mdi:package-variant-closed)[Klasse B]
    a:R --> L:b
 ```
 Bei diesem Beispiel ist die Klasse A ein high-level Modul, welches direkt auf die Klasse B referenziert, was das DI-Prinzip verbietet.
 Das Problem dabei: Die einzelnen Klassen sind eng gekoppelt, was das Austauschen von B mit einer anderen Klasse unmöglich macht. Genau dieses Problem wird vom DIP gelöst.
 ```mermaid
 architecture-beta
-    service a(mdi:package-variant-closed)[Klasse A]
+    service a(mdi:package-variant-closed)[Klasse A] 
    service b(mdi:package-variant-closed)[Klasse B]
    service ib(mdi:car-clutch)[Interface B]
    a:B --> T:ib
    ib:R <-- L:b
 ```
 Das High-Level-Modul ruft lediglich eine Abstraktion eines Low-Level-Moduls auf, welche von einem, oder mehreren Low-Level-Modulen implementiert wurde. Für das High-Level-Modul ist es hier egal, welches Low-Level-Modul die Implementierung bereitstellt. Dadurch erhält man einen viel modulareren Aufbau in der Software. Die einzelnen Module sind auch leichter austauschbar und testbar. Genau diese Modularität macht Dependency Injection möglich.
-#### 3.5.2 Microsoft Dependency Injection Framework
+### Microsoft Dependency Injection Framework
-
+Dependency Injektion ist in .NET genau so wie Konfiguration, Protokollierung und das Optionsmuster ins Framework integriert. [^4]
 Dependency Injection ist in .NET genau so wie Konfiguration, Protokollierung und das Optionsmuster ins Framework integriert. [^4]
 Alle Dependencies werden in einem `Service-Container` zur Verwaltung registriert. .NET hat einen eingebauten `Service-Container` (eine Implementierung des `IServiceProvider`). [^4]
-Das Dependency Injection Framework verwaltet alle Instanzen. Nach Bedarf werden Instanzen erstellt, oder wieder entsorgt (sofern das Service nicht mehr gebraucht wird). Beim Instanziieren einer Klasse werden alle im Konstruktor erwarteten Dependencies bereitgestellt, bzw. selbst instanziiert und danach bereitgestellt. [^4]
+Das Dependency Injection Framework verwaltet alle Instanzen. Nach Bedarf werden Instanzen erstellt, oder wieder entsorgt (sofern das Service nicht mehr gebraucht wird). Beim Instanziieren einer Klasse werden alle im Konstruktor erwarteten Dependencies bereitgestellt, bzw. selbst instanziiert und dannach bereitgestellt. [^4]
 Hier ein Beispiel aus der Dokumentation von Microsoft: [^4]
 ```c#
 HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);
@@ -252,10 +166,9 @@ public sealed class Worker(IMessageWriter messageWriter) : BackgroundService
    }
 }
 ```
 Das ist ein simples Beispiel, welches Teile des DI Frameworks zeigt. Wir haben einen Service (Klasse Worker), ein Dependency (Klasse MessageWriter) und eine Abstraktionsebene, von dem Dependency (Interface IMessageWriter).
-Bei Programmstart wird zuerst manuell der `Service-Container` erstellt, danach alle Module registriert (entweder als HostedService, oder als Modul mit einer spezifischen Lifetime (Scoped, Transient, Singleton)).
+Bei Programmstart wird zuerst manuell der `Service-Container` erstellt, dannach alle Module registriert (entweder als HostedService, oder als Modul mit einer spezifischen Lifetime (Scoped, Transient, Singleton)). 
 Mit dem Aufruf von `builder.Build()` wird intern ein Dependency Graph erstellt und mit `host.Run()` wird versucht die Klasse Worker zu instanziieren und zu starten. Nachdem Worker ein Dependency auf IMessageWriter hat, wird über den zuvor erstellten Dependency-Graph die Implementierung von IMessageWriter gesucht. Jetzt wird MessageWriter instanziiert und dem Konstruktor von Worker übergeben, damit seine Dependencies befriedigt werden.
@@ -263,7 +176,7 @@ So sieht der Abhängigkeitsgraph bei diesem Beispiel aus.
 ```mermaid
 architecture-beta
-    service a(mdi:package-variant-closed)[Worker]
+    service a(mdi:package-variant-closed)[Worker] 
    service b(mdi:package-variant-closed)[MessageWriter]
    service ib(mdi:car-clutch)[IMessageWriter]
@@ -271,7 +184,17 @@ architecture-beta
    ib:R <-- L:b
 ```
-### 3.6 Continuous Integration
+[^1]: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion
 [^2]: https://blog.logrocket.com/dependency-inversion-principle/
 [^3]: https://www.oodesign.com/dependency-inversion-principle
 [^4]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview
 # Continuous Integration
 ## Automatisierter Build und Release Prozess mithilfe von Gitea Actions.
 Gitea, das Versionskontrollsystem dieser Diplomarbeit, hat einen Continuous-Integration-System eingebaut. Im Kern ist es baugleich zu den GitHub-Pipelines. Man kann im `.gitea/workflow` Ordner `.yml` Dateien ablegen, welche dann das Verhalten der Workflows definieren.
@@ -291,263 +214,21 @@ Anwendungen von Gitea Actions bei dieser Diplomarbeit:
 - PM Repository:
  > Zum automatischen Überprüfen der Dokumente, unter anderem, mithilfe von KI, wie zum Beispiel Gemini.
-### 3.7 Debian Paket
+# Projektmanagement
-
+## Scrum
-TODO
+## YouTrack
-
+## Gitea (mit Issues)
-## 4 Projektmanagement & Tools
+## Git
-
+## Kommunikation
-### 4.1 Scrum
+
-
+# Learnings
-### 4.2 YouTrack
+## Probleme mit Oqtane
-
+## Arbeitszeiteinschätzung (Zeitverzug)
-### 4.3 Git
+## Teamleitung (Motivation / Downsizing)
-
+## Produktion != Staging
-Git fungierte im Rahmen dieser Diplomarbeit als zentrales Werkzeug zur Versionskontrolle und Koordination sämtlicher Entwicklungsschritte. Die wichtigste Komponente stellt dabei der Commit dar, welcher als eindeutiger Snapshot des Projektzustands dient und über eine spezifische Commit-SHA (Secure Hash Algorithm) referenziert werden kann. Um eine lückenlose Nachvollziehbarkeit zu gewährleisten, wurde für jeden abgeschlossenen Arbeitsschritt ein eigener Commit erstellt.
+## Sprints und Meetings (in Zukunft ja asynchron)
-
+
-Im Gegensatz zu zentralisierten Systemen wie SVN, welches wir im Unterricht beigebracht bekommen haben, speichert Git die vollständige Historie eines Projekts lokal auf dem Rechner jedes Beteiligten. Dies ermöglicht nicht nur ein Offline-Arbeiten, sondern bietet auch eine hohe Ausfallsicherheit.
+# Modules
-
+## Mass Mailer
-Der Workflow in Git basiert auf drei Hauptbereichen:
+## Event Registration
-
+## Schwarzes Brett
 1. Working Directory: Der aktuelle Zustand der Dateien auf der Festplatte.
 2. Staging Area (Index): Eine Zwischenebene, in der Änderungen für den nächsten Snapshot vorgemerkt werden.
 3. Repository (HEAD): Der dauerhafte Speicher der versionierten Stände (Commits).
 Eines der mächtigsten Features von Git ist das Branching. Es erlaubt es, isolierte Entwicklungszweige zu erstellen, um neue Features oder experimentelle Analysen zu implementieren, ohne die Stabilität des Hauptzweigs `main` zu gefährden.
 Sobald eine Änderung erfolgreich getestet wurde, wird sie durch einen Merge wieder in den Hauptzweig integriert. Sollten dabei widersprüchliche Änderungen an denselben Dateizeilen auftreten, unterstützt Git den Nutzer bei der Auflösung dieser sogenannten Merge-Konflikte.
 Für die Sicherung und Zusammenarbeit wurde im Rahmen dieser Arbeit Remote-Repositories auf einer Gitea Instanz verwendet. Durch die Befehle push und pull wird der lokale Stand mit dem Server synchronisiert. Dies gewährleistet eine konsistente Datenbasis und dient gleichzeitig als kontinuierliches Backup des Projektfortschritts.
 ### 4.4 Gitea
 Als schlanke und selbst gehostete Open-Source-Alternative zu Plattformen wie GitHub oder GitLab wurde für die Verwaltung der Repositories Gitea eingesetzt. Hauptgrund für die Benutzung von Gitea war meine bereits aufgesetzte Instanz, welche schon mehrere Jahre in Verwendung war und mit der es im Team auch schon Erfahrungen gab. Gitea bietet neben der reinen Git-Verwaltung essenzielle Werkzeuge für den Software-Lebenszyklus, wie ein integriertes Issue-Tracking, Code-Reviews über Pull-Requests sowie eine Benutzerverwaltung, und unterstützt somit die strukturierte Umsetzung der Diplomarbeit im Team.[^12]
 #### 4.4.1 Repositories
 Ein Repository bildet den zentralen Speicherort für einen Projektteil. In Gitea wurden separate Repositories für die einzelnen Module und Themes, das Oqtane Framework, Skripte, die Dokumentation angelegt. Ein zusätzliches Repository bindet alle übrigen Quellcode-Repositories als Submodule ein, das macht die Einrichtung einer neuen Entwicklungsumgebung sehr kompfortabel. Dies ermöglichte eine saubere Trennung der verschiedenen Projektkomponenten. [^12]
 #### 4.4.2 Issues
 Zur Aufgabenplanung und Fehlerverfolgung wurde das integrierte Issue-System genutzt. Jede anstehende Aufgabe oder entdeckte Schwachstelle wurde als „Issue“ erfasst, einem Verantwortlichen zugewiesen und mit Labels (z. B. „Bug“, „Feature“ oder „Dokumentation“) versehen. Dies half dabei, den Überblick über den Projektfortschritt zu behalten und die Anforderungen aus dem Lastenheft strukturiert abzuarbeiten. [^12][^13]
 #### 4.4.3 Pull Requests
 Um die Qualität des Codes zu sichern, wurden Änderungen nicht direkt in den Hauptzweig eingespielt, sondern über Pull Requests eingereicht. Ein Teammitglied konnte so die Änderungen eines anderen sichten, kommentieren und bei Bedarf Korrekturen anfordern. Erst nach einer erfolgreichen Überprüfung wurde der Code in den main-Branch gemergt. [^12][^14]
 #### 4.4.4 Actions
 Gitea Actions wurden eingesetzt, um CI/CD-Pipelines (Continuous Integration / Continuous Deployment) zu realisieren. Bei jedem Push oder Pull Request wurden automatisierte Skripte ausgeführt, die das Projekt bauten. Dies reduzierte manuelle Fehlerquellen erheblich. Außerdem konnten wir mithilfe von CI/CD den Release Prozess einmalig festlegen und automatisieren, ohne bei jedem Update manuell den selben Prozess wiederholt durchgehen zu müssen. Das APT-Package Projekt enthält die CI/CD Konfiguration für das bauen von Oqtane, der Module und Themes, sowie das verpacken in ein APT Paket und dem veröffentlichen aller Pakete als eingenes Gitea Release. [^12][^15]
 #### 4.4.5 Releases
 Über die Release-Funktion wurden wichtige Meilensteine der Diplomarbeit festgeschrieben. Hierbei wird ein spezifischer Git-Tag mit einer Versionsnummer versehen und die dazugehörigen Binärdateien, Pakete und Dokumente archiviert. So lässt sich jederzeit auf einen stabilen, abgabebereiten Stand des Projekts zugreifen. [^12]
 #### 4.4.6 Package Repositories
 Gitea fungierte zusätzlich als Register für Pakete und Container-Images. Selbst erstellte Artefakte, wie das Debian Paket für die Bereitstellung der Anwendung, wurden direkt in der Gitea-Instanz versioniert gespeichert. Dadurch waren alle notwendigen Komponenten für das Deployment an einem zentralen Ort verfügbar und abrufbar. Gitea selbst unterstützt verschiedenste Pakettypen. Darunter fallen unteranderem NuGet- und Debianpakete. Für beide haben wir in dieser Arbeit verwendung gefunden. [^12][^16]
 ### 4.5 Kommunikation
 ## 5 Module
 ### 5.1 Admin Modules
 Eine C#-Solution, welche einige Module, welche für den Admineinsatz geschrieben worden sind beinhaltet. Dieses Modul besteht aus 3 Teilmodulen. Einem Modul für den Versand von Rundmails, eines für die Einstellung von der Token Lebenszeit bei Tokens, welche per E-Mail verschickt werden und eines, welches das Reporting-System übernimmt.
 #### 5.1.1 Mass Mailing
 Das Mass Mailer Modul ist eine administrative Erweiterung für den Alumnihub, die es dem Vorstand ermöglicht, personalisierte Rundschreiben an alle registrierten Mitglieder zu versenden. Da die Pflege der Mitgliederdaten direkt im CMS erfolgt, bietet dieses Modul eine nahtlose Integration ohne den Export von CSV-Listen in externe Newsletter-Tools.
 Integration von Brevo
 Für den tatsächlichen Versand der E-Mails nutzen wir den Cloud-Dienst Brevo. Dieser bietet eine zuverlässige Zustellung (hohe Reputation der Mailserver), stellt uns jedoch in der kostenlosen Variante vor eine Herausforderung: nur 300 E-Mails pro Tag.
 `Batch-Processing`: Mails werden nicht sofort ("Fire and Forget") versendet, sondern in eine Versandwarteschlange geschrieben. Nachdem schon die Notifications Infrastruktur, welche sich auch um den Mail versand kümmert, ins Framework eingebaut worden ist, wird diese gleich zum `schedulen` unserer E-Mails genutzt. Immer 100 Mails alle 24 Stunden bis alle Ziele die Mails erhalten haben. Das Limit von 100 / Tag ist konservativ sehr niedrig angesetzt, damit funktionen wie Passwort Reset Mails nicht (leicht) dadurch beeinflusst werden können.
 #### 5.1.2 Token Lifetime
 Das Token Lifetime Modul wurde geschrieben, um die Token-Lebenszeit konfigurierbar zu machen. Notwendig war das, um die Passwort Reset Links im initialen Mail versand länger gultig sein zu lassen. Durch das `Batch Processing` war es möglich, dass eine Mail erst Tage nach erstellen des Links hinaus geschickt wird und bei einer Standard Ablaufdauer von 2 Tagen sind mache Links schon ungültig, bis sie den Mail Server erreichen. Ziel war es, die Änderung der Lebenszeit für Administratoren im User Interface im Admin Bereich möglich zu machen.
 Technisch bedeutet das, dass die standardmäßig vorkonfigurierten `DataProtectionTokenProviderOptions` explizit konfiguriert werden müssen. [^10] Der ASP.NET Core `UserManager`, welcher das generieren der Tokens übernimmt, verwendet einen `DataProtectorTokenProvider` und dieser wiederum kann mithilfe der `DataProtectionTokenProviderOptions` konfiguriert werden.
 Es gibt 2 Möglichkeiten, wie man dieses Problem Lösen kann:
 - `der Workaround`: Ein eigenes Modul, welches in seiner `Server/Startup.cs` die benötigten Werte korrekt setzt. Das hat den Vorteil, dass wir keine Änderungen im CMS selbst haben, sondern nur unsere eigene Erweiterung dafür schreiben. Andererseits könnte durch die undeterministische Ladereihenfolge eine `race-condition` auftreten. [^11] Darüberhinaus ist der gleichzeitigen Zugriff auf appsettings.json und dem IServiceProvider in dem die Konfiguration gesetzt muss. => Nachdem in der Konfigurationsphase auch noch keinen Datenbankzugriff haben, können die Werte nicht aus der DB geladen werden, sondern müssen auf eine Text Datei zurückgreifen.
 - `die saubere Lösung`: Eine Änderung im Kern von Oqtane. Also wird in unserem Fork von Oqtane die Konfigurationslogik für die Tokenlifetime implementiert. In diesem Fall könnte die Konfigurationslogik direkt in `OqtaneServiceCollectionExtensions.cs` hinzugefügt werden, da hier auch alle anderen Oqtane Spezifischen Konfigurationen gesetzt werden. Das hat den Vorteil, dass der Code aufgeräumter und sauberer ist und die `race-condition` verhindert werden kann. [^11] Der initiale Grund dagegen ist, dass wir ein weiteres Git Repository zum warten haben (den Fork vom Oqtane.Framework), welches jetzt nicht mehr mit Upstream Commit-gleich ist.
 `Der Workaround` ist die Möglichkeit für die wir uns entschieden haben, allerdings ist das nicht die schönste Lösung. Eine eventuell nachfolgende Diplomarbeit kann an dieser Stelle ansetzen und `die saubere Lösung` implementieren.
 #### 5.1.3 Reporting System
 Eine weitere Anforderung der Diplomarbeit war es Einträge in Modulen wie der `Hall of Fame`, dem `Schwarzen Brett` und dem Premium Bereich (`Engineer Applications`) melden zu können. Am Anfang war es wichtig, dass jeder schnell vorrankommt, allerdings haben wir die Kommunikation Teamintern ein wenig verschlafen und dadurch ein paar Funktionen doppelt geschrieben. Dadurch kam es zu inkonsistenzen in der Verwendung der unterschiedlichen Reporting Systeme. Deswegen haben wir uns am Ende für eine globales Reporting System entschieden.
 Angestrebt wurde folgender Ablauf für das Melden eines Eintrags:
 ```mermaid
 sequenceDiagram
    participant Module
    actor User
    participant ReportingComponent
    participant ReportingHandler
    User->>+Module: View: Entity
    User->>+ReportingComponent: Report current Entity
    rect rgba(0, 0, 0, 0)
    ReportingComponent->>+User: Ask for reason
    User->>-ReportingComponent: Enters Reason
    end
    ReportingComponent->>+ReportingHandler: New Report (includes entity and reason)
    ReportingComponent->>-User: Done
 ```
 Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der ReportingHandler vom Reporting System über Dependency Injection bereitgestellt, nicht vom Modul selbst. Dadurch erreichen wir eine bessere Trennung der Zuständigkeiten und halten das S in SOLID ein: `Single responsibility`. Die Module sind jetzt nicht mehr für das Reporting selber verantwortlich, sondern müssen nur das Reportings System einbinden.
 Damit DI funktioniert muss für den DI Consumer (`also das Modul, welches das Reporting System einbinden möchte`) das Interface zur Kompilierzeit zur Verfügung stehen. Um das zu erreichen habe ich eine neue Klassenbibliothek erstellt: Sie heißt Interfaces wird per Gitea Actions automatisch in ein Nuget Paket gebaut und in der `Gitea Actions Nuget Registry` veröffentlicht. Dieses Nuget Paket wird dann in jedem notwendigen Modul als dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das IReporting Component zugreifen.
 Die Implementierung des IReportingComponents stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit Dynamic Component sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem Dynamic Component von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse.
 ```razor
@inject IReportUI ReportingComponent
 <DynamicComponent Type="@ReportingComponent.ReportType" Parameters="@ReportingComponent.ConstructParameterList(_item, RenderModeBoundary)"/>
@code {
  private IReportable _item;
 }
 ```
 Die Bereitstellund des Moduls geschieht im `AdminModules` Modul.
 ### 5.2 Event Registration
 Dieses Modul ermöglicht es Administratoren und Absolventen, Veranstaltungen zu erstellen, auf der Seite zu veröffentlichen und zu verwalten, während Mitglieder ihre Teilnahme direkt über das Portal bestätigen oder absagen können. Dieses Modul dient der organisatorischen Unterstützung von Absolvententreffen und anderen Vereinsaktivitäten. Dieses Modul wurde gemeinsam mit Adam Gaiswinkler geschrieben, wobei er sich um die Darstellung der Events im Frontend gekümmert hat, während ich mich der Infrastruktur im Hintergrund angenommen habe.
 #### 5.2.1 Backend und Datenhaltung
 Die serverseitige Implementierung basiert auf dem Repository-Pattern des Oqtane-Frameworks. Hierbei kommen zwei zentrale Repositories zum Einsatz:
 Das `EventRepository` verwaltet die Metadaten der Veranstaltungen wie Name, Beschreibung, Datum und Ort.
 Das `ResponseRepository` speichert die Rückmeldungen der Benutzer. Ein Eintrag verknüpft dabei die UserId mit der EventId und dem Status der Rückmeldung.
 Die Kommunikation zwischen dem Client und dem Server erfolgt über einen REST-API-Controller `EventRegistrationController`, der sicherstellt, dass nur autorisierte Benutzer Änderungen vornehmen oder detaillierte Statistiken einsehen können.
 #### 5.2.2 Statistik und Visualisierung
 Ein wesentlicher Teil der administrativen Ansicht ist die Visualisierung der Anmeldezahlen. Hierfür wurde eine Integration von Chart.js realisiert, um den aktuellen Stand der Rückmeldungen grafisch aufzubereiten.
 Um die Brücke zwischen dem C#-basierten Blazor-Frontend und der JavaScript-Bibliothek Chart.js zu schlagen, wurde ein dedizierter Interop-Service implementiert. Der Ablauf der grafischen Darstellung gestaltet sich wie folgt:
 1. Datenaufbereitung: In der Edit-Komponente werden alle Rückmeldungen zu einem Event geladen und nach ihrem Typ, oder beliebigen anderen Merkmalen aggregiert.
 2. JS-Interop: Über die `CreateChart`-Methode der Interop-Klasse wird die JavaScript-Funktion `createChart` in der `Module.js` aufgerufen. Dabei werden die aggregierten Daten, Beschriftungen und Konfigurationsoptionen übergeben.
 3. Canvas-Rendering: Die JavaScript-Logik erzeugt dynamisch ein HTML5-canvas-Element innerhalb eines Container-Divs und initialisiert daraufhin die Chart.js-Instanz, welche ein übersichtliches Pie-Chart mit den Registrierungsstatistiken rendert.
 Durch diese Trennung bleibt die Geschäftslogik im C#-Code, während für die performante und ansprechende Darstellung auf etablierte Web-Technologien zurückgegriffen wird.
 ### 5.3 Schwarzes Brett
 Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolventenverein. Mitglieder können hier Gesuche, Angebote oder allgemeine Informationen veröffentlichen. Es stellt eine zentrale Informationsdrehscheibe dar, die den informellen Austausch innerhalb des Vereins fördern soll.
 #### 5.3.1 Struktur und Anzeige
 Die Anzeige der Einträge erfolgt in einer responsiven Grid-Ansicht (Index-Komponente), wobei jeder Eintrag als Karte (Card) dargestellt wird. Dieses Design sorgt für eine übersichtliche Präsentation auch bei einer größeren Anzahl von Mitteilungen.
 - Bilderunterstützung: Das Modul nutzt die Oqtane-interne Dateiverwaltung. Wenn ein Bild für einen Eintrag hochgeladen wurde, wird dieses über einen Image-Proxy skaliert und als Vorschaubild angezeigt. Fehlt ein Bild, wird ein konsistenter Platzhalter verwendet, um das visuelle Gleichgewicht der Grid-Ansicht zu wahren.
 - Detailansicht: Die Details-Komponente bietet eine fokussierte Ansicht des Eintrags mit vollständiger HTML-Beschreibung, die über einen Rich-Text-Editor gepflegt werden kann. Ergänzt wird dies durch Metadaten wie Erstellungsdatum und Autor.
 #### 5.3.2 Automatisierter E-Mail-Digest
 Um die Mitglieder regelmäßig über neue Inhalte zu informieren, wurde ein automatisierter `Cronjob` implementiert. Dieser Job läuft im Hintergrund des Oqtane-Frameworks und führt folgende Schritte aus:
 - Filterung: Der Job identifiziert alle Einträge, die seit dem letzten Versand erstellt wurden.
 - Zielgruppenselektion: Es werden alle Benutzer identifiziert, die der Rolle "Absolventen" angehören.
 - Zusammenstellung: Für jeden dieser Benutzer wird eine personalsierte Email-Notification generiert, welche eine Zusammenfassung der neuen Einträge enthält.
 - Versand: Die generierten Notifications werden in die Warteschlange der Notification-Infrastruktur eingereiht und sukzessive versendet.
  Integration des Reporting-Systems
 #### 5.3.3 Reporting System
 Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualität ist die Anbindung an das globale Reporting-System (siehe 5.4). In der Detailansicht wird über Dependency Injection die IReportUI-Komponente eingebunden. Mithilfe der DynamicComponent von Blazor wird die Melde-Funktion nahtlos in die Oberfläche des Moduls integriert. Dadurch können unangemessene Inhalte direkt von Benutzern gemeldet werden.
 #### 5.3.4 Technischer Hintergrund
 Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch. erbarkeit des Moduls gewährleistet.
 ## 6 Learnings
 ### 6.1 Produktion != Staging
 Ein Learning, welches doch relativ schnell aufkam ist im Bereich der IT eigentlich kein unbekanntes. Wir hatten dieses Learning relativ bald, im Frühling 2025, als die ersten Probleme mit dem Deployment von Oqtane aufkamen. Oqtane war zwar in unserer Entwicklungsumgebung sehr einfach zum einrichten gewesen, das Deployment in der Cloud vom Hetzner war jedoch geplagt von Problemen. Im Zeitraum von Mai bis Okober hatten wir keine laufende Produktivumgebung. Dadurch sind wir mit dieser Diplomarbeit auch in [Zeitverzug](#Arbeitszeiteinschätzung-und-verzug) gekommen. Hätte ich mich vor dem Start der Diplomarbeit mit dem Deployment von Oqtane auseinander gesetzt, dann wäre das in [Probleme mit Oqtane](#Probleme mit Oqtane) beschriebene Problem früher aufgekommen und der Zeitverzug wäre nicht so groß, oder noch ganz vermeidbar gewesen.
 ### 6.2 Teamleitung (Motivation / Downsizing)
 Nachdem ich mich von Anfang an volkommen in das Deploymentproblem von Oqtane gestürzt habe, habe ich meine Rolle als Teamleitung etwas schleifen lassen. Dadurch fehlte bei einigen Teammitgliedern initial die Identifikation mit dem Projekt und in weitererfolge auch die Motivation an diesem Projekt mitzuarbeiten. Nachdem im Verlauf des Frühlings und über den Sommer von der hälfte des Teams trotz Besprechungen und Mahnungen keine Beiträge zu dem Projekt kamen, haben Hr. Prof. Gürth und ich uns dazu entschieden uns von 2 Personen vor unterschreiben des Projektantrages zu trennen. Grund dazu war die Angst, die mangelnde Motivation zieht das restliche Team mit hinunter. Wir wollten uns trotz des Downsizings nicht an Funktionalitäten sparen und haben uns für das nächste halbe bis dreiviertel Jahr einen ziemlich strikten Zeitplan vorgenommen.
 ### 6.3 Arbeitszeiteinschätzung (Zeitverzug)
 Ein wesentliches Learning aus dem Projektverlauf war die Diskrepanz zwischen der initialen Planung und dem tatsächlichen Aufwand. Ursprünglich wurde der Zeitaufwand für das Aufsetzen der Infrastruktur und die Einarbeitung in das Oqtane-Framework auf etwa drei Wochen geschätzt. In der Realität nahm dieser Prozess jedoch mehrere Monate in Anspruch.
 Es gibt mehrere Gründe dafür:
 - `Fehlende oder nur schlechte Dokumentation von Oqtane`: Einige Probleme im Deployment wurden in langer und mühseliger Arbeit auseinander gebrochen und in weitere immer kleinere Probleme unterteilt. Dadurch, dass wir alle keine Erfahrung mit der Entwicklung und dem Deployment von ASP.NET Code Anwendungen hatten und die Dokumentation doch schlecht war, blieb uns manchmal nichts anderes übrig als mit WireShark den Netzwerktraffic mit zu schneiden und nebenbei im Git Repository die geloggten Zeilen Code zu finden und so das Framework von innen heraus kennen zu lernen. Dadurch hatte ich dann nach einer Einarbeitungszeit von 4 Monaten ziemlich jede Stelle im Sourcecode von Oqtane gesehen und finde mich um das schneller zurecht.
 - `Team-Konsolidierung`: Durch das notwendige Downsizing des Teams mussten Aufgaben neu verteilt werden, was die individuelle Arbeitslast erhöhte und die Konzentration auf die Kernentwicklung zeitweise verzögert hat.
 - `Abhängigkeit von der Infrastruktur`: Dadurch, dass wir bis in den Oktober / November hinein nicht wussten, ob wir weiter bei Oqtane bleiben können, haben die anderen Teammitglieder nicht mit der sinnvollen Entwicklung ihrer Module starten können. Zitat: "Und was wenn wir am Ende doch noch das CMS umstellen müssen?" => Auch wenn der Auftrag war, mit der Modulentwicklung zu starten war die Motivation meiner Teammitglieder nicht so hoch. Selbst wenn sie nicht direkt von der Infrastruktur mit der Ausführung ihrer Aufgaben abhängig waren, motiviert waren sie wegen der Umstände auch nicht.
 Reaktion auf den Verzug:
 Um das Projektziel dennoch zu erreichen, wurde der Zeitplan im Herbst 2025 massiv gestrafft. Durch die Umstellung auf einen strikteren 14-tägigen Sprint-Rhythmus und die Priorisierung von Core-Funktionalitäten (MVP-Ansatz) konnte der Rückstand teilweise aufgeholt werden.
 > Fazit: Die Erfahrung zeigt, dass gerade bei "Nischen-Frameworks" wie Oqtane ein deutlich höherer Puffer für die Einarbeitungs- und Infrastrukturphase (Faktor 2 bis 3 der ursprünglichen Schätzung) eingeplant werden muss.
 `90% fertig, oder fertig?`: Es gibt einige "Regeln", wie: das `Paretoprinzip`, `Hofstadter’s Law` und die `90-90 Regel`. Letztere wurde im Jahr 1985 von Jon Bentley in einer Kolumne "Programming pearls" veröffentlicht. Ausgeschrieben lautet sie:
 > [Rule of Credibility] The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
 > (Jon Bentley. 1985. Programmimg pearls. Commun. ACM 28, 9 (Sept. 1985), 896–901. https://doi.org/10.1145/4284.315122) [^8]
 > Diese Diplomarbeit liefert weitere Evidenz, dass diese Faustregel stimmt.
 ### 6.4 Sprints und Meetings (in Zukunft ja asynchron)
 Ein zentrales Problem in unserer ursprünglichen Arbeitsweise war die Kopplung von Besprechungsterminen mit festen „Commit-Deadlines“ (dem Ende des aktuellen Sprint zyklusses). Da wir uns einmal pro Woche für sechs Stunden am Stück trafen, entstand ein destruktives Muster:
 - Der "Last-Minute-Commit"-Druck: In den Stunden unmittelbar vor dem Meeting wurden Aufgaben unter Zeitdruck abgeschlossen, um im Meeting Fortschritte präsentieren zu können. Dies führte dazu, dass unfertiger oder unzureichend getesteter Code („Quick and Dirty“) in das Repository gepusht wurde.
 - Fehlende Review-Kultur: Da die Commits erst kurz vor dem Meeting eintrafen, blieb dem restlichen Team keine Zeit für fundierte Code-Reviews. Die Besprechungszeit wurde somit für die Fehlersuche statt für strategische Planung genutzt.
 - Ineffizienz: Lange Präsenz-Meetings blockierten wertvolle Entwicklungszeit, ohne die technische Qualität zu steigern.
 Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen.
 - Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum überblick gesendet werden (eventuell mit @username tagging, um eine Person nochmal genau anzusprechen)
 - Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden.
 - Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#Continuous Integration) Pipeline) am Tag der Besprechung zu vermeiden.
 # Quellen
 [^1]: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion
 [^2]: https://blog.logrocket.com/dependency-inversion-principle/
 [^3]: https://www.oodesign.com/dependency-inversion-principle
 [^4]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview
 [^5]: https://www.oqtane.org/#about
 [^6]: https://docs.oqtane.org/dev/extensions/index.html
 [^7]: https://en.wikipedia.org/wiki/Blazor
 [^8]: https://dl.acm.org/doi/10.1145/4284.315122
 [^9]: https://martinfowler.com/articles/injection.html
 [^10]: https://andrewlock.net/implementing-custom-token-providers-for-passwordless-authentication-in-asp-net-core-identity/#changing-the-default-token-lifetime
 [^11]: https://www.cs.umd.edu/projects/syschat/raceConditions.pdf
 [^12]: https://docs.gitea.com/
 [^13]: https://docs.gitea.com/installation/comparison#issue-tracker
 [^14]: https://docs.gitea.com/usage/pull-request
 [^15]: https://docs.gitea.com/usage/actions/overview
 [^16]: https://docs.gitea.com/usage/packages/overview
Author	SHA1	Message	Date
Konstantin Hintermayer	0b774f00b7	Dassler... All checks were successful Word Count / count-words (pull_request) Successful in 31s Details	2026-03-19 07:23:43 +00:00
Konstantin Hintermayer	d6b360a0f8	New: Danksagung All checks were successful Word Count / count-words (pull_request) Successful in 32s Details Gemini Writing Review / gemini-review (pull_request) Successful in 1m9s Details	2026-03-13 22:25:12 +00:00
Adam Gaiswinkler	df9d4e1687	Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md aktualisiert Some checks failed Word Count / count-words (push) Failing after 33s Details	2026-03-12 14:09:34 +00:00
Adam Gaiswinkler	654eeb4590	Diplomarbeitsbuch-individueller-teil-Adam-Gaiswinkler.md aktualisiert Some checks failed Word Count / count-words (push) Failing after 34s Details	2026-03-09 14:08:03 +00:00
gerti_brindlmayer	b0d67e4d6d	Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md aktualisiert Some checks failed Word Count / count-words (push) Failing after 32s Details	2026-03-08 15:42:16 +00:00
Konstantin Hintermayer	64b148fe6a	Simplify DI Graphics Some checks failed Word Count / count-words (push) Failing after 33s Details	2026-03-07 14:18:27 +00:00