71 lines
3.1 KiB
Markdown
71 lines
3.1 KiB
Markdown
# Module
|
|
|
|
Klassische Module bleiben in diesem Projekt unter `modules/<modul>/`.
|
|
|
|
Die neue Desktop-Shell ist nur die UI-Schicht. Modul-Businesslogik wird nicht in den Desktop-Core verschoben.
|
|
|
|
## Aktuelle Modulstruktur
|
|
|
|
Ein Desktop-Modul kann zusaetzlich diese Projektdateien besitzen:
|
|
|
|
- `desktop.php` fuer die Desktop-App-Metadaten und Asset-Definitionen
|
|
- `pages/` fuer Standalone-Seiten oder iframe/native Einstiegspunkte
|
|
- `api/` fuer modulinterne HTTP-Endpunkte
|
|
- `assets/` fuer modulnahe CSS- und JS-Dateien
|
|
- `docs/README.md` fuer modulspezifische Hinweise, API und Sonderregeln
|
|
- `module.json` fuer Setup, Desktop-Freigabe, Widget-Funktionen und Cron-Endpunkte
|
|
|
|
Module-Assets werden in diesem Projekt nicht direkt aus `public/assets/apps/...` dupliziert, sondern ueber den generischen Endpoint `/module-assets/index.php` aus dem jeweiligen Modul ausgeliefert.
|
|
|
|
## Trennung zwischen Systemtools und Modulen
|
|
|
|
- `Systemtools` sind globale Verwaltungs- und Setup-Apps und nicht installierbar
|
|
- aktuelle Beispiele: `User Management`, `User Self Management`, `Cron Tool`
|
|
- `Module` sind installierbare Fachanwendungen
|
|
- aktuelle Beispiele: `Mining-Checker`, `Waehrungs-Checker`, `Boersenchecker`, `Pi-hole`
|
|
|
|
Diese Trennung wird ueber App-Metadaten gesteuert:
|
|
|
|
- `app_scope`
|
|
- `core`
|
|
- `system_tool`
|
|
- `module`
|
|
- `installable`
|
|
- `false` fuer Core- und Systemtools
|
|
- `true` fuer installierbare Module
|
|
|
|
## Modul-Metadaten in `module.json`
|
|
|
|
Module sollen ihre Desktop-Faehigkeiten zentral in `module.json` beschreiben.
|
|
|
|
Wichtige Bausteine:
|
|
|
|
- `desktop`
|
|
- `available`
|
|
- `show_on_desktop`
|
|
- `show_in_start_menu`
|
|
- `widgets`
|
|
- beschreibt Widget-Funktionen, die nur fuer installierte Module verfuegbar sind
|
|
- `cron_jobs`
|
|
- beschreibt Cron-Endpunkte fuer die zentrale Cron-Verwaltung
|
|
|
|
Die Desktop-Shell liest diese Angaben automatisch ein. Neue Modul-Crons und Widgets muessen deshalb nicht zusaetzlich in einer separaten globalen Liste nachgetragen werden, solange sie sauber im Manifest beschrieben sind.
|
|
|
|
## Globale Desktop-Standards fuer Module
|
|
|
|
- gemeinsame Desktop-Mechaniken wie Fenster, Tray, globale Persistenz und Debug-Infrastruktur liegen im Desktop-Core
|
|
- Module und andere Apps sollen keine eigene Grund-Debug-Oberflaeche im Stil eines separaten globalen Debuggers bauen
|
|
- fuer Debugging im Desktop gilt das zentrale Admin-Debug-Widget neben der Uhr mit eigenem Debug-Fenster als Standard
|
|
- Debug-Events aus Modulen sollen in den gemeinsamen Desktop-Debug-Bus geschrieben werden, damit sie im globalen Debug-Fenster sichtbar sind
|
|
- wenn das globale Debug-Fenster geschlossen ist, sollen Module kein dauerhaft aktives Live-Debugging erzwingen
|
|
- app-spezifische Debug-Darstellungen sind nur zulaessig, wenn sie fachliche Zusatzinformationen zeigen, die ueber den globalen Stream hinausgehen
|
|
|
|
## Pflegehinweis
|
|
|
|
Diese Datei muss gepflegt bleiben, wenn sich Modulstruktur oder Modulregeln aendern.
|
|
|
|
Wichtige Inhalte aus dieser Datei muessen ebenfalls zentral gepflegt werden in:
|
|
|
|
- [CONTENT.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/docs/CONTENT.md)
|
|
- [WEITERENTWICKLUNG.md](/home/lars/Schreibtisch/Projekte/desktop.kusche.berlin/docs/WEITERENTWICKLUNG.md)
|