README: Ausblick durch den tatsaechlichen Stand ersetzt
Alle 15 Typen sind gebaut — der Abschnitt beschrieb noch die Planung. Statt dessen: wie ein weiterer Typ dazukommt, und was als Naechstes sinnvoll waere.
This commit is contained in:
@@ -30,7 +30,7 @@ entscheidet die Verwaltung — nicht gebrauchte lassen sich ausblenden.
|
|||||||
- [Technischer Aufbau](#technischer-aufbau)
|
- [Technischer Aufbau](#technischer-aufbau)
|
||||||
- [Entwicklung ohne Docker](#entwicklung-ohne-docker)
|
- [Entwicklung ohne Docker](#entwicklung-ohne-docker)
|
||||||
- [API](#api)
|
- [API](#api)
|
||||||
- [Ausblick Version 2](#ausblick-version-2)
|
- [Einen weiteren Typ ergänzen](#einen-weiteren-typ-ergänzen)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -860,25 +860,39 @@ curl -X POST http://localhost:3000/api/codes \
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Ausblick Version 2
|
## Einen weiteren Typ ergänzen
|
||||||
|
|
||||||
Geplant sind die übrigen 14 Typen: vCard, App-Link, Mehrere Links, Social
|
Alle 15 vorgesehenen Typen sind gebaut. Kommt ein sechzehnter dazu, besteht er
|
||||||
Media, WhatsApp, PDF, Bild, Video, E-Mail, SMS, Standort, Zahlung, WLAN und
|
aus:
|
||||||
Feedback.
|
|
||||||
|
|
||||||
Die Architektur ist darauf ausgelegt — ein neuer Typ besteht aus:
|
|
||||||
|
|
||||||
1. **einem Modul** in `src/lib/qr/types/` (Zod-Schema, Kodierung, Kurzfassung),
|
1. **einem Modul** in `src/lib/qr/types/` (Zod-Schema, Kodierung, Kurzfassung),
|
||||||
2. **einer Formular-Komponente** in `src/components/qr-forms/`,
|
2. **einer Formular-Komponente** in `src/components/qr-forms/`,
|
||||||
3. **je einem Eintrag** in `src/lib/qr/registry.ts` (ersetzt dort den
|
3. **je einem Eintrag** in `src/lib/qr/registry.ts` und in
|
||||||
`defineComingSoonType`-Platzhalter) und in
|
`src/components/qr-forms/index.ts`,
|
||||||
`src/components/qr-forms/index.ts`.
|
4. **einer Landingpage** in `src/components/landing/`, falls er `hasLandingPage`
|
||||||
|
meldet.
|
||||||
|
|
||||||
Am bestehenden Code aus Version 1 ist dafür nichts zu ändern: Vorschau,
|
Am übrigen Code ist dafür nichts zu ändern: Vorschau, Download, Gestaltung,
|
||||||
Download, Gestaltung, Speicherung dynamischer Codes und die Weiterleitung
|
Speicherung, Weiterleitung, Liste und Verwaltung arbeiten für alle Typen
|
||||||
arbeiten für alle Typen gleich.
|
gleich. Die Kennung gehört zusätzlich in `QR_TYPE_IDS` in
|
||||||
|
`src/lib/qr/type-module.ts`.
|
||||||
|
|
||||||
Typen, die statt einer Weiterleitung eine eigene Landingpage brauchen (etwa
|
Für einen angekündigten, aber noch nicht gebauten Typ gibt es
|
||||||
„Mehrere Links“ oder „Feedback“), setzen dafür `redirectTarget` auf eine
|
`defineComingSoonType`: Er erscheint als Kachel mit dem Badge „Bald
|
||||||
interne Adresse — auch dafür ist keine Änderung am Datenmodell nötig, weil
|
verfügbar“ und lässt sich nicht öffnen.
|
||||||
`data` als JSONB gespeichert wird.
|
|
||||||
|
Braucht der Typ eine hochgeladene Datei, meldet er ihre Ids über `uploadIds` —
|
||||||
|
daran hängt, was beim Löschen des Codes mitgeht und was als verwaist
|
||||||
|
weggeräumt wird.
|
||||||
|
|
||||||
|
### Was als Nächstes sinnvoll wäre
|
||||||
|
|
||||||
|
- **Gruppen aus dem Verzeichnis übernehmen.** Die OIDC-Anbindung übernimmt
|
||||||
|
heute bewusst nur die Identität. Eine Zuordnung von Verzeichnisgruppen zu
|
||||||
|
Gruppen dieser Anwendung wäre möglich, braucht aber eine klare Regel dafür,
|
||||||
|
was mit von Hand vergebenen Rollen passiert.
|
||||||
|
- **Statistik über die Zeit.** Der Zähler weiß heute nur, wie oft und wann
|
||||||
|
zuletzt. Ein Verlauf je Tag wäre eine eigene Tabelle — und die Frage, wie
|
||||||
|
lange man ihn aufbewahrt.
|
||||||
|
- **Codes exportieren.** Eine CSV aller Codes einer Gruppe, für die Übergabe
|
||||||
|
an Druckereien.
|
||||||
|
|||||||
Reference in New Issue
Block a user