refactored
This commit is contained in:
parent
705754f608
commit
f173af8e12
10
.vscode/settings.json
vendored
10
.vscode/settings.json
vendored
@ -2,10 +2,12 @@
|
|||||||
"editor.tabCompletion": "on",
|
"editor.tabCompletion": "on",
|
||||||
"diffEditor.codeLens": true,
|
"diffEditor.codeLens": true,
|
||||||
"yaml.schemas": {
|
"yaml.schemas": {
|
||||||
"node_modules/tibi-types/schemas/api-config/config.json": "api/config.y*ml",
|
"./../../cms/tibi-types/schemas/api-config/config.json": "api/config.y*ml",
|
||||||
"node_modules/tibi-types/schemas/api-config/collection.json": "api/collections/*.y*ml",
|
"./../../cms/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",
|
"./../../cms/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/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"]
|
"yaml.customTags": ["!include scalar"]
|
||||||
}
|
}
|
12
api/assets/demoassets.yml
Normal file
12
api/assets/demoassets.yml
Normal file
@ -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_
|
@ -2,24 +2,110 @@
|
|||||||
# /_/demo/democol
|
# /_/demo/democol
|
||||||
name: democol
|
name: democol
|
||||||
|
|
||||||
# Standardsprache für Text-Index in der Datenbank
|
|
||||||
defaultLanguage: de
|
|
||||||
|
|
||||||
# Enthält die Kollektion Felder vom Typ "file", so werden die
|
# Enthält die Kollektion Felder vom Typ "file", so werden die
|
||||||
# hochgeladenen Dateien unter dem Ordner abgelegt, der mit
|
# hochgeladenen Dateien unter dem Ordner abgelegt, der mit
|
||||||
# "uploadPath" bestimmt wird.
|
# "uploadPath" bestimmt wird.
|
||||||
uploadPath: ../media/democol
|
uploadPath: ../media/democol
|
||||||
|
|
||||||
# Wie auch in der Top-Level-Konfig "config.yml" ist auch hier ein
|
# "fields" stellen die Eigentliche Struktur der Kollektion dar.
|
||||||
# "meta" Objekt möglich und nötig für die Konfiguration des
|
# "fields" ist als Array angelegt um eine Standard-Sortierung
|
||||||
# tibi-admin.
|
# im tibi-admin vorzugeben.
|
||||||
# Mögliche Angaben werden im seperaten Kapitel behandelt.
|
fields:
|
||||||
meta: !include democol/meta.yml
|
# 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
|
# Neben der Definition der Indexe innerhalbd des Feld-Objektes selbst,
|
||||||
# z.B. Verkleinerung.
|
# ist die Index-Definition global für die Kollektion auch hier möglich.
|
||||||
# Mögliche Angaben werden im seperaten Kapitel behandelt.
|
# Diese Definition ist z.B. für zusammengesetzte Index-Typen notwendig.
|
||||||
imageFilter: !include democol/imageFilter.yml
|
# 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=..."
|
# Projektionen der Daten werden via GET-Parameter "projection=..."
|
||||||
# referenziert.
|
# referenziert.
|
||||||
@ -115,98 +201,13 @@ permissions:
|
|||||||
put: true
|
put: true
|
||||||
delete: true
|
delete: true
|
||||||
|
|
||||||
# "hooks" definieren die Algorithmen, die Daten und Abläufe zu bestimmten
|
# "imageFilter" definieren Filter, die Bilder bearbeiten, wie
|
||||||
# HTTP-Methoden und Schritten der API manipulieren können.
|
# z.B. Verkleinerung.
|
||||||
hooks:
|
# Mögliche Angaben werden im seperaten Kapitel behandelt.
|
||||||
# Hooks für die Methode "get"
|
imageFilter: !include democol/imageFilter.yml
|
||||||
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"
|
# Wie auch in der Top-Level-Konfig "config.yml" ist auch hier ein
|
||||||
post:
|
# "meta" Objekt möglich und nötig für die Konfiguration des
|
||||||
# "bind" wird ausgeführt, bevor die übertragenen Daten in eine
|
# tibi-admin.
|
||||||
# Objekt-Struktur umgewandelt werden.
|
# Mögliche Angaben werden im seperaten Kapitel behandelt.
|
||||||
# Der tibi-server erwarten nach diesem Schritt gültige JSON-Daten,
|
meta: !include democol/meta.yml
|
||||||
# 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
|
|
@ -28,6 +28,15 @@ meta:
|
|||||||
en: Pages
|
en: Pages
|
||||||
|
|
||||||
# "collections" ist eine Auflistung von Kollektions-Konfigurationen.
|
# "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:
|
collections:
|
||||||
- !include collections/democol.yml
|
- !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
|
||||||
|
0
api/jobs/demojob.js
Normal file
0
api/jobs/demojob.js
Normal file
14
api/jobs/demojob.yml
Normal file
14
api/jobs/demojob.yml
Normal file
@ -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
|
@ -8,9 +8,42 @@
|
|||||||
- [/user](restapi/user.md)
|
- [/user](restapi/user.md)
|
||||||
- [/project](restapi/project.md)
|
- [/project](restapi/project.md)
|
||||||
- [/_/NS/COLLECTION](restapi/collection.md)
|
- [/_/NS/COLLECTION](restapi/collection.md)
|
||||||
- Projekt-Konfiguration
|
- [/_/NS/_/assets/ASSETSNAME](restapi/assets.md)
|
||||||
|
- Projekt Konfiguration
|
||||||
- [Ordnerstruktur](projektkonfig/ordnerstruktur.md)
|
- [Ordnerstruktur](projektkonfig/ordnerstruktur.md)
|
||||||
- [config.yml](projektkonfig/config.yml.md)
|
- [config.yml](projektkonfig/config.yml.md)
|
||||||
- [collections](projektkonfig/collections.md)
|
- [collections](projektkonfig/collections.md)
|
||||||
- [fields](projektkonfig/fields.md)
|
- [fields](projektkonfig/collections/fields.md)
|
||||||
- [hooks](projektkonfig/hooks.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)
|
||||||
|
47
docs/admin-javascript-kontext/allgemeines.md
Normal file
47
docs/admin-javascript-kontext/allgemeines.md
Normal file
@ -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.
|
9
docs/admin-javascript-kontext/collection.meta..eval.md
Normal file
9
docs/admin-javascript-kontext/collection.meta..eval.md
Normal file
@ -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` |
|
104
docs/admin-javascript-kontext/field.meta..eval.md
Normal file
104
docs/admin-javascript-kontext/field.meta..eval.md
Normal file
@ -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"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
6
docs/projektkonfig/assets.md
Normal file
6
docs/projektkonfig/assets.md
Normal file
@ -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)!!!
|
@ -8,67 +8,10 @@ Eine solche Datei hat folgenden Aufbau:
|
|||||||
|
|
||||||
!!!include(api/collections/democol.yml)!!!
|
!!!include(api/collections/democol.yml)!!!
|
||||||
|
|
||||||
## imageFilter Objekt
|
### siehe
|
||||||
|
|
||||||
Die Bildmanipulation von hochgeladen Bildern zu einer Kollektion kann über das `imageFilter` Objekt definiert werden.
|
- [fields](./collections/fields.md)
|
||||||
Der Filter wird angewandt, wenn an die Bild-URL der Parameter `filter=...` angehangen wird.
|
- [indexes](./collections/indexes.md)
|
||||||
|
- [hooks](./collections/hooks.md)
|
||||||
Der Prozess selbst erfolgt beim ersten Abruf des Bildes und wird zwischengespeichert.
|
- [imageFilter](./collections/imageFilter.md)
|
||||||
|
- [meta](./collections/meta.md)
|
||||||
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)!!!
|
|
67
docs/projektkonfig/collections/fields.md
Normal file
67
docs/projektkonfig/collections/fields.md
Normal file
@ -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`.
|
44
docs/projektkonfig/collections/fields/datentypen.md
Normal file
44
docs/projektkonfig/collections/fields/datentypen.md
Normal file
@ -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.
|
||||||
|
|
37
docs/projektkonfig/collections/fields/widgets.md
Normal file
37
docs/projektkonfig/collections/fields/widgets.md
Normal file
@ -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
|
30
docs/projektkonfig/collections/imageFilter.md
Normal file
30
docs/projektkonfig/collections/imageFilter.md
Normal file
@ -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 |
|
||||||
|
|
3
docs/projektkonfig/collections/indexes.md
Normal file
3
docs/projektkonfig/collections/indexes.md
Normal file
@ -0,0 +1,3 @@
|
|||||||
|
# indexes Liste
|
||||||
|
|
||||||
|
TODO
|
29
docs/projektkonfig/collections/meta.md
Normal file
29
docs/projektkonfig/collections/meta.md
Normal file
@ -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)!!!
|
@ -6,4 +6,10 @@ Es hat sich jedoch als günstig erwiesen bei Webprojekten die Datei und alle and
|
|||||||
|
|
||||||
## Aufbau
|
## Aufbau
|
||||||
|
|
||||||
!!!include(api/config.yml)!!!
|
!!!include(api/config.yml)!!!
|
||||||
|
|
||||||
|
### siehe
|
||||||
|
|
||||||
|
- [collections](./collections.md)
|
||||||
|
- [jobs](./jobs.md)
|
||||||
|
- [assets](./assets.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
|
|
11
docs/projektkonfig/jobs.md
Normal file
11
docs/projektkonfig/jobs.md
Normal file
@ -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.
|
@ -54,11 +54,11 @@ Bei Aufteilung der Kollektionskonfigurationen in einzelne Dateien, sollten diese
|
|||||||
|
|
||||||
### /api/collections/fields
|
### /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
|
### /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
|
### /api/templates
|
||||||
|
|
||||||
|
3
docs/restapi/assets.md
Normal file
3
docs/restapi/assets.md
Normal file
@ -0,0 +1,3 @@
|
|||||||
|
# `/_/NAMESPACE/_/assets/ASSETSNAME`
|
||||||
|
|
||||||
|
TODO
|
@ -1,3 +1,3 @@
|
|||||||
# /collection
|
# `/_/NAMESPACE/COLLECTION`
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
@ -1,3 +1,3 @@
|
|||||||
# /login
|
# `/login`
|
||||||
|
|
||||||
TODO
|
TODO
|
@ -1,3 +1,3 @@
|
|||||||
# /project
|
# `/project`
|
||||||
|
|
||||||
TODO
|
TODO
|
@ -1,3 +1,3 @@
|
|||||||
# /_/NAMESPACE/COLLECTION
|
# `/user`
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
0
docs/server-javascript-kontext/allgemeines.md
Normal file
0
docs/server-javascript-kontext/allgemeines.md
Normal file
0
docs/server-javascript-kontext/hook.md
Normal file
0
docs/server-javascript-kontext/hook.md
Normal file
0
docs/server-javascript-kontext/job.md
Normal file
0
docs/server-javascript-kontext/job.md
Normal file
0
docs/server-javascript-kontext/packages/bcrypt.md
Normal file
0
docs/server-javascript-kontext/packages/bcrypt.md
Normal file
0
docs/server-javascript-kontext/packages/charset.md
Normal file
0
docs/server-javascript-kontext/packages/charset.md
Normal file
0
docs/server-javascript-kontext/packages/cookie.md
Normal file
0
docs/server-javascript-kontext/packages/cookie.md
Normal file
0
docs/server-javascript-kontext/packages/db.md
Normal file
0
docs/server-javascript-kontext/packages/db.md
Normal file
0
docs/server-javascript-kontext/packages/debug.md
Normal file
0
docs/server-javascript-kontext/packages/debug.md
Normal file
0
docs/server-javascript-kontext/packages/fs.md
Normal file
0
docs/server-javascript-kontext/packages/fs.md
Normal file
0
docs/server-javascript-kontext/packages/http.md
Normal file
0
docs/server-javascript-kontext/packages/http.md
Normal file
0
docs/server-javascript-kontext/packages/image.md
Normal file
0
docs/server-javascript-kontext/packages/image.md
Normal file
0
docs/server-javascript-kontext/packages/jwt.md
Normal file
0
docs/server-javascript-kontext/packages/jwt.md
Normal file
0
docs/server-javascript-kontext/packages/pdf.md
Normal file
0
docs/server-javascript-kontext/packages/pdf.md
Normal file
0
docs/server-javascript-kontext/packages/response.md
Normal file
0
docs/server-javascript-kontext/packages/response.md
Normal file
0
docs/server-javascript-kontext/packages/smtp.md
Normal file
0
docs/server-javascript-kontext/packages/smtp.md
Normal file
0
docs/server-javascript-kontext/packages/tpl.md
Normal file
0
docs/server-javascript-kontext/packages/tpl.md
Normal file
0
docs/server-javascript-kontext/packages/user.md
Normal file
0
docs/server-javascript-kontext/packages/user.md
Normal file
0
docs/server-javascript-kontext/packages/xml.md
Normal file
0
docs/server-javascript-kontext/packages/xml.md
Normal file
0
docs/server-javascript-kontext/validator.md
Normal file
0
docs/server-javascript-kontext/validator.md
Normal file
Loading…
Reference in New Issue
Block a user