cms/tibi-docs
Template
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

styling

Browse Source
This commit is contained in:
Sebastian Frank 2022-11-03 10:05:44 +00:00
parent 8fd120aba3
commit 705754f608
13 changed files with 112 additions and 93 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.md
View File

@ -1,21 +1,21 @@
# TibiCMS Dokumentation
Quickstart Anleitung zum TibiCMS (tibi-server und tibi-admin)
Anleitung zum *TibiCMS* (*tibi-server* und *tibi-admin*)
## Einleitung
TibiCMS ist der Sammelbegriff für die Komponenten "tibi-server" und "tibi-admin", welche einen REST-API Server und eine Administrationsoberfläche zur Verfügung stellen. Auf Basis dieser beiden Komponenten und der MongoDB als Abhängigkeit lassen sich WebCMS Anwendungen abbilden.
*TibiCMS* ist der Sammelbegriff für die Komponenten *tibi-server* und *tibi-admin*, welche einen Rest-API Server und eine Administrationsoberfläche zur Verfügung stellen. Auf Basis dieser beiden Komponenten und der *MongoDB* als Abhängigkeit lassen sich WebCMS Anwendungen abbilden.
Das CMS ist multi-mandanten-fähig, d.h. es kann mehrer Projekte mit unterschiedlichen Zugriffsbeschränkungen verwalten.
### tibi-server
Der Server selbst kommt ohne grafische Oberfläche oder WebUI. Er ist ausschließlich nach außen über eine REST-API erreichbar.
Der Server selbst kommt ohne grafische Oberfläche oder WebUI. Er ist ausschließlich nach außen über eine Rest-API erreichbar.
Als einzige Abhängigkeit ist eine "MongoDB" zu erwähnen. Da der Server in Go geschrieben ist, sind keine externen Bibliotheken notwendig. Er lässt sich daher prima via Docker-Container verteilen.
Als einzige Abhängigkeit ist eine *MongoDB* zu erwähnen. Da der Server in Go geschrieben ist, sind keine externen Bibliotheken notwendig. Er lässt sich daher prima via Docker-Container verteilen.
### tibi-admin
Die Administrationsoberfläche ist wie jeder andere Service, der die REST-API des Servers nutzt, nur ein Frontend. tibi-admin läuft vollständig im Browser und benötigt nur einen Webserver, der statischen Content ausliefert.
Die Administrationsoberfläche ist wie jeder andere Service, der die Rest-API des Servers nutzt, nur ein Frontend. *tibi-admin* läuft vollständig im Browser und benötigt nur einen Webserver, der statischen Content ausliefert.
Die Version der Admin-UI sollte synchron zur tibi-server Version gehalten werden, damit alle Datentypen bedient werden können.
Die Version des *tibi-admin* sollte synchron zur *tibi-server* Version gehalten werden, damit alle Datentypen bedient werden können.

8
api/collections/democol.yml
View File

@ -11,8 +11,8 @@ defaultLanguage: de
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 der
# Admin-UI.
# "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
@ -105,7 +105,7 @@ permissions:
# Alle Berechtigungs-Namen, die nicht "public", "user" oder "token:..."
# heißen, sind benutzerdefinierte Berechtigungen, die Benutzern
# zugeordnet werden können.
# Eine mögliche Auflistung um Vorschläge in der Admin-UI anzubieten,
# Eine mögliche Auflistung um Vorschläge im tibi-admin anzubieten,
# werden im Top-Level meta-Objekt der "config.yml" unter "permissions"
# definiert.
pages:
@ -192,7 +192,7 @@ hooks:
# "fields" stellen die Eigentliche Struktur der Kollektion dar.
# "fields" ist als Array angelegt um eine Standard-Sortierung
# in der Admin-UI vorzugeben.
# 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

2
api/collections/democol/meta.yml
View File

@ -1,4 +1,4 @@
# Ein Label für die Admin-UI wird mehrsprachig folgendermaßen definiert
# Ein Label für tibi-admin wird mehrsprachig folgendermaßen definiert
label:
de: Demo-Kolletion
en: Demo-Collection

2
api/collections/fields/date.yml
View File

@ -28,7 +28,7 @@ validator:
eval: new Date($this) > new Date()
# Und natürlich gibt es auch hier ein "meta" Objekt zur Steuerung
# der Admin-UI.
# des tibi-admin.
meta:
# Das "label" des Feldes wird als Label vor dem Widget verwendet.
label:

2
api/config.yml
View File

@ -9,7 +9,7 @@ namespace: demo
# Das "meta"-Objekt ist frei definierbar, wird aber vom tibi-admin in spezieller Form erwartet.
# Mögliche Angaben, die der tibi-admin versteht, sind hier mit aufgeführt.
meta:
# Pfad zu einer Bilddatei die als Projektbild in der Admin-UI verwendet wird
# Pfad zu einer Bilddatei die als Projektbild im tibi-admin verwendet wird
imageUrl: https://testversion.online/demo.png
# Liste möglicher Berechtigungen, die Benutzern zugeordnet werden können

12
docs/begriffe.md
View File

@ -2,23 +2,23 @@
## TibiCMS
Oberbegriff der den gesamten Stack, bestehend aus "tibi-server" mit "MongoDB" und "tibi-admin" beschreibt.
Oberbegriff der den gesamten Stack, bestehend aus *tibi-server* mit *MongoDB** und *tibi-admin* beschreibt.
## tibi-server
REST-API Server des TibiCMS Stack
Rest-API Server des *TibiCMS* Stack
## tibi-admin
Admin-UI/Backend zur Verwaltung der Inhalte im "tibi-server"
Admin-UI/Backend zur Verwaltung der Inhalte im *tibi-server*
## API
Schnittstelle (hier Rest-API) des tibi-server (im Projektkontext ebenso für Projektspezifische Schnittstelle vrwendet)
Schnittstelle (hier Rest-API) des *tibi-server* (im Projektkontext ebenso für Projektspezifische Schnittstelle vrwendet)
## project / Projekt
Projekt innerhalb des TibiCMS welches üblicherweise die Datengrundlage für eine Website im TibiCMS ist
Projekt innerhalb des *TibiCMS* welches üblicherweise die Datengrundlage für eine Website im *TibiCMS* ist
## collection / Kollektion
@ -46,7 +46,7 @@ Vorerst nur in Javascript geschriebene Algorithmen, die die sich in die API eink
## user / Benutzer
Ein Benutzer mit Login innerhalb des TibiCMS
Ein Benutzer mit Login innerhalb des *TibiCMS*
## permission / Berechtigung

8
docs/docpress.css
View File

@ -24,3 +24,11 @@ ul.heading-list .hlink, ul.heading-list .hlink:visited {
right: 0px;
opacity: 1!important;
}
a {
color: #7c2828!important;
}
code {
color:#3a0909!important;
}

2
docs/github-dark-dimmed.css
View File

@ -8,7 +8,7 @@
Colors taken from GitHub's CSS
*/
.hljs, pre {
.hljs, pre, pre code {
color: #adbac7!important;
background: #22272e!important;
}

48
docs/projektkonfig/collections.md
View File

@ -1,17 +1,17 @@
# collections
Die Konfiguration einer Kollektion sollte zur besseren Übersicht innerhalb einer gesonderten Datei im Unterorder "/api/collections/" erfolgen und via "!include" in die "config.yml" eingebunden werden.
Die Konfiguration einer Kollektion sollte zur besseren Übersicht innerhalb einer gesonderten Datei im Unterorder **api/collections/** erfolgen und via `!include` in die [config.yml](./config.yml.md) eingebunden werden.
## Grundlegender Aufbau
Eine solche Datei (z.B. democol.yml) hat folgenden Aufbau:
Eine solche Datei hat folgenden Aufbau:
!!!include(api/collections/democol.yml)!!!
## 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.
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.
@ -19,24 +19,24 @@ 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:
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 |
| `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
@ -45,7 +45,7 @@ TODO
## meta Objekt
Wie bereits an anderer Stelle beschrieben, dient das meta-Objekt zur Definition von Merkmalen, die in der Admin-UI Verwendung finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
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:
@ -53,11 +53,11 @@ Folgende Angaben sind möglich:
### views Liste
"views" werden für die Darstellung der Kollektion-Daten in der Admin-UI benötigt. Die Auswahl des passenden View erfolgt über CSS Media-Queries.
`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.
Optionale Unternavigationen können eigene `views` haben.
Folgende Views gibt es derzeit:
Folgende möglche Einträge für `views` gibt es derzeit:
#### simpleList
@ -69,6 +69,6 @@ Folgende Views gibt es derzeit:
### 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.
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)!!!

4
docs/projektkonfig/config.yml.md
View File

@ -1,8 +1,8 @@
# config.yml
Die Datei "config.yml" ist der Einstieg in die API-Konfiguration eines Projekts. Die Datei kann sich an einem beliebigen Ort befinden. Die einzige Bedingung ist, dass sie durch den tibi-server lesbar ist.
Die Datei **config.yml** ist der Einstieg in die API-Konfiguration eines Projekts. Die Datei kann sich an einem beliebigen Ort befinden. Die einzige Bedingung ist, dass sie durch den tibi-server lesbar ist.
Es hat sich jedoch als günstig erwiesen bei Webprojekten die Datei und alle anderen Datein, die zur API-Konfiguration gehören, im ordner "/api/" unterhalb des eigentlichen Webprojektes anzuordnen. Die Quellen des Frontends und der API können somit in ein Mono-Repo eingecheckt werden.
Es hat sich jedoch als günstig erwiesen bei Webprojekten die Datei und alle anderen Datein, die zur API-Konfiguration gehören, im ordner [api/](./ordnerstruktur.md) unterhalb des eigentlichen Webprojektes anzuordnen. Die Quellen des Frontends und der API können somit in ein Mono-Repo eingecheckt werden.
## Aufbau

83
docs/projektkonfig/fields.md
View File

@ -1,8 +1,8 @@
# fields
Felder im tibi-server müssen einen bestimmten Datentyp haben. Über die Admin-UI können die Felder über Widgets in unterschiedlichen Ausprägungen dargestellt werden (view-Widgets), bzw. dem Benutzer eine Eingabe abverlangen (input-Widgets).
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 der Admin-UI mitteilt, wie es dieses Feld für Ausgabe und Eingabe behandel soll.
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:
@ -10,15 +10,15 @@ Zunächst folgt der grundlegende Aufbau des Feld-Objektes:
## validator Objekt
Der Validator wird tibi-server seitig genutzt um die Daten zu validieren. Da das "validator" Objekt der Admin-UI ebenso zur Verfügung steht, kann vorab eine client-seitige Validierung zusaätzlich durchgeführt werden.
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 |
| `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
@ -26,11 +26,11 @@ 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. |
| `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 Onliner wie `new Date($this) > new Date()` meist ausreichend. Für komplexere Prüfungen ist eine sich selbst ausführende Funktion aber oft geeigneter, wie z.B.
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() {
@ -53,20 +53,20 @@ eval: |
})()
```
Wie im obigen Beispiel zu sehen, gibt es spezielle Variablen die im Javascript zur Verfügung stehen. Nicht alle Variablen stehen server- und clientseitig (Admin-UI) zur Verfügung. Eine ensprechende Ausnahmebehandlung ist daher nötig.
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 | serverseitig | Admin-UI | Bedeutung |
| 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/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/null | X | TODO | Das aktuelle Auth-Objekt des eingeloggten Benutzers, siehe Hooks `context.user.auth()` |
| context | object | X | - | Das serverseitige context-Objekt, siehe Hooks |
| `$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
@ -159,60 +159,69 @@ plah
## dependsOn und defaultValue Kontext
TODO
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:
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 input-Element vom type="text".
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 input-Element, allerdings vom type="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/false, wird über den Typ "boolean" definiert und standardmäßig als Checkbox dargestellt.
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.
`"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.
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.
Für `"string[]` Arrays ist die Angabe des Widgets zwingend notwendig.
### number[]
Auch für number-Arrays wird die Widget-Angabe erwartet.
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"` 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.
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.
Felder vom Typ `"any"` können beliebige Daten aufnehmen. Die Validierung schlägt auf Basis der Typ-Validierung hier nie fehl.
## Admin-UI Widgets
## Widgets
TODO
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
### richText
### number
### checkbox
@ -223,6 +232,8 @@ TODO
### datetime
### richText
### file
### image

16
docs/projektkonfig/ordnerstruktur.md
View File

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

6
docs/servergrundlagen/entitaeten.md
View File

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