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.