mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7ff48ed3d7
meldestelle/docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
StefanMoCoAt 85282ea7b4
Some checks failed
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Details
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
Details
Update documentation for Navigation V3 and tenant concept: Mark Navigation V2 as deprecated, link replacement documentation, and expand tenant concept details with frontend and backend integration guidelines.
2026-04-02 23:17:07 +02:00

5.9 KiB
Raw Blame History

type status owner last_update sources replaces
Frontend ACTIVE 🎨 Frontend Expert & 🧹 Curator 2026-04-02
docs/06_Frontend/Navigation_Routing_Diagramm.md
docs/02_Guides/Event-First-Workflow.md
docs/99_Journal/2026-04-02_Meldestelle_Besprechung_Session-Log.md
docs/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md

Navigation V3 — Screen‑Baum & Back‑Stack‑Regeln (jetzt gültig)

Dieses Dokument beschreibt die jetzt gültige, startfähige Fassung der Desktop‑App Navigation (Compose Multiplatform, MVP‑Stand ohne erzwungenen Login/Ping).

1. Screen‑Baum (Routen)

  • AppRoot
    • MainShell (ohne Login/Ping)
      • Veranstaltungen (Tab‑Root)
        • Veranstaltung.Detail(eventId)
          • Turnier.Detail(tournamentId)
            • Bewerb.Detail(contestId)
              • Abteilung.Detail(divisionId)
                • Startliste(divisionId)
            • Kassa.Turnier(tournamentId)
          • Kassa.Veranstaltung(eventId)
      • StammdatenImport (Tab‑Root)
      • Reiter (Tab‑Root, Placeholder)
      • Pferde (Tab‑Root, Placeholder)
      • Funktionaere (Tab‑Root, Placeholder)
      • Meisterschaften (Tab‑Root, Placeholder)
      • Cups (Tab‑Root, Placeholder)

Hinweise:

  • Fachliche Struktur folgt dem Event‑First‑Workflow: Veranstaltung → Turnier → Bewerb → Abteilung. Abteilung ist kleinste ausführbare Einheit.
  • Kassen‑Screens existieren getrennt für Turnier und Veranstaltung (Terminologie gemäß Ubiquitous Language).

1a. Haupt‑Shell (Abfragen, Status & Einstieg)

Quellen: frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/DesktopApp.kt, frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/screens/layout/DesktopMainLayout.kt, frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/navigation/DesktopNavigationPort.kt

  • Einstieg/Startzustand

    • Start‑Screen in der Desktop‑Shell ist AppScreen.Onboarding (siehe DesktopNavigationPort, Initialwert und DesktopApp Login‑Gate).
    • Onboarding setzt im MVP ein Dummy‑Token via AuthTokenManager.setToken(...) und leitet in VeranstaltungVerwaltung weiter.
    • Kein erzwungener Login im MVP: DesktopApp erlaubt zentrale Screens ohne Auth, Login‑Route existiert weiterhin optional.

  • TopBar (Breadcrumb)

    • Zeigt kontextabhängige Breadcrumbs (Verwaltung → Veranstalter → Veranstaltung → Turnier ...), inkl. Klick‑Navigation auf Eltern.
    • Kein Logout‑Button im MVP (auf Kundenwunsch entfernt).

  • Content (Screens)

    • Zentrale Verwaltung: VeranstaltungVerwaltungV2 mit Navigations‑Callbacks zu Profilen, Import, Reiter/Pferde/Funktionäre/Vereine.
    • Ping‑Screen existiert (PingScreen/PingViewModel), ist aber kein Einstiegspunkt und wird nicht automatisch abgefragt.

  • Footer/Statusleiste (DesktopFooterBar)

    • Zeigt Online/Offline‑Status (MVP: Stub‑State), Geräte‑Verbindungsstatus inkl. Gerätename „Richter‑Turm“ (Stub) und Chat‑Trigger, wenn Gerät verbunden.
    • Dient rein der Anzeige; keine Navigations‑Einträge im Back‑Stack.

  • Validierungs‑Hinweise

    • Bei inkonsistentem Kontext (z. B. IDs nicht vorhanden) wird ein InvalidContextNotice mit Rücksprung angeboten.

2. Navigations‑Konventionen

  • Route IDs: stabile, serialisierbare IDs (eventId, tournamentId, contestId, divisionId).
  • SingleTop/SingleTask je Tab: erneuter Klick auf einen Tab bringt zum jeweiligen Tab‑Root, Stack bleibt je Tab erhalten.
  • Hierarchischer Drilldown (Parent → Child). „Zurück“ führt jeweils eine Ebene hoch.
  • Deep Links: app://event/{eventId}/tournament/{tId}/contest/{cId}/division/{dId} öffnen direkt die Abteilung; Eltern werden synthetisch für den Back‑Pfad aufgebaut.

3. Back‑Stack‑Regeln (V3)

  1. App‑Start

    • Startet in MainShell → Tab „Veranstaltungen“.

  2. Wechsel Tab → Tab

    • Eigener Stack je Tab; Wechsel speichert und restauriert den jeweiligen Stack (SingleTask je Tab).

  3. Navigieren innerhalb „Veranstaltungen“

    • Veranstaltungen (Liste) → Veranstaltung.Detail → Turnier.Detail → Bewerb.Detail → Abteilung.Detail → Startliste.
    • „Zurück“ springt exakt eine Ebene zurück; beim Verlassen von Startliste zurück zur Abteilung.

  4. Kassa öffnen

    • Von Turnier.Detail zu Kassa.Turnier: Push auf Stack, Back kehrt zu Turnier.Detail zurück.
    • Von Veranstaltung.Detail zu Kassa.Veranstaltung: Push auf Stack, Back kehrt zu Veranstaltung.Detail zurück.

  5. Override‑Dialoge (Regelwerk)

    • Modal/Sheet, kein eigener Stack‑Eintrag. Schließen kehrt zum aktuellen Screen zurück. Override‑Events werden protokolliert.

  6. Auth/Logout (MVP)

    • Kein erzwungener Login; Logout‑Sonderregeln aus V2 sind im MVP nicht aktiv. Bei späterer Aktivierung gelten die bisherigen Regeln (MainShell‑Stack leeren, zurück zum Entry).

4. Zustandsmanagement

  • Screens sind UDF/MVVM‑kompatibel (Details separat dokumentiert).
  • Navigation‑State kann optional returnTo für spätere Login‑Flows halten; im MVP ohne Wirkung.

5. Edge‑Cases & Tests

  • Abteilungswechsel: Beim Wechsel der Abteilung innerhalb eines Bewerbs bleibt der Stack auf Bewerb‑Ebene erhalten; nur das Abteilung‑Detail wird ersetzt.
  • Datenverlust vermeiden: Vor Navigation prüfen, ob ungespeicherte Änderungen vorliegen (z. B. Kassa‑Buchung), ggf. Confirm‑Dialog.
  • Deep‑Link Pfadaufbau: synthetische Eltern korrekt in den Back‑Pfad einhängen.

6. Querverweise

  • Routing‑Diagramm: docs/06_Frontend/Navigation_Routing_Diagramm.md
  • Event‑First‑Workflow: docs/02_Guides/Event-First-Workflow.md
  • Begriffe: docs/03_Domain/01_Glossary/Ubiquitous_Language.md
  • Analyse/Begründung: docs/06_Frontend/Reports/2026-04-02_Navigation_Versionierung_Analyse_V2_vs_V3.md
  • Tenant‑Konzept (eine Veranstaltung = ein Tenant): docs/01_Architecture/Reference/Tenant-Konzept_Eine-Veranstaltung-eine-Datenbank.md