diff --git a/.vscode/settings.json b/.vscode/settings.json index 4e9ad61..469f331 100644 --- a/.vscode/settings.json +++ b/.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"] } \ No newline at end of file diff --git a/api/assets/demoassets.yml b/api/assets/demoassets.yml new file mode 100644 index 0000000..718cd96 --- /dev/null +++ b/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_ \ No newline at end of file diff --git a/api/collections/democol.yml b/api/collections/democol.yml index 4e8c8a1..706fd45 100644 --- a/api/collections/democol.yml +++ b/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 \ No newline at end of file +# 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 \ No newline at end of file diff --git a/api/config.yml b/api/config.yml index 66650a7..ff98d8c 100644 --- a/api/config.yml +++ b/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 diff --git a/api/jobs/demojob.js b/api/jobs/demojob.js new file mode 100644 index 0000000..e69de29 diff --git a/api/jobs/demojob.yml b/api/jobs/demojob.yml new file mode 100644 index 0000000..1ab3b70 --- /dev/null +++ b/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 \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index 7fcfa37..32a04de 100644 --- a/docs/README.md +++ b/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) \ No newline at end of file + - [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) diff --git a/docs/admin-javascript-kontext/allgemeines.md b/docs/admin-javascript-kontext/allgemeines.md new file mode 100644 index 0000000..5a10059 --- /dev/null +++ b/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. \ No newline at end of file diff --git a/docs/admin-javascript-kontext/collection.meta..eval.md b/docs/admin-javascript-kontext/collection.meta..eval.md new file mode 100644 index 0000000..bed42ab --- /dev/null +++ b/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` | \ No newline at end of file diff --git a/docs/admin-javascript-kontext/field.meta..eval.md b/docs/admin-javascript-kontext/field.meta..eval.md new file mode 100644 index 0000000..a9b449c --- /dev/null +++ b/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" + } + ] + } +} +``` diff --git a/docs/projektkonfig/assets.md b/docs/projektkonfig/assets.md new file mode 100644 index 0000000..00859fa --- /dev/null +++ b/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)!!! \ No newline at end of file diff --git a/docs/projektkonfig/collections.md b/docs/projektkonfig/collections.md index 1fb5976..79c8136 100644 --- a/docs/projektkonfig/collections.md +++ b/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"
"nearestNeighbor"
"linear"
"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) \ No newline at end of file diff --git a/docs/projektkonfig/collections/fields.md b/docs/projektkonfig/collections/fields.md new file mode 100644 index 0000000..7c53205 --- /dev/null +++ b/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

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`. diff --git a/docs/projektkonfig/collections/fields/datentypen.md b/docs/projektkonfig/collections/fields/datentypen.md new file mode 100644 index 0000000..5c6ae83 --- /dev/null +++ b/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 `` 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 `` 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. + diff --git a/docs/projektkonfig/collections/fields/widgets.md b/docs/projektkonfig/collections/fields/widgets.md new file mode 100644 index 0000000..40ec4ca --- /dev/null +++ b/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 \ No newline at end of file diff --git a/docs/projektkonfig/hooks.md b/docs/projektkonfig/collections/hooks.md similarity index 100% rename from docs/projektkonfig/hooks.md rename to docs/projektkonfig/collections/hooks.md diff --git a/docs/projektkonfig/collections/imageFilter.md b/docs/projektkonfig/collections/imageFilter.md new file mode 100644 index 0000000..9a97324 --- /dev/null +++ b/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"
"nearestNeighbor"
"linear"
"catmullRom" | Resampling-Algorithmus | +| `quality` | number | Ausgabequalität 0..100 | + diff --git a/docs/projektkonfig/collections/indexes.md b/docs/projektkonfig/collections/indexes.md new file mode 100644 index 0000000..c029052 --- /dev/null +++ b/docs/projektkonfig/collections/indexes.md @@ -0,0 +1,3 @@ +# indexes Liste + +TODO diff --git a/docs/projektkonfig/collections/meta.md b/docs/projektkonfig/collections/meta.md new file mode 100644 index 0000000..11053c2 --- /dev/null +++ b/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)!!! diff --git a/docs/projektkonfig/config.yml.md b/docs/projektkonfig/config.yml.md index dcb253b..5660c2c 100644 --- a/docs/projektkonfig/config.yml.md +++ b/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)!!! \ No newline at end of file +!!!include(api/config.yml)!!! + +### siehe + +- [collections](./collections.md) +- [jobs](./jobs.md) +- [assets](./assets.md) \ No newline at end of file diff --git a/docs/projektkonfig/fields.md b/docs/projektkonfig/fields.md deleted file mode 100644 index 7d4171d..0000000 --- a/docs/projektkonfig/fields.md +++ /dev/null @@ -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

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,
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 `` 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 `` 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 diff --git a/docs/projektkonfig/jobs.md b/docs/projektkonfig/jobs.md new file mode 100644 index 0000000..f19d3b8 --- /dev/null +++ b/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. \ No newline at end of file diff --git a/docs/projektkonfig/ordnerstruktur.md b/docs/projektkonfig/ordnerstruktur.md index 4d5570c..849002c 100644 --- a/docs/projektkonfig/ordnerstruktur.md +++ b/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 diff --git a/docs/restapi/assets.md b/docs/restapi/assets.md new file mode 100644 index 0000000..1ac3cd4 --- /dev/null +++ b/docs/restapi/assets.md @@ -0,0 +1,3 @@ +# `/_/NAMESPACE/_/assets/ASSETSNAME` + +TODO \ No newline at end of file diff --git a/docs/restapi/collection.md b/docs/restapi/collection.md index f2a7d66..ddaeb5a 100644 --- a/docs/restapi/collection.md +++ b/docs/restapi/collection.md @@ -1,3 +1,3 @@ -# /collection +# `/_/NAMESPACE/COLLECTION` TODO diff --git a/docs/restapi/login.md b/docs/restapi/login.md index ddbcfd7..e91c82a 100644 --- a/docs/restapi/login.md +++ b/docs/restapi/login.md @@ -1,3 +1,3 @@ -# /login +# `/login` TODO \ No newline at end of file diff --git a/docs/restapi/project.md b/docs/restapi/project.md index a29152f..c5f3799 100644 --- a/docs/restapi/project.md +++ b/docs/restapi/project.md @@ -1,3 +1,3 @@ -# /project +# `/project` TODO \ No newline at end of file diff --git a/docs/restapi/user.md b/docs/restapi/user.md index df53e67..8944d73 100644 --- a/docs/restapi/user.md +++ b/docs/restapi/user.md @@ -1,3 +1,3 @@ -# /_/NAMESPACE/COLLECTION +# `/user` TODO diff --git a/docs/server-javascript-kontext/allgemeines.md b/docs/server-javascript-kontext/allgemeines.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/hook.md b/docs/server-javascript-kontext/hook.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/job.md b/docs/server-javascript-kontext/job.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/bcrypt.md b/docs/server-javascript-kontext/packages/bcrypt.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/charset.md b/docs/server-javascript-kontext/packages/charset.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/cookie.md b/docs/server-javascript-kontext/packages/cookie.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/db.md b/docs/server-javascript-kontext/packages/db.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/debug.md b/docs/server-javascript-kontext/packages/debug.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/fs.md b/docs/server-javascript-kontext/packages/fs.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/http.md b/docs/server-javascript-kontext/packages/http.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/image.md b/docs/server-javascript-kontext/packages/image.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/jwt.md b/docs/server-javascript-kontext/packages/jwt.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/pdf.md b/docs/server-javascript-kontext/packages/pdf.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/response.md b/docs/server-javascript-kontext/packages/response.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/smtp.md b/docs/server-javascript-kontext/packages/smtp.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/tpl.md b/docs/server-javascript-kontext/packages/tpl.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/user.md b/docs/server-javascript-kontext/packages/user.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/packages/xml.md b/docs/server-javascript-kontext/packages/xml.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/server-javascript-kontext/validator.md b/docs/server-javascript-kontext/validator.md new file mode 100644 index 0000000..e69de29