first docs

docs/README.md

@@ -0,0 +1,16 @@
+- [TibiCMS](../README.md)
+- [Begriffe](begriffe.md)
+- Servergrundlagen
+    - [Konfiguration](servergrundlagen/konfiguration.md)
+    - [Entitäten](servergrundlagen/entitaeten.md)
+- RestAPI Endpunkte
+    - [/login](restapi/login.md)
+    - [/user](restapi/user.md)
+    - [/project](restapi/project.md)
+    - [/_/NS/COLLECTION](restapi/collection.md)
+- Projekt-Konfiguration
+    - [Ordnerstruktur](projektkonfig/ordnerstruktur.md)
+    - [config.yml](projektkonfig/config.yml.md)
+    - [collections](projektkonfig/collections.md)
+    - [fields](projektkonfig/fields.md)
+    - [hooks](projektkonfig/hooks.md)

docs/begriffe.md

@@ -0,0 +1,41 @@
+# Begriffe
+
+## TibiCMS
+
+Oberbegriff der den gesamten Stack, bestehend aus "tibi-server" mit "MongoDB" und "tibi-admin" beschreibt.
+
+## tibi-server
+
+REST-API Server des TibiCMS Stack
+
+## tibi-admin
+
+Admin-UI/Backend zur Verwaltung der Inhalte im "tibi-server"
+
+## API
+
+Schnittstelle (hier Rest-API) des tibi-server (im Projektkontext ebenso für Projektspezifische Schnittstelle vrwendet)
+
+## project / Projekt
+
+Projekt innerhalb des TibiCMS welches üblicherweise die Datengrundlage für eine Website im TibiCMS ist
+
+## collection / Kollektion
+
+Datensammlung innerhalb eines Projekte (z.B. Newsartikel), in relationalen Datenbanken oft eine Tabelle
+
+## field / Feld
+
+Ein Datenfeld innerhalb einer Kollektion mit einem bestimmten Datentyp (z.B. string, number, ...)
+
+## validator / Validator
+
+Code oder Anweisung zur Überprüfung der Gültigkeit von Feld-Daten
+
+## user / Benutzer
+
+Ein Benutzer mit Login innerhalb des TibiCMS
+
+## permission / Berechtigung
+
+Berechtigung innerhalb eines Projektes, welche einem Benutzer zugeordnet werden kann

docs/projektkonfig/collections.md

@@ -0,0 +1,9 @@
+# collections
+
+Die Konfiguration einer Kollektion sollte zur besseren Übersicht innerhalb einer gesonderten Datei im Unterorder "/api/collections/" erfolgen und via "!include" in die "config.yml" eingebunden werden.
+
+Eine solche Datei (z.B. democol.yml) hat folgenden Aufbau:
+
+```yaml
+
+```

docs/projektkonfig/config.yml.md

@@ -0,0 +1,52 @@
+# config.yml
+
+Die Datei "config.yml" ist der Einstieg in die API-Konfiguration eines Projekts. Die Datei kann sich an einem beliebigen Ort befinden. Die einzige Bedingung ist, dass sie durch den tibi-server lesbar ist.
+
+Es hat sich jedoch als günstig erwiesen bei Webprojekten die Datei und alle anderen Datein, die zur API-Konfiguration gehören, im ordner "/api/" unterhalb des eigentlichen Webprojektes anzuordnen. Die Quellen des Frontends und der API können somit in ein Mono-Repo eingecheckt werden.
+
+## Aufbau
+
+```yaml
+# Der Namespace legt die eigentliche Projektbezeichnung und
+# den Datenbankkontext fest.
+# Er sollte nach Projektinitialisierung auf dem tibi-server
+# nicht mehr angepasst werden.
+# In den Projekteinstellungen im tibi-server kann der Namespace
+# durch einen Datenbankeintrag überschrieben werden.
+# Über die Bezeichnung des Namespace plus einen Prefix der in
+# der globalen Server-Konfig hinterlegt ist, definiert sich der
+# Datenbank-Name innerhalb der MongoDB.
+namespace: demo
+
+# Das "meta"-Objekt ist frei definierbar, wird aber vom
+# tibi-admin in spezieller Form erwartet.
+# Mögliche Angaben, die der tibi-admin versteht, sind hier mit
+# aufgeführt.
+meta:
+  # Pfad zu einer Bilddatei die als Projektbild in der Admin-UI
+  # verwendet wird
+  imageUrl: https://testversion.online/demo.png
+    
+  # Liste möglicher Berechtigungen, die Benutzern zugeordnet
+  # werden können
+  permissions:
+    - # Name der Berechtigung
+      name: news
+      # Label für die Anzeige im Admin
+      # (kann string oder object mit Sprachen als keys sein)
+      label:
+        de: Neuigkeiten
+        en: News
+            
+    - name: pages
+      label:
+        de: Seiten
+        en: Pages
+    
+# "collections" ist eine Auflistung von
+# Kollektions-Konfigurationen. 
+# Hier bietet sich eine Auslagerung und Einbidnung via
+# YAML-Tag "!include" an.
+collections:
+  - !include collections/democol.yml
+```

docs/projektkonfig/fields.md

@@ -0,0 +1 @@
+# fields

docs/projektkonfig/hooks.md

@@ -0,0 +1 @@
+# hooks

docs/projektkonfig/ordnerstruktur.md

@@ -0,0 +1,65 @@
+# Ordnerstruktur
+
+Als Konvention für neue Projekte hat sich folgende Ordnerstruktur etabliert:
+
+![Ordnerstruktur](api-ordner.png)
+
+Die Aufteilung der YAML-Konfiguration ist durch den YAML-Tag "!include" möglich. Genaueres dazu wird auf den nachfolgenden Seiten beschrieben.
+
+## /api
+
+Der Einstigesordner in die Konfiguration ist frei wählbar. "/api" innerhalb des Projektrepositories hat sich jedoch bewährt.
+
+Die Enstiegsdatei in die Gesamt-Konfiguration liegt hier und heißt `config.yml`. In dieser können Umgebungsvariablen erstetzt werden, welche in `config.yml.env` definiert sind.
+
+Ebenso sind alle nachfolgenden Unterordner beliebig zu benennen. Da aber ein JSON-Schema und VSCode-Konfiguration zur Validierung der YAML Dateien existiert, ist folgende Struktur hilfreich.
+
+### JSON-Schema
+
+Das JSON-Schema ist in die package.json einzubinden via:
+
+```json
+  ...
+  "devDependencies": {
+    ...,
+    "tibi-types": "https://gitbase.de/cms/tibi-types.git"
+  },
+  ...
+```
+
+Die im Projekt liegende VSCode-Konfig sollte dementsprechend ergänzt werden:
+
+```json
+    ...
+    "yaml.schemas": {
+        "node_modules/tibi-types/schemas/api-config/config.json": "api/config.y*ml",
+        "node_modules/tibi-types/schemas/api-config/collection.json": "api/collections/*.y*ml",
+        "node_modules/tibi-types/schemas/api-config/field.json": "api/collections/fields/*.y*ml",
+        "node_modules/tibi-types/schemas/api-config/fieldArray.json": "api/collections/fieldLists/*.y*ml"
+    },
+    "yaml.customTags": ["!include scalar"],
+    ...
+```
+
+Sollte Yarn2 verwendet werden ist die Verlinkung von "node_modules" nötig. Dazu ist folgendes in der `.yarnrc.yml` einzutragen:
+
+```yaml
+...
+nodeLinker: node-modules
+```
+
+## /api/collections
+
+Bei Aufteilung der Kollektionskonfigurationen in einzelne Dateien, sollten diese in diesem Ordner gespeichert werden. Für jede Kollektion sollte eine eigene Datei verwendet werden, hier im Beispiel `democol.yml`.
+
+### /api/collections/fields
+
+Sollten Feldkonfigurationen wieder verwendet werden, können diese im "fields" Unterordner gepeichert werden. Diese sind pro Feldkonfiguration als einzelne Datei aufzuführen.
+
+### /api/hooks
+
+Jede Javascript-Datei, die einen Hook bedient sollte im Unterordner benannt nach der Kollektion im Ordner "hooks" sein. Der Name der Datei sollte sich nach den Hook richten. Z.B. `get_return.js` ist zustängig für den GET-Hook nach dem Lesen der Daten, bevor diese zurück gegeben werden. Mehr dazu unter [Hooks](hooks.md).
+
+### /api/templates
+
+Ist es nötig im Projekt Templates zu rendern (z.B. für den Email-Versand), sind diese im Ordner "templates" gut aufgehoben.

docs/restapi/collection.md

@@ -0,0 +1,3 @@
+# /collection
+
+TODO

docs/restapi/login.md

@@ -0,0 +1,3 @@
+# /login
+
+TODO

docs/restapi/project.md

@@ -0,0 +1,3 @@
+# /project
+
+TODO

docs/restapi/user.md

@@ -0,0 +1,3 @@
+# /_/NAMESPACE/COLLECTION
+
+TODO

docs/servergrundlagen/entitaeten.md

@@ -0,0 +1,13 @@
+# Entitäten
+
+## Projekt
+
+Jedes Projekt hat eine eigene Konfig-Datei im YAML-Format (config.yml) deren Aufbau später beschrieben wird.
+
+Wird der Server als "root" ausgeführt, so werden die individuellen Projekt-Threads mit der Benutzer- und Gruppenberechtigung der config.yml Datei ausgeführt. Somit ist ein Multi-Mandanten-Server mit getrennten Dateisystem-Berechtigungen möglich.
+
+Die Projektkonfiguration ist zwingend notwendig und wird beim Anlegen oder Bearbeiten von Projekten über die REST-API neu eingelesen.
+
+## Benutzer
+
+TODO

docs/servergrundlagen/konfiguration.md

@@ -0,0 +1,3 @@
+# Serverkonfiguration
+
+TODO