mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
94306329c9
meldestelle/docs/01_Architecture/Frontend_Komponenten_Roadmap.md
Stefan Mogeritsch 94306329c9 feat(reiter-feature): introduce Reiter management module with screens, ViewModel, and domain models 
- Added `reiter-feature` module for managing riders, including list and detail views.
- Implemented `MsMasterDetailLayout` for ReiterScreen, integrating `MsDataTable`, `MsFilterBar`, and `MsActionToolbar`.
- Defined domain models (`Reiter`, `LizenzKlasse`, `Sparte`, `ReiterStatus`) with mock data support.
- Updated roadmap to reflect progress in Phase 5: Routing & Screen-Komposition.
- Registered the new module in `settings.gradle.kts`.

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

3.6 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) 🔵 [IN ARBEIT]

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 🔵 [IN ARBEIT]

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.
  • Navigation & Routing: Integration der neuen Screens in die Hauptnavigation.

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.