Stefan Mogeritsch
ad529f7395
- Introduced `MsMasterDetailLayout` as a standardized layout for master-detail screens, including support for customizable headers and split proportions. - Updated `Frontend_Komponenten_Roadmap.md` to mark this component as complete in Phase 4. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
69 lines
3.2 KiB
Markdown
69 lines
3.2 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) 🔵 [IN ARBEIT]
|
|
|
|
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 🔵 [IN ARBEIT]
|
|
|
|
Hier bringen wir alles zusammen, bevor das finale Routing implementiert wird.
|
|
|
|
* [x] **`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.
|
|
|
|
---
|
|
|
|
## 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.*
|