diff --git a/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md index d1064dd..cb9d097 100644 --- a/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md +++ b/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md @@ -458,6 +458,8 @@ Anwendungen von Gitea Actions bei dieser Diplomarbeit: - PM Repository: > Zum automatischen Überprüfen der Dokumente, unter anderem, mithilfe von KI, wie zum Beispiel Gemini. +# Gitea Actions YAML einfügen und erklären + ### Debian Paket Um die Anwendung und ihre Abhängigkeiten konsistent auf dem Zielserver (Linux/Hetzner) zu installieren, wurde ein eigenes Debian-Paket (`.deb`) erstellt. Das Debian-Paketformat bietet den Vorteil, dass es Metadaten über Versionen, Abhängigkeiten und Installationsskripte (Maintainer Scripts) enthält. @@ -632,9 +634,9 @@ Im oben dargestellten Ablaufdiagram werden das ReportingComponent und der Report Darüber hinaus erfüllt dieses Design das **Open/Closed Principle**: Das Reporting-System ist offen für Erweiterungen (neue Module können einfach andocken), aber geschlossen für Modifikationen (der Kern des Reporting-Systems muss nicht für jedes neue Modul geändert werden). -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. +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. Die Versionierung folgt dabei strikt den Git-Tags im Repository, was eine saubere Release-History ermöglicht. Dieses NuGet-Paket wird dann in jedem notwendigen Modul als Dependency hinzugefügt und damit kann man Modulübergreifend auf die Services und das `IReportingComponent` 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. +Die Implementierung des `IReportingComponents` stellt nur eine Property (`ReportType`, welche den TypeName der Razor Komponente zurückliefert, damit `DynamicComponent` sie laden kann) und eine Methode (`ConstructParameterList`, welche das Parameter Dictionary erstellt. Nur zwecks Typensicherheit eingefügt) bereit. Mit dem `DynamicComponent` von Razor ist es möglich, per C# Code unterschiedliche Komponenten zu rendern und damit auch die per DI injizierte Klasse. ```razor @inject IReportUI ReportUI @@ -708,9 +710,11 @@ erDiagram \ +# TODO: Bild vom Grafen hier einfügen + 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: +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 JS-Interop-Layer ist zwar standardmäßig in Oqtane-Modulen vorgesehen, wurde jedoch in diesem Modul zum ersten Mal angepasst und produktiv eingesetzt. 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. @@ -733,7 +737,7 @@ Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolvente 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. +- Detailansicht: Die Details-Komponente bietet eine fokussierte Ansicht des Eintrags mit vollständiger HTML-Beschreibung. Für die Eingabe und Formatierung der Texte wird auf die von Oqtane standardmäßig bereitgestellten Rich-Text-Editoren zurückgegriffen, was eine konsistente Nutzerführung im gesamten CMS gewährleistet. Ergänzt wird dies durch Metadaten wie Erstellungsdatum und Autor.