Stefan Mogeritsch
683ef956fc
- 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>
90 lines
4.1 KiB
Markdown
90 lines
4.1 KiB
Markdown
# 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.
|
|
|
|
* [x] **Design-System Refactoring:**
|
|
* [x] `Buttons.kt` (DenseButton) in `MsButton.kt` überführt.
|
|
* [x] Einheitliches Naming: Alle Basis-Komponenten erhalten das Präfix `Ms` (z.B. `MsButton.kt`, `MsTextField.kt`).
|
|
* [x] Redundante Placeholder-Dateien entfernt oder in `core/design-system/models/` bündeln.
|
|
* [x] **Theme-Check:**
|
|
* [x] Sicherstellen, dass alle Farben aus `AppColors` kommen und nicht hart codiert sind.
|
|
* [x] Typografie-Skalen für High-Density optimieren (LabelSmall für Tabellen).
|
|
* [x] **Build-Fixes:**
|
|
* [x] Referenzen in `ping-feature` korrigiert.
|
|
* [x] 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.
|
|
|
|
* [x] **`MsDataTable`:**
|
|
* [x] KMP-kompatible Tabelle mit Sticky Header.
|
|
* [x] Generische Spaltendefinition mit Custom Cell Renderern.
|
|
* [x] Zeilen-Selektion (Einzel-Klick) und gestreiftes Zeilen-Design.
|
|
* [x] **`MsStatusBadge`:**
|
|
* [x] Farbliche Kodierung für Nennungsstatus, Lizenzstatus und Prüfungsstatus.
|
|
* [x] Kompaktes Design für die Nutzung innerhalb von Tabellenzellen.
|
|
* [x] **`MsFilterBar`:**
|
|
* [x] Suchfeld mit Debounce-Unterstützung (Pattern-basiert).
|
|
* [x] Filter-Chips für schnelle Status-Wechsel.
|
|
* [x] Anzeige der Trefferanzahl (Result Count).
|
|
|
|
## Phase 3: Formular- & Eingabe-System (Die Datenerfassung) ✅ [ABGESCHLOSSEN]
|
|
|
|
Eingabe von Stammdaten muss schnell und fehlerfrei erfolgen.
|
|
|
|
* [x] **`MsEnumDropdown`:** Automatisches Mapping von Backend-Enums (ÖTO) auf UI-Auswahl.
|
|
* [x] **`MsValidationWrapper`:** Konsistente Anzeige von Fehlern und Warnungen (z.B. ÖTO-Validierungsregeln).
|
|
* [x] **`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.
|
|
|
|
* [x] **`MsMasterDetailLayout`:** Standard-Layout für alle Stammdaten-Screens (Liste & Editor).
|
|
* [x] **`MsActionToolbar`:** Einheitliche Platzierung von Hauptaktionen (Neu, Speichern, Drucken).
|
|
* [x] **`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.
|
|
|
|
* [x] **Reiter-Verwaltung (MVP):** Erster Screen mit `MsMasterDetailLayout`, `MsDataTable` und Editor.
|
|
* [x] **Pferde-Verwaltung (MVP):** Analog zur Reiter-Verwaltung (Fertiggestellt).
|
|
* [x] **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.
|
|
|
|
* [x] **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.*
|