mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
cfe12e4dd0
meldestelle/docs/01_Architecture/Frontend_Komponenten_Roadmap.md
Stefan Mogeritsch 683ef956fc docs(adr): add ADR-0020 for LAN communication and data isolation architecture 
- Documented decision for Peer-to-Peer (P2P) model with mDNS discovery, WebSocket transport, and shared security keys.
- Addressed data isolation with namespacing by turnierId.
- Updated roadmap to reflect progress in Phase 6: Vernetzung & Inter-App Kommunikation.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-03-31 13:02:08 +02:00

4.1 KiB
Raw Blame History

Frontend-Komponenten Roadmap: Meldestelle-Biest

🏗️ [Lead Architect] | 31. März 2026

Diese Roadmap definiert den Weg von der aktuellen Prototypen-Phase hin zu einer professionellen, konsistenten und performanten Desktop-App. Wir setzen auf einen komponentengetriebenen Ansatz (High-Density UI), um die komplexe Datenverwaltung der Turniermeldestelle effizient abzubilden.

Phase 1: Cleanup & Konsolidierung (Das Fundament) ✅ [ABGESCHLOSSEN]

Bevor wir neue Features bauen, räumen wir die bestehenden Entwürfe auf, um Redundanzen zu vermeiden.

  • Design-System Refactoring:
  • Buttons.kt (DenseButton) in MsButton.kt überführt.
  • Einheitliches Naming: Alle Basis-Komponenten erhalten das Präfix Ms (z.B. MsButton.kt, MsTextField.kt).
  • Redundante Placeholder-Dateien entfernt oder in core/design-system/models/ bündeln.
  • Theme-Check:
  • Sicherstellen, dass alle Farben aus AppColors kommen und nicht hart codiert sind.
  • Typografie-Skalen für High-Density optimieren (LabelSmall für Tabellen).
  • Build-Fixes:
  • Referenzen in ping-feature korrigiert.
  • Referenzen in profile-feature korrigiert.

Phase 2: Daten-Visualisierungs-Komponenten (Das Herzstück) ✅ [ABGESCHLOSSEN]

Turniermanagement bedeutet Arbeit mit Listen. Wir benötigen mächtige, aber kompakte Anzeige-Komponenten.

  • MsDataTable:
  • KMP-kompatible Tabelle mit Sticky Header.
  • Generische Spaltendefinition mit Custom Cell Renderern.
  • Zeilen-Selektion (Einzel-Klick) und gestreiftes Zeilen-Design.
  • MsStatusBadge:
  • Farbliche Kodierung für Nennungsstatus, Lizenzstatus und Prüfungsstatus.
  • Kompaktes Design für die Nutzung innerhalb von Tabellenzellen.
  • MsFilterBar:
  • Suchfeld mit Debounce-Unterstützung (Pattern-basiert).
  • Filter-Chips für schnelle Status-Wechsel.
  • Anzeige der Trefferanzahl (Result Count).

Phase 3: Formular- & Eingabe-System (Die Datenerfassung) ✅ [ABGESCHLOSSEN]

Eingabe von Stammdaten muss schnell und fehlerfrei erfolgen.

  • MsEnumDropdown: Automatisches Mapping von Backend-Enums (ÖTO) auf UI-Auswahl.
  • MsValidationWrapper: Konsistente Anzeige von Fehlern und Warnungen (z.B. ÖTO-Validierungsregeln).
  • MsSearchableSelect: Für die Verknüpfung von Reitern/Pferden (Autocomplete-Suche).

Phase 4: Layout-Patterns & Navigation ✅ [ABGESCHLOSSEN]

Hier bringen wir alles zusammen, bevor das finale Routing implementiert wird.

  • MsMasterDetailLayout: Standard-Layout für alle Stammdaten-Screens (Liste & Editor).
  • MsActionToolbar: Einheitliche Platzierung von Hauptaktionen (Neu, Speichern, Drucken).
  • MsDialogShell: Standardisierter Rahmen für Modale und Bestätigungsdialoge.

Phase 5: Routing & Screen-Komposition ✅ [ABGESCHLOSSEN]

In dieser Phase werden die Komponenten zu echten Features zusammengebaut.

  • Reiter-Verwaltung (MVP): Erster Screen mit MsMasterDetailLayout, MsDataTable und Editor.
  • Pferde-Verwaltung (MVP): Analog zur Reiter-Verwaltung (Fertiggestellt).
  • Layout-Refactoring: Umstellung auf Event-First Workflow (Login-Skip).

Phase 6: Vernetzung & Inter-App Kommunikation 🔵 [IN ARBEIT]

Nachdem die UI-Bausteine stehen, vernetzen wir die Desktop-Apps im LAN.

  • Konzept & ADR: ADR-0020 (LAN-Communication & Isolation) erstellt.
  • Discovery: mDNS Integration für automatische Gerätefindung.
  • Sync: WebSocket-basierte Echtzeit-Synchronisation zwischen Meldestelle und Richter.
  • Chat: Implementierung des veranstaltungsweiten Chat-Fensters.

Erfolgs-Metriken

  • Wiederverwendbarkeit: > 80% der UI besteht aus Ms-Komponenten.
  • Density: Alle relevanten Daten eines Reiters/Pferdes sind ohne Scrollen in der Detailansicht sichtbar.
  • Performance: MsDataTable rendert 500+ Zeilen flüssig auf ARM64 (Zora/Mac/Linux).

🧹 [Curator] | 2026-03-31 Dieses Dokument dient als Single Source of Truth für die Frontend-Entwicklung.