mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2d532eb41c
meldestelle/docs/01_Architecture/Frontend_Komponenten_Roadmap.md
Stefan Mogeritsch 2d532eb41c docs(roadmap): mark Phase 1 as complete and update progress in Frontend_Komponenten_Roadmap.md 
- Marked Phase 1 (`Cleanup & Konsolidierung`) as complete and updated task checklists accordingly.
- Recorded fixes for `ping-feature` and `profile-feature` references in the roadmap.
- Improved clarity for completed refactorings and theme adjustments.

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

3.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) 🔵 [GEPLANT]

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

  • MsDataTable:
  • KMP-kompatible Tabelle mit Sticky Header.
  • Sortier- und Filter-Logik (in-memory & API-driven).
  • Zeilen-Selektion (Einzel/Mehrfach) und Kontextmenüs.
  • MsStatusBadge:
  • Farbliche Kodierung für Nennungsstatus, Lizenzstatus und Prüfungsstatus.
  • Kompaktes Design für die Nutzung innerhalb von Tabellenzellen.
  • MsFilterBar:
  • Suchfeld mit Debounce.
  • Filter-Chips für schnelle Status-Wechsel.

Phase 3: Formular- & Eingabe-System (Die Datenerfassung) ⚪ [ZUKUNFT]

Eingabe von Stammdaten muss schnell und fehlerfrei erfolgen.

  • MsEnumDropdown: Automatisches Mapping von Backend-Enums (ÖTO) auf UI-Auswahl.
  • MsValidationWrapper: Konsistente Anzeige von Fehlern (z.B. "Lizenz für diese Klasse nicht ausreichend").
  • MsSearchableSelect: Für die Verknüpfung von Reitern/Pferden (Autocomplete).

Phase 4: Layout-Patterns & Navigation ⚪ [ZUKUNFT]

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

  • MsMasterDetailLayout: Standard-Layout für alle Stammdaten-Screens.
  • 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.