Skip to content

# Architektur

## Systemübersicht

Das XMAS-Plugin verbindet drei Komponenten: den QGIS-Desktop-Client, einen lokalen XMAS-App-Server und eine PostgreSQL-Datenbank. Lese- und Schreibpfade sind bewusst getrennt: Lesezugriffe gehen direkt von QGIS über den eingebetteten Postgres-Provider zur Datenbank, während Schreiboperationen über den XMAS-App-HTTP-Backend geleitet werden.

## Datenpfade im Detail

### Lesezugriffe (READ — direktes SQL)

QGIS lädt Features über `XMASPluginVectorDataProvider`, der intern einen Standard-`QgsPostgresProvider` kapselt. Leseanfragen werden direkt an PostgreSQL weitergeleitet — ohne Umweg über den App-Server. Das sorgt für niedrige Latenz beim Rendern großer Datensätze.

### Schreiboperationen (WRITE — HTTP über Webapp)

Insert- und Update-Operationen werden nicht direkt an die Datenbank geschickt. Stattdessen sendet `XMASPluginVectorDataProvider` HTTP-POST-Anfragen an den lokalen XMAS-App-Server (`/insert-features`, `/update-features`). Der Server validiert die Daten, wendet Geschäftslogik an und schreibt dann erst in PostgreSQL.

### Löschoperationen (DELETE — direktes SQL)

Löschvorgänge gehen — wie Lesezugriffe — direkt über den Postgres-Provider an die Datenbank.

### JS ↔ Python Kommunikation (QWebChannel)

Die `QWebEngineView` im Dock-Widget lädt die Web-UI des XMAS-App-Servers. Über einen `QWebChannel` können JavaScript (im Browser-Kontext) und Python (QGIS-Seite) bidirektional kommunizieren — z. B. um Plan-Lifecycle-Ereignisse (Layer anlegen, löschen, synchronisieren) auszulösen oder Feature-Eigenschaften für den Attribut-Editor abzurufen.

### Server-Startup

`ServerManager` startet den XMAS-App-Server als Subprozess und übergibt PostgreSQL-Verbindungsdaten (Host, Port, Datenbankname, Credentials) als Umgebungsvariablen. Anschließend pollt er `GET /health_check`, bis der Server bereit ist.