This commit is contained in:
Ismail Ali
2025-05-27 19:41:17 +02:00
parent 257341475c
commit 97fbb6fdc1
86 changed files with 1452 additions and 1185 deletions

26
docs/pages/_app.md Normal file
View File

@@ -0,0 +1,26 @@
<!-- /docs/pages/_app.md -->
# 🌐 _app.js
Diese Datei stellt die Haupt-Wrap-Komponente der Next.js-App dar.
Sie initialisiert globale Provider wie den Redux Store.
## Features
- Importiert globales CSS (`styles/global.css`)
- Bindet Redux `Provider` um alle Seiten-Komponenten
- Ermöglicht Zugriff auf Store in allen Seiten
## Struktur
```jsx
<Provider store={store}>
<Component {...pageProps} />
</Provider>
```
## Pfad
```bash
/pages/_app.js
```

View File

@@ -1,67 +0,0 @@
# 📘 API-Routen in `/pages/api/`
Dieses Dokument beschreibt die internen API-Routen der Anwendung (Next.js API Routes) und erklärt die verwendeten URL-Parameter sowie Konventionen bei der Nutzung im Backend.
---
## 🔗 Übergabeparameter aus TALAS.web
Beim Aufruf der Anwendung über TALAS.web werden die folgenden URL-Parameter übergeben:
| Parameter | Bedeutung | Verwendung im Code |
|-----------|------------------|---------------------------|
| `m` | Map-ID (`idMap`) | `req.query.m` |
| `u` | User-ID (`idUser`)| `req.query.u` |
> ⚠️ Es wird bewusst **nicht** `idMap` oder `idUser` verwendet, da TALAS mit Kurzparametern arbeitet.
### Beispiel:
```ts
const idMap = req.query.m;
const idUser = req.query.u;
```
---
## 🛠 Zweck des Verzeichnisses `/pages/api/`
Alle Dateien in diesem Verzeichnis definieren serverseitige Endpunkte. Diese:
- werden **nur auf dem Server ausgeführt**
- sind über `fetch('/api/...')` vom Frontend aufrufbar
- dienen als **Proxy zu SOAP-Webservices** oder **Zugriff auf die Datenbank**
---
## 📁 Beispiel: Aufruf eines Webservice
```bash
GET /api/gisSystemStatic?m=10&u=484
```
Dieser Request wird serverseitig weitergeleitet an:
```
http://[SERVER]/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=10&idUser=484
```
---
## 📄 Übersicht interner API-Routen
| API-Route | Beschreibung |
|----------------------------------|------------------------------------------|
| `/api/gisSystemStatic` | Proxy zu WebService GisSystemStatic |
| `/api/gisStationsStaticDistrict` | Geräte-Liste inkl. Bereich |
| `/api/gisStationsMeasurements` | Live-Messwerte der Geräte |
| `/api/talas_v5_DB/pois/readLocations` | POIs aus der Datenbank (MySQL) |
| `/api/talas_v5_DB/device/getAllStationsNames` | Gerätnamen aus DB |
---
## 🔐 Sicherheitshinweis
- Kein sensibler Parameter darf hart codiert sein
- Alle Server-URLs werden über `.env.local` konfiguriert
- Nur `m` und `u` aus `req.query` verwenden keine Fallbacks oder Defaults

View File

@@ -0,0 +1,45 @@
<!-- /docs/pages/api/[...path].md -->
# 🌐 [...path].js
Next.js API-Proxy-Handler mit `http-proxy-middleware`.
Dient als Middleware zur Weiterleitung von API-Requests an das Backend (z.B. Raspberry Pi oder Entwicklungsserver).
---
## 🔧 Funktion
- Leitet alle Requests von `/api/...` an das definierte `target` weiter
- Entfernt `/api` aus dem URL-Pfad
- Erlaubt Cross-Origin Requests mit `changeOrigin: true`
---
## Ziel-Logik
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const target = mode === "dev" ? "http://localhost:80" : "http://localhost";
```
---
## Beispiel
- Frontend-Request: `GET /api/GisStationsStaticDistrict`
- Weitergeleitet an: `GET http://localhost:80/GisStationsStaticDistrict`
---
## Besonderheiten
- Ermöglicht portunabhängige Proxy-Nutzung über `.env`
- Setzt `logLevel: "debug"` zur Diagnose
---
## Pfad
```bash
/pages/api/[...path].js
```

View File

@@ -1,77 +0,0 @@
# 🌐 API Proxy [...path].js
## Zweck
Diese Datei (`pages/api/[...path].js`) dient als **Catch-All Proxy**
für externe Webservice-Aufrufe über die Next.js API-Routing-Struktur.
Sie leitet alle Anfragen unter `/api/...` an einen Zielserver weiter.
---
## Technologie
Verwendet wird:
- [`http-proxy-middleware`](https://github.com/chimurai/http-proxy-middleware)
- Dynamische Zielauswahl basierend auf Umgebungsvariable `NEXT_PUBLIC_API_PORT_MODE`
---
## Ziel-URL-Konfiguration
```js
const mode = process.env.NEXT_PUBLIC_API_PORT_MODE;
const target =
mode === "dev"
? "http://localhost:80"
: "http://localhost"; // oder z.B. http://10.10.0.13
```
➡ Dadurch entfällt die feste Konfiguration über `NEXT_PUBLIC_SERVER_URL`.
---
## Beispiel: Weiterleitung
Request im Browser:
```
GET /api/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
→ wird weitergeleitet an:
```
http://localhost/talas5/ClientData/WebServiceMap.asmx/GisSystemStatic?idMap=12&idUser=484
```
---
## Verwendete Einstellungen
```js
export default createProxyMiddleware({
target,
changeOrigin: true,
pathRewrite: {
"^/api": "/", // entfernt /api aus dem Pfad
},
logLevel: "debug",
});
```
---
## Vorteile
| Punkt | Nutzen |
|---------------------------|------------------------------------------|
| Keine doppelte API-Konfiguration | ✅ `.env.local` bereinigt |
| Wiederverwendbar & flexibel | ✅ funktioniert lokal & auf Servern |
| Klar gekapselt in `[...path].js` | ✅ übersichtlich |
---
📄 Pfad: `/docs/server/pages/api/apiProxy.md`

View File

@@ -0,0 +1,28 @@
<!-- /docs/pages/api/talas_v5_DB/area/readArea.md -->
# 📥 readArea.js
Liest Bereichskoordinaten (`location_coordinates`) aus der Datenbank basierend auf `idMaps` (und optional `idLocation`).
## Methode
- `GET`
## URL-Parameter
| Name | Beschreibung |
|-------------|--------------------------------------|
| `m` | Karten-ID (entspricht `idMaps`) |
| `idLocation` | (optional) ID eines bestimmten Bereichs |
## Verhalten
- Joint `location`, `location_coordinates` und `area`-Tabelle
- Gibt strukturierte Daten mit `x`, `y`, `location_name`, `area_name` zurück
- Nutzt MySQL-Pool (`getPool()`)
## Beispiel
```http
GET /api/talas_v5_DB/area/readArea?m=3
```

View File

@@ -0,0 +1,32 @@
<!-- /docs/pages/api/talas_v5_DB/area/updateArea.md -->
# 📤 updateArea.js
Aktualisiert die Koordinaten eines Bereichs (`location_coordinates`) basierend auf `idLocation` und `idMap`.
## Methode
- `PUT`
## Request-Body
```json
{
"idLocation": 12,
"idMap": 3,
"x": 53.21421,
"y": 8.43212
}
```
## Verhalten
- Führt `UPDATE location_coordinates SET x=?, y=? WHERE idLocation=? AND idMaps=?`
- Gibt bei Erfolg `success: true` zurück
- Nutzt MySQL-Pool und `connection.release()`
## Fehlerbehandlung
- 400: Fehlende Daten
- 404: Kein Eintrag gefunden
- 500: Interner Fehler

View File

@@ -0,0 +1,29 @@
<!-- /docs/pages/api/talas_v5_DB/device/getAllStationsNames.md -->
# 🧾 getAllStationsNames.js
Liefert eine Zuordnungstabelle aller Geräte-IDs (`idLD`) zu ihren Namen (`name`).
## Methode
- `GET`
## Antwortformat
```json
{
"123": "Kue 705",
"124": "Basisstation 1"
}
```
## Verhalten
- Nutzt Tabelle `location_device`
- Gibt Fehler bei leerem Ergebnis (404) oder Datenbankfehler (500)
## Pfad
```bash
/pages/api/talas_v5_DB/device/getAllStationsNames.js
```

View File

@@ -0,0 +1,34 @@
<!-- /docs/pages/api/talas_v5_DB/device/getDevices.md -->
# 🔌 getDevices.js
API-Route zum Abrufen aller Geräteinformationen aus der `devices`-Tabelle.
## Methode
- `POST` (erwartet JSON-Body mit optionalem `activeSystems`-Array)
## Verhalten
- Führt ein einfaches `SELECT * FROM devices` aus
- Nutzt Singleton-MySQL-Pool für Verbindung
- Rückgabe: JSON-Array mit allen Geräteobjekten
## Beispielantwort
```json
[
{
"id": 1,
"name": "Kue705",
"idsystem_typ": 1,
...
}
]
```
## Pfad
```bash
/pages/api/talas_v5_DB/device/getDevices.js
```

View File

@@ -0,0 +1,25 @@
<!-- /docs/pages/api/talas_v5_DB/gisLines/readGisLines.md -->
# 🧭 readGisLines.js
Liefert alle Linien aus der Tabelle `gis_lines`.
## Methode
- `GET`
## Rückgabe
- JSON-Array mit Objekten aus `gis_lines`
- Leeres Array bei keinen Treffern
## Besonderheiten
- Nutzt Singleton-Pool (`getPool()`)
- Immer HTTP 200, auch bei leerem Ergebnis
## Beispiel
```http
GET /api/talas_v5_DB/gisLines/readGisLines
```

View File

@@ -0,0 +1,30 @@
<!-- /docs/pages/api/talas_v5_DB/gisLines/updateLineCoordinates.md -->
# ✏️ updateLineCoordinates.js
Aktualisiert die `points`-Spalte einer Linie in der Tabelle `gis_lines`.
## Methode
- `POST`
## Request-Body
```json
{
"idLD": 7,
"idModul": 2,
"newCoordinates": [[53.2151, 8.4522], [53.2165, 8.4531]]
}
```
## Verhalten
- Erzeugt aus Koordinaten eine `LINESTRING(...)`
- Nutzt `ST_GeomFromText()` in MySQL
- Transaktion mit Commit/Rollback
## Fehlerfälle
- 400: Ungültige oder fehlende Felder
- 500: Datenbankfehler

View File

@@ -0,0 +1,26 @@
<!-- /docs/pages/api/talas_v5_DB/locationDevice/getDeviceId.md -->
# 🔍 getDeviceId.js
Gibt die Geräte-ID (`idLD`) zu einem übergebenen Gerätenamen zurück.
## Methode
- `GET`
## Parameter
| Name | Beschreibung |
|-------------|----------------------|
| `deviceName` | Der Gerätename (z.B. "Kue705") |
## Antwort
```json
{ "idLD": 27 }
```
## Fehler
- 400: Wenn `deviceName` fehlt
- 404: Gerät nicht gefunden

View File

@@ -0,0 +1,26 @@
<!-- /docs/pages/api/talas_v5_DB/locationDevice/locationDeviceNameById.md -->
# 🏷️ locationDeviceNameById.js
Gibt den Namen eines Geräts anhand seiner ID zurück.
## Methode
- `GET`
## Parameter
| Name | Beschreibung |
|--------|------------------------|
| `idLD` | Geräte-ID (z.B. 27) |
## Antwort
```json
{ "name": "Kue705" }
```
## Fehler
- 400: Fehlender Parameter
- 404: Gerät mit ID nicht gefunden

View File

@@ -0,0 +1,27 @@
<!-- /docs/pages/api/talas_v5_DB/locationDevice/locationDevices.md -->
# 🗂️ locationDevices.js
Gibt eine vollständige Liste aller Geräte in der Tabelle `location_device` zurück.
## Methode
- `GET`
## Verhalten
- Führt `SELECT * FROM location_device ORDER BY name` aus
- Gibt vollständige Objekte zurück
## Beispielantwort
```json
[
{
"idLD": 27,
"name": "Kue705",
"description": "...",
...
}
]
```

View File

@@ -0,0 +1,36 @@
<!-- /docs/pages/api/talas_v5_DB/poiTyp/readPoiTyp.md -->
# 🗂️ readPoiTyp.js
Liefert alle verfügbaren POI-Typen aus der Tabelle `poityp`.
## Methode
- `GET`
## Rückgabe
- JSON-Array mit allen Einträgen in `poityp`
## Besonderheiten
- Gibt bei leerem Ergebnis `200` mit Warnung zurück
- Verwendet Singleton-Verbindungspool (`getPool()`)
## Beispiel
```http
GET /api/talas_v5_DB/poiTyp/readPoiTyp
```
## Antwort
```json
[
{
"idPoiTyp": 1,
"name": "Messgerät",
"icon": 12
}
]
```

View File

@@ -0,0 +1,25 @@
<!-- /docs/pages/api/talas_v5_DB/pois/addPoi.md -->
# addPoi.js
Fügt einen neuen POI (Point of Interest) zur Datenbank hinzu.
## Methode
- `POST`
## Request-Body
```json
{
"name": "POI A",
"poiTypeId": 1,
"latitude": 53.2,
"longitude": 8.1,
"idLD": 27
}
```
## Besonderheiten
- Position wird als `POINT(longitude latitude)` gespeichert

View File

@@ -0,0 +1,20 @@
<!-- /docs/pages/api/talas_v5_DB/pois/deletePoi.md -->
# ❌ deletePoi.js
Löscht einen POI anhand seiner ID.
## Methode
- `DELETE`
## Query-Parameter
| Parameter | Beschreibung |
|-----------|---------------------|
| `id` | ID des POI (`idPoi`) |
## Antwort
- 200: Erfolgreich gelöscht
- 404: POI nicht gefunden

View File

@@ -0,0 +1,21 @@
<!-- /docs/pages/api/talas_v5_DB/pois/getPoiById.md -->
# 🔎 getPoiById.js
Gibt die Beschreibung eines POIs zurück.
## Methode
- `GET`
## Query-Parameter
| Parameter | Beschreibung |
|-----------|--------------|
| `idPoi` | POI-ID |
## Antwort
```json
{ "description": "POI A" }
```

View File

@@ -0,0 +1,21 @@
<!-- /docs/pages/api/talas_v5_DB/pois/poi-icons.md -->
# 🖼️ poi-icons.js
Gibt eine Liste aller POIs und ihrer zugehörigen Icon-Pfade zurück.
## Methode
- `GET`
## Datenquelle
- `poi``poiTyp``poiicons`
## Antwort
```json
[
{ "idPoi": 12, "path": "/icons/kue.svg" }
]
```

View File

@@ -0,0 +1,17 @@
<!-- /docs/pages/api/talas_v5_DB/pois/readAllPOIs.md -->
# 📋 readAllPOIs.js
Gibt alle POIs mit Positionen zurück.
## Methode
- `GET`
## Rückgabe
- JSON-Array mit `idPoi`, `description`, `idPoiTyp`, `idLD`, `position`
## Besonderheiten
- Position wird per `ST_AsText(...)` als String geliefert

View File

@@ -0,0 +1,23 @@
<!-- /docs/pages/api/talas_v5_DB/pois/updateLocation.md -->
# 🧭 updateLocation.js
Aktualisiert die Position (`POINT`) eines POIs.
## Methode
- `POST`
## Request-Body
```json
{
"id": 12,
"latitude": 53.2,
"longitude": 8.1
}
```
## Antwort
- 200: `{ success: true }`

View File

@@ -0,0 +1,25 @@
<!-- /docs/pages/api/talas_v5_DB/pois/updatePoi.md -->
# 📝 updatePoi.js
Aktualisiert Beschreibung, Typ und Gerät eines POIs.
## Methode
- `POST`
## Request-Body
```json
{
"idPoi": 12,
"description": "POI A",
"idPoiTyp": 2,
"idLD": 27
}
```
## Antwort
- 200: Erfolgreich aktualisiert
- 404: POI nicht gefunden

View File

@@ -0,0 +1,29 @@
<!-- /docs/pages/api/talas_v5_DB/station/getAllStationsNames.md -->
# 🏷️ getAllStationsNames.js
Liefert eine Mapping-Tabelle aus `idLD``name` aller Einträge in `location_device`.
## Methode
- `GET`
## Rückgabe
```json
{
"12": "Hauptstation",
"13": "Unterstation"
}
```
## Verhalten
- Antwort ist ein Key-Value-Objekt
- Nutzt `reduce()` zur Map-Erstellung
- Verwendet MySQL-Singleton-Pool
## Fehler
- 404: Wenn keine Daten vorhanden
- 500: Datenbankfehler

View File

@@ -0,0 +1,40 @@
<!-- /docs/pages/api/talas_v5_DB/device/getDevices.md -->
# 📦 getDevices.js
Gibt alle Geräte aus der `devices`-Tabelle zurück.
## Methode
- `POST`
## Request-Body
```json
{
"activeSystems": [1, 2, 3]
}
```
⚠️ Hinweis: Im aktuellen Code wird der Parameter `activeSystems` nicht verwendet!
## Rückgabe
- JSON-Array mit Geräteobjekten
## Beispielantwort
```json
[
{
"id": 1,
"name": "CPL V4.0",
"idsystem_typ": 1
}
]
```
## Fehler
- 404: Keine Ergebnisse
- 500: Datenbankfehler

32
docs/pages/index.md Normal file
View File

@@ -0,0 +1,32 @@
<!-- /docs/pages/index.md -->
# 🏠 index.js (Home-Seite)
Die Hauptseite der Anwendung.
Bindet dynamisch die Leaflet-Karte (`MapComponent`) und ein Testscripting-Tool (`TestScript`).
## Features
- `MapComponent` ohne SSR eingebunden
- `TestScript` prüft per Konsole Logik/Strukturen
- Lädt POI-Daten per `fetchPoiMarkersThunk()`
- Liest URL-Parameter `m` und `u`
- Unterstützt POI-Hinzufügen über `addPoiThunk(...)`
## Redux-Slices
- `poiMarkersSlice`
- `addPoiSlice`
- `poiReadFromDbTrigger`
## Struktur
```jsx
<MapComponentWithNoSSR locations={locations} onAddLocation={handleAddLocation} />
<TestScriptWithNoSSR />
```
## Besonderheiten
- Dynamisches Nachladen der POIs bei Triggeränderung
- Fehleranzeige über `addPoiStatus` + `addPoiError`