refactored

.vscode/settings.json

@@ -2,10 +2,12 @@
     "editor.tabCompletion": "on",
     "diffEditor.codeLens": true,
     "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"
+        "./../../cms/tibi-types/schemas/api-config/config.json": "api/config.y*ml",
+        "./../../cms/tibi-types/schemas/api-config/collection.json": "api/collections/*.y*ml",
+        "./../../cms/tibi-types/schemas/api-config/field.json": "api/collections/fields/*.y*ml",
+        "./../../cms/tibi-types/schemas/api-config/fieldArray.json": "api/collections/fieldLists/*.y*ml",
+        "./../../cms/tibi-types/schemas/api-config/job.json": "api/jobs/*.y*ml",
+        "./../../cms/tibi-types/schemas/api-config/assets.json": "api/assets/*.y*ml"
     },
     "yaml.customTags": ["!include scalar"]
 }

api/assets/demoassets.yml

@@ -0,0 +1,12 @@
+# Ordnerpfade, die über den tibi-server direkt erreichbar seien sollen,
+# können über den "path" relativ zur "config.yml" definiert werden.
+# Durch die "name"-Definition werden diese Pfade eindeutig unterschieden.
+# Für folgende Beispielangaben bildet sich folgende URL:
+#
+#   TIBI-SERVER-URL/api/v1/_/NAMESPACE/assets/_dist_/
+# 
+# Jeder Zugriff wird intern umgeleitet auf ../frontend/_dist_/ 
+# (relativ zur "config.yml").
+# Es ist ausschließlich ein unbeschränkter Lesezugriff (GET-Methode) möglich.
+name: _dist_
+path: ../frontend/_dist_

api/collections/democol.yml

@@ -2,24 +2,110 @@
 # /_/demo/democol
 name: democol
 
-# Standardsprache für Text-Index in der Datenbank
-defaultLanguage: de
-
 # Enthält die Kollektion Felder vom Typ "file", so werden die
 # hochgeladenen Dateien unter dem Ordner abgelegt, der mit
 # "uploadPath" bestimmt wird.
 uploadPath: ../media/democol
 
-# Wie auch in der Top-Level-Konfig "config.yml" ist auch hier ein
-# "meta" Objekt möglich und nötig für die Konfiguration des
-# tibi-admin.
-# Mögliche Angaben werden im seperaten Kapitel behandelt.
-meta: !include democol/meta.yml
+# "fields" stellen die Eigentliche Struktur der Kollektion dar.
+# "fields" ist als Array angelegt um eine Standard-Sortierung
+# im tibi-admin vorzugeben.
+fields:
+    # Das Einbinden von Feldern über extra Dateien bietet sich nur
+    # an, wenn das jeweilige Feld mehrfach von dieser oder anderen
+    # Kollektionen verwendet wird.
+    # Auf die möglichen Definitionen wird im Kapitel "fields"
+    # eingegangen.
+    - !include fields/title.yml
+    - !include fields/date.yml
+    - !include fields/type.yml
 
-# "imageFilter" definieren Filter, die Bilder bearbeiten, wie
-# z.B. Verkleinerung.
-# Mögliche Angaben werden im seperaten Kapitel behandelt.
-imageFilter: !include democol/imageFilter.yml
+# Neben der Definition der Indexe innerhalbd des Feld-Objektes selbst,
+# ist die Index-Definition global für die Kollektion auch hier möglich.
+# Diese Definition ist z.B. für zusammengesetzte Index-Typen notwendig.
+# Außerdem sind hier feinere Einstellungen für den Index möglich.
+
+# Mehr dazu im "indexes" Kapitel
+indexes: 
+    - !include democol/textindex.yml
+
+# Standardsprache für Text-Index in der Datenbank
+defaultLanguage: de
+
+# "hooks" definieren die Algorithmen, die Daten und Abläufe zu bestimmten
+# HTTP-Methoden und Schritten der API manipulieren können.
+hooks:
+    # Hooks für die Methode "get"
+    get:
+        # "read"-Schritt wird ausgeführt, bevor die Daten von der Datenbank
+        # gelesen werden.
+        read:
+            # "type" ist derzeit immer "javascript"
+            type: javascript
+            # "file" zeigt auf die Datei mit dem Javascript-Code relativ zum
+            # Ordner der "config.yml" Datei.
+            file: hooks/democol/get_read.js
+        # "return"-Schritt wird ausgeführt, bevor die gelesenen Daten über
+        # HTTP übertragen werden.
+        return:
+            type: javascript
+            file: hooks/democol/get_return.js
+
+    # Hooks für die Methode "post"
+    post:
+        # "bind" wird ausgeführt, bevor die übertragenen Daten in eine
+        # Objekt-Struktur umgewandelt werden.
+        # Der tibi-server erwarten nach diesem Schritt gültige JSON-Daten,
+        # d.h. sollte es möglich gemacht werden, dass andere Daten übertragen
+        # werden, sind diese in diesem Hook abzufangen und zu verarbeiten.
+        bind:
+            type: javascript
+            file: hooks/democol/post_bind.js
+        # "validate" wird ausgeführt, bevor die Daten validiert werden.
+        validate:
+            type: javascript
+            file: hooks/democol/post_validate.js
+        # "create" wird ausgeführt, bevor das Objekt/Dokument in der Datenbank
+        # angelegt wird.
+        create:
+            type: javascript
+            file: hooks/democol/post_create.js
+        # "return" wird ausgeführt, bevor die Serverantwort über HTTP
+        # übertragen wird.
+        return:
+            type: javascript
+            file: hooks/democol/post_return.js
+
+    # Hooks für die Methode "put"
+    put:
+        bind:
+            type: javascript
+            file: hooks/democol/put_bind.js
+        validate:
+            type: javascript
+            file: hooks/democol/put_validate.js
+        # "bind" und "validate" habe die gleiche Bedeutung wie Hooks der
+        # Methode "post".
+        # "update" wird ausgeführt bevor das Objekt in der Datenbank
+        # aktualisiert wird.
+        update:
+            type: javascript
+            file: hooks/democol/put_create.js
+        # "return" wird auch hier vor der Serverantwort ausgeführt.
+        return:
+            type: javascript
+            file: hooks/democol/put_return.js
+
+    # Hooks für die Methode "delete"
+    delete:
+        # Der "delete"-Hook wird vor dem eigentlichen Löschen ausgeführt
+        delete:
+            type: javascript
+            file: hooks/democol/delete_delete.js
+        # "return"-Hook kann ebenso hier die Serverantwort manipulieren
+        return:
+            type: javascript
+            file: hooks/democol/delete_return.js
 
 # Projektionen der Daten werden via GET-Parameter "projection=..."
 # referenziert.
@@ -115,98 +201,13 @@ permissions:
             put: true
             delete: true
 
-# "hooks" definieren die Algorithmen, die Daten und Abläufe zu bestimmten
-# HTTP-Methoden und Schritten der API manipulieren können.
-hooks:
-    # Hooks für die Methode "get"
-    get:
-        # "read"-Schritt wird ausgeführt, bevor die Daten von der Datenbank
-        # gelesen werden.
-        read:
-            # "type" ist derzeit immer "javascript"
-            type: javascript
-            # "file" zeigt auf die Datei mit dem Javascript-Code relativ zum
-            # Ordner der "config.yml" Datei.
-            file: hooks/democol/get_read.js
-        # "return"-Schritt wird ausgeführt, bevor die gelesenen Daten über
-        # HTTP übertragen werden.
-        return:
-            type: javascript
-            file: hooks/democol/get_return.js
+# "imageFilter" definieren Filter, die Bilder bearbeiten, wie
+# z.B. Verkleinerung.
+# Mögliche Angaben werden im seperaten Kapitel behandelt.
+imageFilter: !include democol/imageFilter.yml
 
-    # Hooks für die Methode "post"
-    post:
-        # "bind" wird ausgeführt, bevor die übertragenen Daten in eine
-        # Objekt-Struktur umgewandelt werden.
-        # Der tibi-server erwarten nach diesem Schritt gültige JSON-Daten,
-        # d.h. sollte es möglich gemacht werden, dass andere Daten übertragen
-        # werden, sind diese in diesem Hook abzufangen und zu verarbeiten.
-        bind:
-            type: javascript
-            file: hooks/democol/post_bind.js
-        # "validate" wird ausgeführt, bevor die Daten validiert werden.
-        validate:
-            type: javascript
-            file: hooks/democol/post_validate.js
-        # "create" wird ausgeführt, bevor das Objekt/Dokument in der Datenbank
-        # angelegt wird.
-        create:
-            type: javascript
-            file: hooks/democol/post_create.js
-        # "return" wird ausgeführt, bevor die Serverantwort über HTTP
-        # übertragen wird.
-        return:
-            type: javascript
-            file: hooks/democol/post_return.js
-
-    # Hooks für die Methode "put"
-    put:
-        bind:
-            type: javascript
-            file: hooks/democol/put_bind.js
-        validate:
-            type: javascript
-            file: hooks/democol/put_validate.js
-        # "bind" und "validate" habe die gleiche Bedeutung wie Hooks der
-        # Methode "post".
-        # "update" wird ausgeführt bevor das Objekt in der Datenbank
-        # aktualisiert wird.
-        update:
-            type: javascript
-            file: hooks/democol/put_create.js
-        # "return" wird auch hier vor der Serverantwort ausgeführt.
-        return:
-            type: javascript
-            file: hooks/democol/put_return.js
-
-    # Hooks für die Methode "delete"
-    delete:
-        # Der "delete"-Hook wird vor dem eigentlichen Löschen ausgeführt
-        delete:
-            type: javascript
-            file: hooks/democol/delete_delete.js
-        # "return"-Hook kann ebenso hier die Serverantwort manipulieren
-        return:
-            type: javascript
-            file: hooks/democol/delete_return.js
-
-# "fields" stellen die Eigentliche Struktur der Kollektion dar.
-# "fields" ist als Array angelegt um eine Standard-Sortierung
-# im tibi-admin vorzugeben.
-fields:
-    # Das Einbinden von Feldern über extra Dateien bietet sich nur
-    # an, wenn das jeweilige Feld mehrfach von dieser oder anderen
-    # Kollektionen verwendet wird.
-    # Auf die möglichen Definitionen wird im Kapitel "fields"
-    # eingegangen.
-    - !include fields/title.yml
-    - !include fields/date.yml
-    - !include fields/type.yml
-
-# Neben der Definition der Indexe innerhalbd des Feld-Objektes selbst,
-# ist die Index-Definition global für die Kollektion auch hier möglich.
-# Diese Definition ist z.B. für zusammengesetzte Index-Typen notwendig.
-# Außerdem sind hier feinere Einstellungen für den Index möglich.
-# Mehr dazu im "indexes" Kapitel
-indexes: 
-    - !include democol/textindex.yml
+# Wie auch in der Top-Level-Konfig "config.yml" ist auch hier ein
+# "meta" Objekt möglich und nötig für die Konfiguration des
+# tibi-admin.
+# Mögliche Angaben werden im seperaten Kapitel behandelt.
+meta: !include democol/meta.yml

api/config.yml

@@ -28,6 +28,15 @@ meta:
         en: Pages
     
 # "collections" ist eine Auflistung von Kollektions-Konfigurationen. 
-# Hier bietet sich eine Auslagerung und Einbidnung via YAML-Tag "!include" an.
+# Hier bietet sich eine Auslagerung und Einbindung via YAML-Tag "!include" an.
 collections:
   - !include collections/democol.yml
+
+# Unter "jobs" können Jobs definiert werden, die regelmäßig ausgeführt werden sollen.
+jobs:
+    - !include jobs/demojob.yml
+
+# Werden Dateien innerhalb vom tibi-admin benötigt, bietet es sich an diese über
+# "assets"-Pfade erreichbar zu machen.
+assets:
+    - !include assets/demoasset.yml

api/jobs/demojob.yml

@@ -0,0 +1,14 @@
+# Jedem Job muss ein "cron" Eintrag zugeordnet werden, der die
+# Ausführungszeitpunkte definiert.
+# Das cron-Schema ist dem üblichen Linux cron-Schema nachempfunden.
+cron: "*/10 * * * *"
+
+# "type" des Jobs ist derzeit immer "javascript" mit der "file"-Referenz
+# relativ zur "config.yml".
+type: javascript
+file: jobs/demojob.js
+
+# Es können beliebige "meta"-Daten hinterlegt werden, die im Javascript
+# des Jobs über "context.job.meta" abgerufen werden können.
+meta:
+    name: Demo Job

docs/README.md

@@ -8,9 +8,42 @@
     - [/user](restapi/user.md)
     - [/project](restapi/project.md)
     - [/_/NS/COLLECTION](restapi/collection.md)
-- Projekt-Konfiguration
+    - [/_/NS/_/assets/ASSETSNAME](restapi/assets.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)
+        - [fields](projektkonfig/collections/fields.md)
+            - [Datentypen](projektkonfig/collections/fields/datentypen.md)
+            - [Admin Widgets](projektkonfig/collections/fields/widgets.md)
+        - [indexes](projektkonfig/collections/indexes.md)
+        - [hooks](projektkonfig/collections/hooks.md)
+        - [imageFilter](projektkonfig/collections/imageFilter.md)
+        - [meta](projektkonfig/collections/meta.md)
+    - [jobs](projektkonfig/jobs.md)
+    - [assets](projektkonfig/assets.md)
+- Admin Javascript Kontext
+    - [Allgemeines](admin-javascript-kontext/allgemeines.md)
+    - [collection.meta..eval](admin-javascript-kontext/collection.meta..eval.md)
+    - [field.meta..eval](admin-javascript-kontext/field.meta..eval.md)
+- Server Javascript Kontext
+    - [Allgmeines](server-javascript-kontext/allgemeines.md)
+    - [hook](server-javascript-kontext/hook.md)
+    - [job](server-javascript-kontext/job.md)
+    - [validator](server-javascript-kontext/validator.md)
+    - Packages
+        - [user](server-javascript-kontext/packages/user.md)
+        - [response](server-javascript-kontext/packages/response.md)
+        - [cookie](server-javascript-kontext/packages/cookie.md)
+        - [db](server-javascript-kontext/packages/db.md)
+        - [http](server-javascript-kontext/packages/http.md)
+        - [smtp](server-javascript-kontext/packages/smtp.md)
+        - [fs](server-javascript-kontext/packages/fs.md)
+        - [tpl](server-javascript-kontext/packages/tpl.md)
+        - [jwt](server-javascript-kontext/packages/jwt.md)
+        - [image](server-javascript-kontext/packages/image.md)
+        - [bcrypt](server-javascript-kontext/packages/bcrypt.md)
+        - [xml](server-javascript-kontext/packages/xml.md)
+        - [charset](server-javascript-kontext/packages/charset.md)
+        - [pdf](server-javascript-kontext/packages/pdf.md)
+        - [debug](server-javascript-kontext/packages/debug.md)

docs/admin-javascript-kontext/allgemeines.md

@@ -0,0 +1,47 @@
+# Javascript-Kontext im tibi-admin
+
+Diverse `meta`-Angaben ermöglichen neben der eigentliche Angabe eines festen Wertes wie z.B:
+
+```yaml
+defaultValue: "Hallo Welt"
+```
+
+auch die Angabe eines Javascript-Ausdrucks, der zur Laufzeit ausgewertet wird. Dieser Ausdruck wird in einem Javascript-Kontext clientseitig ausgeführt und ist mit diversen Variablen vorbelegt.
+Die Angabe des Javascript-Codes erfolgt dabei meist mit dem `eval`-Attribut dessen Wert der String des Codes ist:
+
+```yaml
+defaultValue:
+  eval: "new Date().toISOString().substr(0, 10)"
+```
+
+In den Fällen in denen ein Oneliner nicht ausreiched ist, bieten sich "selbst ausführende Funktionen" an, wie z.B.:
+
+```js
+(function() {
+    return new Date().toISOString().substr(0, 10)
+})()
+```
+
+Um diese im YAML unterzubringen nutzt man YAML-Multiline-Modifizierer:
+
+```yaml
+defaultValue:
+  eval: |
+    (function() {
+      return new Date().toISOString().substr(0, 10)
+    })()
+```
+
+## Kontext-Variablen
+
+Der Javascript-Kontext ist mit folgenden Variablen standardmäßig angereichert:
+
+| Variable | Datentyp | Bedeutung |
+| --- | --- | --- | --- | --- |
+| `$namespace` | string | Der Namespacebezeichner des aktuellen Projekts |
+| `$apiBase` | string | Basis-URL des API-Endpunkts |
+| `$projectBase` | string | Basis-URL des Projekts-API-Endpunkts (`$apiBase`_/`$namespace`/) |
+| `$auth` TODO | object | Das aktuelle Auth-Objetc des eingeloggten Benutzers |
+| `$project` | object | Das aktuelle Projekt-Objekt, siehe [API /project](./../restapi/project.md) |
+
+Die `meta`-Daten der Collections und Fields bekommen in den Javascript-Kontext der `eval`-Eigenschaften noch jeweils zusätzliche Variablen.

docs/admin-javascript-kontext/collection.meta..eval.md

@@ -0,0 +1,9 @@
+# collection.meta..eval Javascript-Kontext
+
+Die `eval`-Properties der Eigenschaften (wo möglich) bekommen unterhalb des `collection.meta`-Objektes zusätzlich zu den bereits bekannten Variablen (siehe [Allgemeines zum Kontext](./allgemeines.md)) folgende Variable zur Verfügung:
+
+
+| Variable | Datentyp | Bedeutung |
+| --- | --- | --- | --- | --- |
+| `$object` | object | Das aktuelle Kollektion-Objekt, siehe [API /collection](./../restapi/collection.md) |
+| `$navigation` | object | Das aktuelle Navigation-Objekt, also den entsprechenden aktiven Eintrag aus `meta.subNavigation` |

docs/admin-javascript-kontext/field.meta..eval.md

@@ -0,0 +1,104 @@
+# field.meta..eval Javascript-Kontext
+
+Zuätzlich zu den allgemeinen und Kollektions-spezifischen Variablen, die im Javascript-Kontext der `eval`-Eigenschaften unterhalb des zur Verfügung stehen, gibt es noch folgende Variablen unterhalb des `field.meta`-Objektes für die Evaluierung:
+
+| Variable | Datentyp | Bedeutung |
+| --- | --- | --- | --- | --- |
+| `$field` TODO | object | Das aktuelle Feld-Objekt |
+| `$method` | `"post"`/`"put"` | `"put"` bedeuted, dass der Datensatz gerade in Bearbeitung ist, `"post"` = Datensatz soll angelegt werden |
+| `$this` | any | Der aktuelle Wert des Feldes |
+| `$` | object | Das gesamte Objekt des Dokuments |
+| `$parent` | object oder array | Der Wert des Elternknotens zum aktuellen Feld |
+| `$stack` | array | Der Stack bis zum Ursprung des gesamten Objekts |
+
+## Der Stack
+
+Um die Abhängigkeiten zu bestimmten Werten ausdrücken zu können (z.B. in `meta.dependsOn.eval`), sind die Variablen `$this`, `$`, `$parent` und `$stack` verfügbar.
+
+Folgendes Beispiel eines Datensatzes verdeutlicht die Belegung, während die Maske zum Editieren im *tibi-admin* geöffnet ist:
+
+
+```json
+{
+    "title": "Mein Datensatz",
+    "meta": {
+        "keywords": [
+            {
+                "key": "pla",
+                "description": "Ah Plah"
+            },
+            {
+                "key": "blup",
+                "description": "Buh Blup"
+            }
+        ]
+    }
+}
+```
+
+wobei wir den `"key": "pla"` betrachten, wären die Inhalte der Variablen folgende:
+
+`$this`:
+
+plah
+
+`$parent` und `$stack[0]`:
+
+```json
+{
+    "key": "pla",
+    "description": "Ah Plah"
+}
+```
+
+`$stack[1]`:
+
+```json
+[
+    {
+        "key": "pla",
+        "description": "Ah Plah"
+    },
+    {
+        "key": "blup",
+        "description": "Buh Blup"
+    }
+]
+```
+
+`$stack[2]`:
+
+```json
+{
+    "keywords": [
+        {
+            "key": "pla",
+            "description": "Ah Plah"
+        },
+        {
+            "key": "blup",
+            "description": "Buh Blup"
+        }
+    ]
+}
+```
+
+`$stack[3]`, `entry` und  `$`:
+
+```json
+{
+    "title": "Mein Datensatz",
+    "meta": {
+        "keywords": [
+            {
+                "key": "pla",
+                "description": "Ah Plah"
+            },
+            {
+                "key": "blup",
+                "description": "Buh Blup"
+            }
+        ]
+    }
+}
+```

docs/projektkonfig/assets.md

@@ -0,0 +1,6 @@
+# assets
+
+Folgende Angaben sind in der `assets`-Sektion der [config.yml](./config.yml.md) geführt als Liste möglich:
+
+
+!!!include(api/assets/demoassets.yml)!!!

docs/projektkonfig/collections.md

@@ -8,67 +8,10 @@ Eine solche Datei hat folgenden Aufbau:
 
 !!!include(api/collections/democol.yml)!!!
 
-## imageFilter Objekt
+### siehe
 
-Die Bildmanipulation von hochgeladen Bildern zu einer Kollektion kann über das `imageFilter` Objekt definiert werden.
-Der Filter wird angewandt, wenn an die Bild-URL der Parameter `filter=...` angehangen wird.
-
-Der Prozess selbst erfolgt beim ersten Abruf des Bildes und wird zwischengespeichert.
-
-Eine beispielhafte Konfiguration, die die Bilder nur verkleinert sieht so aus:
-
-!!!include(api/collections/democol/imageFilter.yml)!!!
-
-Folgende Attribute können Filter-Eintrage haben, wobei `fit` und `fill` exklusiv sind:
-
-| Attribut | Typ | Beschreibung |
-| --- | --- | --- |
-| `fit` | boolean | passt das Bild in ein Rechteck ein |
-| `fill` | boolean | streckt/staucht das Bild, so dass es das Rechteck komplett ausfüllt |
-| `height` | number | Höhe des Rechtecks |
-| `width` | number | Breite des Rechtecks |
-| `blur` | number | Verwischungsgrad |
-| `brightness` | number | Helligkeit |
-| `contrast` | number | Konrast |
-| `gamma` | number | Gamma-Wert |
-| `saturation` | number | Sättigung |
-| `sharpen` | number | Schärfe |
-| `invert` | boolean | Farben invertieren |
-| `grayscale` | boolean | Schwarz-Weiß |
-| `resampling` | "lanczos"<br>"nearestNeighbor"<br>"linear"<br>"catmullRom" | Resampling-Algorithmus |
-| `quality` | number | Ausgabequalität 0..100 |
-
-
-## indexes Liste
-
-TODO
-
-## meta Objekt
-
-Wie bereits an anderer Stelle beschrieben, dient das `meta` Objekt zur Definition von Merkmalen, die im *tibi-admin* finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
-
-Folgende Angaben sind möglich:
-
-!!!include(api/collections/democol/meta.yml)!!!
-
-### views Liste
-
-`views` werden für die Darstellung der Kollektion-Daten im *tibi-admin* benötigt. Die Auswahl des passenden View erfolgt über CSS Media-Queries.
-
-Optionale Unternavigationen können eigene `views` haben.
-
-Folgende möglche Einträge für `views` gibt es derzeit:
-
-#### simpleList
-
-!!!include(api/collections/democol/simpleList.yml)!!!
-
-#### table
-
-!!!include(api/collections/democol/table.yml)!!!
-
-### tablist
-
-Wird die `tablist` verwendet, ist sicher zu stellen, dass alle Felder in der Definition aufgenommen werden. Werden Felder nicht in die `tablist` aufgenommen, sind diese weiterhin in einer Gesamtliste unterhalb der Tabs und bringen das Layout durcheinander.
-
-!!!include(api/collections/democol/tablist.yml)!!!
+- [fields](./collections/fields.md)
+- [indexes](./collections/indexes.md)
+- [hooks](./collections/hooks.md)
+- [imageFilter](./collections/imageFilter.md)
+- [meta](./collections/meta.md)

docs/projektkonfig/collections/fields.md

@@ -0,0 +1,67 @@
+# fields
+
+Felder im *tibi-server* müssen einen bestimmten Datentyp haben. Über den *tibi-admin* können die Felder über Widgets in unterschiedlichen Ausprägungen dargestellt werden (view-Widgets), bzw. dem Benutzer eine Eingabe abverlangen (input-Widgets).
+
+Es gibt grundlegende Angaben, die jedes Feld haben muss um vom *tibi-server* akzeptiert zu werden. Darüber hinaus kann auch jedes Feld ein `meta` Objekt haben, was dem *tibi-admin* mitteilt, wie er dieses Feld für Ausgabe und Eingabe behandel soll.
+
+Zunächst folgt der grundlegende Aufbau des Feld-Objektes:
+
+!!!include(api/collections/fields/date.yml)!!!
+
+## validator Objekt
+
+Das `validator` Objekt wird *tibi-server* seitig genutzt um die Daten zu validieren. Da das `validator` Objekt dem *tibi-admin* ebenso zur Verfügung steht, kann vorab eine client-seitige Validierung zusätzlich durchgeführt werden.
+
+Attribute des Objektes:
+
+| Attribut | Datentyp | Beschreibung |
+| --- | --- | --- |
+| `required` | boolean | wenn `true`, dann ist zwingend eine Eingabe zu diesem Feld nötig |
+| `allowZero` | boolean | in Kombination mit `required: true`, wenn `true`, dann ist der jeweilige "Null"-Wert des Datentyps erlaubt<br><br>z.B. `type: string` erlaubt den leeren String und `type: number` erlaubt `0` |
+| `eval` | string | Javascript-Code der zu true evaluieren muss um den Wert des Feldes als gültig zu definieren |
+
+### eval-Attribut
+
+Der Javascript-Code in diesem Attribut kann folgende Rückgabe-Werte haben:
+
+| Wert | Bedeutung |
+| --- | --- |
+| `true` | Der Wert des Feldes ist gültig |
+| `false` | Der Wert des Feldes ist ungültig |
+| `"Text"` | Wird ein String zurückgegeben ist, wird der Wert es Feldes ebenso als ungültig erachtet und der String selbst ist eine benutzerdefinierte Fehlermeldung, die in der Serverantwort gelesen werden kann. |
+
+Da der `eval` Code serverseitig immer ausgeführt wird und ein Fehlschlag zwangsläufig zum Abbruch der Serveraktion führt, ist es wichtig, dass der [serverseitige Javascript-Kontext](./../../server-javascript-kontext/validator.md) berücksichtigt wird.
+
+Optional kann der Code auch zusätzlich über eine Lauffähigkeit ohne Fehler (z.B. keine Verwendung nicht vorhandender Kontext-Variablen oder Verwendung von `try ... catch`) im *tibi-admin* verfügen. Das hat den Vorteil, dass eine Vorab-Validierung stattfindet, bevor der Datensatz an der Server gesendet wird.
+
+Sollte der `eval` Code im *tibi-admin* nicht lauffähig sein (nicht abgefangene Exception), wird der Validator clientseitig ingoriert und nur die serverseitige Prüfung beeinflusst die Aktion.
+
+#### siehe
+
+- [Server Javascript Kontext](./../../server-javascript-kontext/allgemeines.md)
+- [Validator Javascript Kontext](./../../server-javascript-kontext/validator.md)
+
+## dependsOn
+
+`meta.dependsOn` kann als Objekt mit `eval`-Attribut für Javascript oder als `string` mit dem Feldnamen (Punktschreibweise, z.B. `"additionalData.author"`) angegeben werden.
+
+Wird der Feldname verwendet wird nur geprüft, ob das Feld belegt ist. TODO
+
+Die `eval` Variante verwendet als Javascript-Kontext Variablen die auf folgenden Seite beschrieben werden:
+
+- [Admin Javascript Kontext](./../../admin-javascript-kontext/allgemeines.md)
+- [collection.meta..eval](./../../admin-javascript-kontext/collection.meta..eval.md)
+- [field.meta..eval](./../../admin-javascript-kontext/field.meta..eval.md)
+
+Die Rückgabe des Javascript-Codes beeinflusst die Einblendung des betroffenen Feldes in folgender Weise:
+
+| Rückgabe | Bedeutung |
+| --- | --- |
+| `true` | Das Feld wird angezeigt |
+| `false` | Das Feld wird ausgeblendet |
+
+## defaultValue
+
+Für die Vorlegung neu anzulegender Datensätze kann in `field.meta.defaultValue` direkt der Standardwert hinterlegt werden, oder über `field.meta.defaultValue.eval` ein Javascript-Code angegeben werden, der den Wert ermittelt. Die Rückgabe des Javascript-Codes, sowie auch die direkte Vergabe des Wertes muss dem Datentyp des Feldes entsprechen.
+
+Der Javascript-Kontext ist der gleiche wie bei `field.meta.dependsOn.eval`.

docs/projektkonfig/collections/fields/datentypen.md

@@ -0,0 +1,44 @@
+# Datentypen
+
+Via `type` wird der Datentyp des Feldes definiert. Folgende Datentypen sind möglich:
+
+## string
+
+String wird für Zeichenketten verwendet. Das Standardwidget ohne weitere Angabe ist bei der Ausgabe die direkte Textausgabe und bei der Eingabe ein HTML `<input ...>` Element mit dem Attribut `type="text"`.
+
+## number
+
+Number wird sowohl für ganze Zahlen, wie auch für Gleitkommawerte definiert. Auch hier ist das Standard-Widget für die Eingabe ein HTML `<input ...>` Element, allerdings mit dem Attribut `type="number"`.
+
+## boolean
+
+Ein boolcher Wert, also `true` oder `false`, wird über den Typ `"boolean"` definiert und standardmäßig als Checkbox dargestellt.
+
+## date
+
+`"date"` als Datentyp kann sowohl Datumsangabe mit, als auch ohne Uhrzeit aufnehmen. Das Standardwidget ist die einfache Datumseingabe ohne Uhrzeit.
+
+## file
+
+Der Datentyp `"file"` ist für Dateiuploads vorgesehen. Es daher standardmäßig ein Datei-Auswahl-Dialog als Widget für die Eingabe angeboten.
+
+## string[]
+
+Für `"string[]` Arrays ist die Angabe des Widgets zwingend notwendig.
+
+## number[]
+
+Auch für `"number[]"` Arrays wird die Widget-Angabe erwartet.
+
+## object
+
+`"object"` ist ein spezieller Datentyp der zur Strukturierung der API und der Eingabe dient. Dieser Datentyp fasst `subFields` zusammen.
+
+## object[]
+
+Wie `"object"` fasst auch das `"object[]"` Array `subFields` zusammen. Diese allerdings als Liste von Objekten, anstatt als Einzelobjekt.
+
+## any
+
+Felder vom Typ `"any"` können beliebige Daten aufnehmen. Die Validierung schlägt auf Basis der Typ-Validierung hier nie fehl.
+

docs/projektkonfig/collections/fields/widgets.md

@@ -0,0 +1,37 @@
+# Widgets
+
+Das im *tibi-admin* für die Ein- und Ausgabe von Daten zu verwendente Widget wird über die Feldkonfiguration `meta.widget` festgelegt. Die Angabe erfolgt als String mit dem Widget-Namen.
+
+Nicht jedes Widget kann mit jedem Datentyp umgehen, die möglichen Datentypen werden aber nachfolgend bei jedem Widget erwähnt. Außerdem wird auf individuelle Konfigurationsmöglichkeiten eingegangen.
+
+## text
+
+## number
+
+## checkbox
+
+## select
+
+## date
+
+## datetime
+
+## richtext
+
+## file
+
+## image
+
+## selectArray
+
+## checkboxArray
+
+## chipArray
+
+## object
+
+## objectArray
+
+## tabs
+
+## contentbuilder

docs/projektkonfig/collections/imageFilter.md

@@ -0,0 +1,30 @@
+# imageFilter Objekt
+
+Die Bildmanipulation von hochgeladen Bildern zu einer Kollektion kann über das `imageFilter` Objekt definiert werden.
+Der Filter wird angewandt, wenn an die Bild-URL der Parameter `filter=...` angehangen wird.
+
+Der Prozess selbst erfolgt beim ersten Abruf des Bildes und wird zwischengespeichert.
+
+Eine beispielhafte Konfiguration, die die Bilder nur verkleinert sieht so aus:
+
+!!!include(api/collections/democol/imageFilter.yml)!!!
+
+Folgende Attribute können Filter-Eintrage haben, wobei `fit` und `fill` exklusiv sind:
+
+| Attribut | Typ | Beschreibung |
+| --- | --- | --- |
+| `fit` | boolean | passt das Bild in ein Rechteck ein |
+| `fill` | boolean | streckt/staucht das Bild, so dass es das Rechteck komplett ausfüllt |
+| `height` | number | Höhe des Rechtecks |
+| `width` | number | Breite des Rechtecks |
+| `blur` | number | Verwischungsgrad |
+| `brightness` | number | Helligkeit |
+| `contrast` | number | Konrast |
+| `gamma` | number | Gamma-Wert |
+| `saturation` | number | Sättigung |
+| `sharpen` | number | Schärfe |
+| `invert` | boolean | Farben invertieren |
+| `grayscale` | boolean | Schwarz-Weiß |
+| `resampling` | "lanczos"<br>"nearestNeighbor"<br>"linear"<br>"catmullRom" | Resampling-Algorithmus |
+| `quality` | number | Ausgabequalität 0..100 |
+

docs/projektkonfig/collections/indexes.md

@@ -0,0 +1,3 @@
+# indexes Liste
+
+TODO

docs/projektkonfig/collections/meta.md

@@ -0,0 +1,29 @@
+# meta Objekt
+
+Wie bereits an anderer Stelle beschrieben, dient das `meta` Objekt zur Definition von Merkmalen, die im *tibi-admin* finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
+
+Folgende Angaben sind möglich:
+
+!!!include(api/collections/democol/meta.yml)!!!
+
+## views Liste
+
+`views` werden für die Darstellung der Kollektion-Daten im *tibi-admin* benötigt. Die Auswahl des passenden View erfolgt über CSS Media-Queries.
+
+Optionale Unternavigationen können eigene `views` haben.
+
+Folgende möglche Einträge für `views` gibt es derzeit:
+
+### simpleList
+
+!!!include(api/collections/democol/simpleList.yml)!!!
+
+### table
+
+!!!include(api/collections/democol/table.yml)!!!
+
+## tablist
+
+Wird die `tablist` verwendet, ist sicher zu stellen, dass alle Felder in der Definition aufgenommen werden. Werden Felder nicht in die `tablist` aufgenommen, sind diese weiterhin in einer Gesamtliste unterhalb der Tabs und bringen das Layout durcheinander.
+
+!!!include(api/collections/democol/tablist.yml)!!!

docs/projektkonfig/config.yml.md

@@ -6,4 +6,10 @@ Es hat sich jedoch als günstig erwiesen bei Webprojekten die Datei und alle and
 
 ## Aufbau
 
-!!!include(api/config.yml)!!!
+!!!include(api/config.yml)!!!
+
+### siehe
+
+- [collections](./collections.md)
+- [jobs](./jobs.md)
+- [assets](./assets.md)

docs/projektkonfig/fields.md

@@ -1,251 +0,0 @@
-# fields
-
-Felder im *tibi-server* müssen einen bestimmten Datentyp haben. Über den *tibi-admin* können die Felder über Widgets in unterschiedlichen Ausprägungen dargestellt werden (view-Widgets), bzw. dem Benutzer eine Eingabe abverlangen (input-Widgets).
-
-Es gibt grundlegende Angaben, die jedes Feld haben muss um vom *tibi-server* akzeptiert zu werden. Darüber hinaus kann auch jedes Feld ein `meta` Objekt haben, was dem *tibi-admin* mitteilt, wie er dieses Feld für Ausgabe und Eingabe behandel soll.
-
-Zunächst folgt der grundlegende Aufbau des Feld-Objektes:
-
-!!!include(api/collections/fields/date.yml)!!!
-
-## validator Objekt
-
-Das `validator` Objekt wird *tibi-server* seitig genutzt um die Daten zu validieren. Da das `validator` Objekt dem *tibi-admin* ebenso zur Verfügung steht, kann vorab eine client-seitige Validierung zusätzlich durchgeführt werden.
-
-Attribute des Objektes:
-
-| Attribut | Datentyp | Beschreibung |
-| --- | --- | --- |
-| `required` | boolean | wenn `true`, dann ist zwingend eine Eingabe zu diesem Feld nötig |
-| `allowZero` | boolean | in Kombination mit `required: true`, wenn `true`, dann ist der jeweilige "Null"-Wert des Datentyps erlaubt<br><br>z.B. `type: string` erlaubt den leeren String und `type: number` erlaubt `0` |
-| `eval` | string | Javascript-Code der zu true evaluieren muss um den Wert des Feldes als gültig zu definieren |
-
-### eval-Attribut
-
-Der Javascript-Code in diesem Attribut kann folgende Rückgabe-Werte haben:
-
-| Wert | Bedeutung |
-| --- | --- |
-| `true` | Der Wert des Feldes ist gültig |
-| `false` | Der Wert des Feldes ist ungültig |
-| `"Text"` | Wird ein String zurückgegeben ist, wird der Wert es Feldes ebenso als ungültig erachtet und der String selbst ist eine benutzerdefinierte Fehlermeldung, die in der Serverantwort gelesen werden kann. |
-
-Es ist ein Oneliner wie `new Date($this) > new Date()` meist ausreichend. Für komplexere Prüfungen ist eine sich selbst ausführende Funktion aber geeigneter, wie z.B.
-
-```javascript
-(function() {
-    if (new Date($this) > new Date()) {
-        return true
-    }
-    return false
-})()
-```
-
-Dafür eignen sich im YAML Multiline-Modifizierer wie z.B.:
-
-```yaml
-eval: |
-    (function() {
-        if (new Date($this) > new Date()) {
-            return true
-        }
-        return false
-    })()
-```
-
-Wie im obigen Beispiel zu sehen, gibt es spezielle Variablen die im Javascript zur Verfügung stehen. Nicht alle Variablen stehen server- und clientseitig (*tibi-admin*) zur Verfügung. Eine ensprechende Ausnahmebehandlung ist daher nötig.
-
-Folgende Variablen stehen zur Verfügung:
-
-| Variable | Datentyp | tibi-server | tibi-admin | Bedeutung |
-| --- | --- | --- | --- | --- |
-| `$this` |  | X | X | | Der Wert des Feldes in dem der Validator ausgeführt wird. |
-| `$` (alias `entry`) | object | X | X | Das gesamte Objekt des Dokuments |
-| `$parent` | object oder array | X | X | Der Wert des Elternknotens zum aktuellen Feld |
-| `$stack` | array | X | X | Der Stack bis zum Ursprung des gesamten Objekts |
-| `$namespace` | string | X | TODO | Die Bezeichnung des Namespace des aktuellen Projekts |
-| `$method` | `"post"`/`"put"` | X | TODO | Die HTTP-Methode (Kleinschreibung) |
-| `$auth` | object oder `null` | X | TODO | Das aktuelle Auth-Objekt des eingeloggten Benutzers, siehe Hooks `context.user.auth()` |
-| `context` | object | X | - | Das serverseitige context-Objekt, siehe Hooks |
-
-Für die beispielhafte Übertragung von
-
-```json
-{
-    "title": "Mein Datensatz",
-    "meta": {
-        "keywords": [
-            {
-                "key": "pla",
-                "description": "Ah Plah"
-            },
-            {
-                "key": "blup",
-                "description": "Buh Blup"
-            }
-        ]
-    }
-}
-```
-
-wobei wir den `"key": "pla"` betrachten, wären die Inhalte der Variablen folgende:
-
-`$this`:
-
-plah
-
-`$parent` und `$stack[0]`:
-
-```json
-{
-    "key": "pla",
-    "description": "Ah Plah"
-}
-```
-
-`$stack[1]`:
-
-```json
-[
-    {
-        "key": "pla",
-        "description": "Ah Plah"
-    },
-    {
-        "key": "blup",
-        "description": "Buh Blup"
-    }
-]
-```
-
-`$stack[2]`:
-
-```json
-{
-    "keywords": [
-        {
-            "key": "pla",
-            "description": "Ah Plah"
-        },
-        {
-            "key": "blup",
-            "description": "Buh Blup"
-        }
-    ]
-}
-```
-
-`$stack[3]`, `entry` und  `$`:
-
-```json
-{
-    "title": "Mein Datensatz",
-    "meta": {
-        "keywords": [
-            {
-                "key": "pla",
-                "description": "Ah Plah"
-            },
-            {
-                "key": "blup",
-                "description": "Buh Blup"
-            }
-        ]
-    }
-}
-```
-
-
-
-## dependsOn und defaultValue Kontext
-
-Der Javascript-Kontext ist für das `eval`-Attribut von `dependsOn` und `defaultValue` ebenso mit Variablen angereichert, wie es beim `validator.eval` der Fall ist. Da der entsprechende Code allerdings nur client-seitig ausgeführt wird (im Feld `meta` Objekt), sind nicht alle Variablen identisch.
-
-Folgende Unterschiede gibt es zu den bereits beschriebenen Variablen von `validator.eval`:
-
-| Variable | Unterschied |
-| --- | --- |
-| `context` | nicht vorhanden |
-| `$method` | `"put"` bedeuted, dass der Datensatz gerade in Bearbeitung ist, `"post"` = Datensatz soll angelegt werden |
-| `$navigation` | nur hier vorhanden, da der Server keine `subNavigation` Liste kennt,<br>enthält das aktuelle Objekt der aktiven Unternavigation, also den entprechenden Listeneintrag aus `meta.subNavigation` |
-
-
-## Datentypen
-
-Via `type` wird der Datentyp des Feldes definiert. Folgende Datentypen sind möglich:
-
-### string
-
-String wird für Zeichenketten verwendet. Das Standardwidget ohne weitere Angabe ist bei der Ausgabe die direkte Textausgabe und bei der Eingabe ein HTML `<input ...>` Element mit dem Attribut `type="text"`.
-
-### number
-
-Number wird sowohl für ganze Zahlen, wie auch für Gleitkommawerte definiert. Auch hier ist das Standard-Widget für die Eingabe ein HTML `<input ...>` Element, allerdings mit dem Attribut `type="number"`.
-
-### boolean
-
-Ein boolcher Wert, also `true` oder `false`, wird über den Typ `"boolean"` definiert und standardmäßig als Checkbox dargestellt.
-
-### date
-
-`"date"` als Datentyp kann sowohl Datumsangabe mit, als auch ohne Uhrzeit aufnehmen. Das Standardwidget ist die einfache Datumseingabe ohne Uhrzeit.
-
-### file
-
-Der Datentyp `"file"` ist für Dateiuploads vorgesehen. Es daher standardmäßig ein Datei-Auswahl-Dialog als Widget für die Eingabe angeboten.
-
-### string[]
-
-Für `"string[]` Arrays ist die Angabe des Widgets zwingend notwendig.
-
-### number[]
-
-Auch für `"number[]"` Arrays wird die Widget-Angabe erwartet.
-
-### object
-
-`"object"` ist ein spezieller Datentyp der zur Strukturierung der API und der Eingabe dient. Dieser Datentyp fasst `subFields` zusammen.
-
-### object[]
-
-Wie `"object"` fasst auch das `"object[]"` Array `subFields` zusammen. Diese allerdings als Liste von Objekten, anstatt als Einzelobjekt.
-
-### any
-
-Felder vom Typ `"any"` können beliebige Daten aufnehmen. Die Validierung schlägt auf Basis der Typ-Validierung hier nie fehl.
-
-## Widgets
-
-Das im *tibi-admin* für die Ein- und Ausgabe von Daten zu verwendente Widget wird über die Feldkonfiguration `meta.widget` festgelegt. Die Angabe erfolgt als String mit dem Widget-Namen.
-
-Nicht jedes Widget kann mit jedem Datentyp umgehen, die möglichen Datentypen werden aber nachfolgend bei jedem Widget erwähnt. Außerdem wird auf individuelle Konfigurationsmöglichkeiten eingegangen.
-
-### text
-
-### number
-
-### checkbox
-
-### select
-
-### date
-
-### datetime
-
-### richText
-
-### file
-
-### image
-
-### selectArray
-
-### checkboxArray
-
-### chipArray
-
-### object
-
-### objectArray
-
-### tabs

docs/projektkonfig/jobs.md

@@ -0,0 +1,11 @@
+# jobs
+
+In dem ein oder anderen Projekt werden sicherlich Jobs im Hintergrund benötigt, die zu bestimmten Zeiten oder Intervallweise ausgeführt werden müssen (z.B. Datenbereinigung). Diese Jobs können innerhalb der [config.yml](./config.yml.md) definiert werden.
+
+Wie in allen YAML-Definitionen können auch die Jobs via `!include` ausgelagert werden.
+
+Der Aufbau eines Jobs ausgelagert in einer Datei sieht beispielsweise folgendermaßen aus:
+
+!!!include(api/jobs/demojob.yml)!!!
+
+Die Möglichkeiten innerhalb der Javascript-Datei werden im Kapitel [Javascript Kontext](./../server-javascript-kontext/job.md) beschrieben.

docs/projektkonfig/ordnerstruktur.md

@@ -54,11 +54,11 @@ Bei Aufteilung der Kollektionskonfigurationen in einzelne Dateien, sollten diese
 
 ### /api/collections/fields
 
-Sollten Feldkonfigurationen wieder verwendet werden, können diese im [api/collections/fields/](./fields.md) Unterordner gepeichert werden. Diese sind pro Feldkonfiguration als einzelne Datei aufzuführen.
+Sollten Feldkonfigurationen wieder verwendet werden, können diese im [api/collections/fields/](./collections/fields.md) 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 [api/hooks/](./hooks.md) 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).
+Jede Javascript-Datei, die einen Hook bedient sollte im Unterordner benannt nach der Kollektion im Ordner [api/hooks/](./collections/hooks.md) 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](./collections/hooks.md).
 
 ### /api/templates
 

docs/restapi/assets.md

@@ -0,0 +1,3 @@
+# `/_/NAMESPACE/_/assets/ASSETSNAME`
+
+TODO

docs/restapi/collection.md

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

docs/restapi/login.md

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

docs/restapi/project.md

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

docs/restapi/user.md

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