# DiaryView Port Plan (statt direkter Komplett-Implementierung)

## Entscheidung
Die vollständige Rest-Portierung von `frontend/src/views/DiaryView.vue` in einem einzigen Durchlauf würde voraussichtlich **deutlich mehr als 40 Dateien** betreffen (UI-Module, Dialoge, Mapper/DTOs, Repository/Service/ViewModel-Erweiterungen, Socket-Handling, Strings, Tests, Doku).

Daher wurde gemäß Vorgabe (`Wenn mehr nötig: /docs/plan_diaryview.md statt Änderungen`) **kein weiterer Code geändert**.

## 1) Analyse von `DiaryView.vue`

### Verwendete Components
- `CourtDrawingRender`
- `CourtDrawingDialog`
- `InfoDialog`
- `ConfirmDialog`
- `ImageDialog`
- `BaseDialog`
- `MemberNotesDialog`
- `TagHistoryDialog`
- `MemberActivityStatsDialog`
- `AccidentFormDialog`
- `QuickAddMemberDialog`
- `MemberGalleryDialog`
- `PDFGenerator` (JS-Utility)

### Services / Utilities / Composables
- `apiClient` (viele REST-Aufrufe)
- `socketService` (`connectSocket`, `disconnectSocket`, `on*`, `off*`)
- Vuex `mapGetters`: `isAuthenticated`, `currentClub`, `currentClubName`
- Sortable/Drag&Drop Logik (Order-Updates)

### Store-Abhängigkeiten
- Auth/Session und Club-Kontext kommen aus Store-Gettern:
  - `isAuthenticated`
  - `currentClub`
  - `currentClubName`

### API-Aufrufe (relevant für Rest-Port)
Bereits in Android teilweise umgesetzt, aber für Vollparität fehlen weiterhin größere Blöcke:
- Diary Core: `/diary/{clubId}` (GET/POST/PUT/DELETE)
- Participants: `/participants/*`, `/participants/{dateId}/{memberId}/group`
- Activities: `/activities/{dateId}`, `/activities/add`
- Tags/Notes: `/tags`, `/diary/tag/*`, `/diarymember/*`
- Plan: `/diary-date-activities/*`, `/diary-date-activities/group/*`, `/diary-member-activities/*`
- Groups: `/group/{clubId}/{dateId}`, `/group`, `/group/{groupId}`
- Training context: `/training-groups/{clubId}`, `/training-times/{clubId}`
- Member images/gallery: `/clubmembers/image/*`
- Stats: `/member-activities/*`
- Accident: `/accident`, `/accident/{clubId}/{dateId}`
- Predefined activities + search + create/update: `/predefined-activities*`

### Socket-Events in DiaryView
- Participants: `participant:added`, `participant:removed`, `participant:updated`
- Diary: `diary:note:added`, `diary:note:deleted`, `diary:tag:added`, `diary:tag:removed`, `diary:date:updated`
- Activity member: `activity-member:added`, `activity-member:removed`
- Activity: `activity:changed`
- Member: `member:changed`
- Group: `group:changed`

## 2) Warum >40 Dateien realistisch sind
Für „möglichst 1:1 Web-Funktionalität“ müssen zusätzlich zu bestehendem Stand mindestens folgende Pakete ausgebaut werden:
- Mehrere dedizierte Compose-Dialoge (Drawing, Notes, Tag-Historie, Activity-Stats, Accident, QuickAdd, Gallery, Image/Confirm/Info)
- Umfangreiche VM-State-Modelle pro Dialog/Tab/Flow
- Zusätzliche Repository-Modelle und Mapper für Group-Activities, Member-Activities, Accident, Gallery/Image-Modelle
- Socket-Event-spezifische State-Synchronisation im Diary-Flow
- Zusätzliche Strings/Testfälle für viele Spezialpfade

Damit ist die 40-Dateien-Grenze in einem „alles in einem Durchlauf“-Block nicht sinnvoll einhaltbar, ohne die geforderte 1:1-Funktionalität zu unterlaufen.

## 3) Empfohlene Umsetzungsblöcke (priorisiert)

### Block A: Training-Plan Vollständigkeit
- Group-Activities (`/diary-date-activities/group*`)
- Activity-Member-Zuordnung (`/diary-member-activities/*`)
- Plan-Item Group-Update, Duration/DurationText vollständig
- Drag&Drop-Reorder final

### Block B: Teilnehmer- und Mitglieder-Dialoge
- MemberNotesDialog-Äquivalent (inkl. Tag-Zuordnung auf Member+Date)
- QuickAddMemberDialog inkl. `clubmembers/set`
- Tag-History und Activity-Stats Dialoge

### Block C: Gruppenverwaltung + Vorschlagslogik
- Gruppen CRUD (`/group*`) inklusive Lead
- New-Date Dialog mit TrainingGroup/TrainingTimes-Vorschlag

### Block D: Bilder/Galerie + Export
- MemberGalleryDialog + Bildaufrufe
- ImageDialog
- TrainingDay PDF-Export (oder Android-kompatible Alternative)

### Block E: Accident + Drawing
- AccidentFormDialog (`/accident*`)
- CourtDrawingDialog/Render-Flow mit PredefinedActivity-Sync

### Block F: Socket-Live-Updates
- Nur Diary-relevante Event-Subsets robust in VM integrieren
- Dokumentation in `/docs/socket_contract.md`

## 4) Konkreter nächster Umsetzungsschritt
Wenn du fortsetzen möchtest, starte mit **Block A** (Training-Plan Vollständigkeit), da er den größten funktionalen Mehrwert für den täglichen Diary-Betrieb liefert und auf dem bereits migrierten Stand aufsetzt.
