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

zwischenstand

Browse Source
This commit is contained in:
Robin Grenzdörfer
2024-02-13 16:36:09 +00:00
parent 0b4a474180
commit 49e55a90f7
173 changed files with 15832 additions and 1359 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/md/projektkonfig/api-ordner.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

3
docs/md/projektkonfig/assets.md Normal file
View File

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

17
docs/md/projektkonfig/collections.md Normal file
View File

@@ -0,0 +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](./config.yml.md) eingebunden werden.
## Grundlegender Aufbau
Eine solche Datei hat folgenden Aufbau:
!!!include(../api/collections/medialib.yml)!!!
### siehe
- [fields](./collections/fields.md)
- [indexes](./collections/indexes.md)
- [hooks](./collections/hooks.md)
- [imageFilter](./collections/imageFilter.md)
- [meta](./collections/meta.md)

BIN
docs/md/projektkonfig/collections/dependsOn.webm Normal file
View File

Binary file not shown.

295
docs/md/projektkonfig/collections/fields.md Normal file
View File

@@ -0,0 +1,295 @@
# 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:
```yaml
# Der Name des Feldes wird in der Datenbank zum Objekt ebenso
# wie in der Ein- und Ausgabe über die API verwendet.
name: date
# Über "type" wird der Datentyp in der Datenbank festgelegt.
# Mögliche Typen sind weiter unten aufgelistet.
type: date
# Direkt am Feld kann eine Index-Definition erfolgen.
# Folgende mögliche Werte können ihn die Liste aufgenommen werden:
# "single" - Standard-Index für diese Feld
# "unique" - Das Feld muss einen eindeutigen Wert haben
# "text" - Alle "text"-Indexanganben aller Felder werden zu einem
# gemeinsamen Volltext-Index kombiniert
#
# Die Angabe des Volltextindex ist besser unter "collections.X.indexes"
# vorzunehmen.
index:
- single
# Jede Datenübertragung an des Server wird validiert, d.h. es werden
# keine Datentypen angenommen, die nicht zu "type" passen.
# Darüber hinaus kann via "validator" eine zusätzliche Validierung
# vorgenommen werden.
# Dazu gibt es ein extra Kapitel.
validator:
required: true
eval: new Date($this) > new Date()
# Und natürlich gibt es auch hier ein "meta" Objekt zur Steuerung
# des tibi-admin.
meta:
# Das "label" des Feldes wird als Label vor dem Widget verwendet.
label:
de: Titel
en: title
# Abgelkeitet vom "type" gibt es Standard-Widgets. für spezielle
# Aufgaben stehen aber eine Hand voll Widgets bereit, die später
# beschrieben werden.
widget: date
# Standardwerte für neue Enträge können entweder direkt angegeben
# werden oder via Javascript client-seitig generiert werden.
# In den Kontext injizierte Variablen werden später beschrieben.
defaultValue:
# Das Ergebnis von "eval" wird hier als Standardwert verwendet.
# (hier das aktuelle Datum)
eval: new Date()
# Sollen Felder abhängig von bestimmten Bedingungen ein- oder
# ausgeblendet werden, geschieht das über Anweisungen in "dependsOn".
dependsOn:
# Das Feld wird nur eingeblendet wenn der Wert von "type"
# (auf gleicher Ebene wie das Feld "date" selbst)
# gleich "news" ist.
eval: $parent?.type == "news"
```
## validator Objekt
<video width="100%" controls muted autoplay loop>
<source src="validator.webm" type="video/webm">
</video>
Wie im Beispiel von **fields/date.yml** unter `validator` zu sehen ist, wird dort ein Datum nach dem aktuellen erwartet. Wie der Validator sich auf die UI auswirkt, ist im obigen Video zu sehen.
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 Validator 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)
## dependsOn
<video width="100%" controls muted autoplay loop>
<source src="dependsOn.webm" type="video/webm">
</video>
Obige Darstellung wie im Video wird beispielsweise durch folgende Feld-Konfiguration erreicht:
```yaml
# in einer Kollektions-Konfiguration
fields:
- name: type
type: string
meta:
label:
de: Typ
en: Type
widget: select
choices:
- name:
de: Standardseite
en: Standard page
id: page
- name:
de: News
en: News
id: news
- name: title
type: string
meta:
label:
de: Titel
en: Title
- name: date
type: date
meta:
label:
de: Titel
en: title
widget: date
defaultValue:
eval: new Date()
dependsOn:
eval: $parent?.type == "news"
```
`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`.
## containerProps
Um Felder auf breiten Bildschirmen eine schmalere Breite zu geben, wird das containerProps Attribut empfohlen. Es hat ein class Attribut, welches klassen ins HTML injiziert. Es gibt außerdem noch das Layout attribut mit breakBefore und breakAfter, welche dafür sorgen, dass vorher bzw. nachher keine weiteren HTML Elemente platz finden. Hier ist des weiteren das size Objekt drin, welches 3 attribute hat. Die attribute sollten col-1 bis col-12 beeinhalten, diese klassen werden ins html injiziert, können also dem zufolge auch misbraucht werden. Die klassen bei den attributen werden bei unterschiedlichen Bildschirmbreiten aktiv.
```yaml
containerProps:
#optional class prop
layout:
breakBefore: false
breakAfter: false
size:
default: "col-8"
small: "col-12"
large: "col-4"
```
## inputProps
Wenn man das Input element direkt bearbeiten möchte (Bspw. readonly oder ähnliches), so kann man diese hier als Objekt übergeben:
## hide
möchte man, dass ein bestimmtes Feld nicht im TibiAdmin sichtbar ist, so muss man die property hide auf true setzen.
```yaml
inputProps: { readonly: true, placeholder: { de: "Wert wird automatisch gesetzt", en: "Value is set automatically" } }
```
## direction
Für type Object[] gibt es im Meta objekt das direction attribut, dies kann entweder:
- `horizontal`: flex-direction: row
oder
- `vertical`: flex-direction: column
annehmen.
## metaElements
Möchte man bestimmte Elemente über das Zahnrad greifbar machen (bei type: Object[]), so kann man dies über dieses Attribut tun. Es ist entweder über eine Liste, oder über tablist möglich.
!!!include(../api/collections/fields/info.yml)!!!
## folding
Das folding Objekt ist ebenfalls ein Teil im Meta object und dient dazu, type ObjectArray einen Wert in den Header im HTML einzuschreiben (von den einzelnen Objekten). Es wird vorallem dazu genutzt, die Rows bzw. Columns der Website rein zu rendern, um praktisch ein direktes Prview zu haben. Ebenfalls gibt es das force attribut, welches dafür sorgt, dass die objekte IMMER geöffnet sind und man sie nicht schließen kann. Sinnvoll für Rows. die Generelle struktur verdeutlicht folgendes Code Beispiel:
```yaml
folding:
force: false
previewUnfolded:
raw: true
eval: |
//js
(() => {
return $this?.title ? "<h2 style=\"\">" + $this.title + "</h2>" : ""
})()
//!js
previewFolded:
eval: |
//js
(async () => {
const { getRenderedElement, Row } = await import($projectBase + "_/assets/dist/admin.mjs")
const container = getRenderedElement(Row, {
props: {
row: Object.assign({}, $this),
contentId: $?.id,
apiBaseURL: $projectBase,
},
addCss: [
$projectBase + "_/assets/dist/index.css",
$projectBase + "_/assets/dist/admin.css",
],
})
let style = "max-width: 1220px;"
container.style = style
return container
})()
//!js
```
Hierbei ist raw dafür da, das ganze als HTML direkt zu rendern, wenn es true ist. Der prefiewFolded bereich rendert letzten endes die Seite selbst, für diese Funktionallität ist mehreres notwendig.
- `Row und Column Komponenten`: Dies sind letzenendes jene komponenten die gerendert werden, daher muss man sie natürlich auch bereits programmiert haben.
- `admin.ts file`: Dieses file wird im src Folder platziert und durch ES-Build über den oben genutzen Pfad verfügbar gemacht. Hier ist ein Beispiel:
```ts
import Row from "./components/Row.svelte"
import Col from "./components/Col.svelte"
function getRenderedElement(component, options?: { props: { [key: string]: any }; addCss?: string[] }) {
const el = document.createElement("div")
el.attachShadow({ mode: "open" })
const target = document.createElement("body")
el.shadowRoot.appendChild(target)
options?.addCss?.forEach((css) => {
const link = document.createElement("link")
link.rel = "stylesheet"
link.href = css
link.type = "text/css"
el.shadowRoot.appendChild(link)
})
new component({
target: target,
props: options?.props,
})
return el
}
export { getRenderedElement, Row, Col }
```
Das props Attribut nimmt ein Objekt entgegen, welches als keys die namen hat, wie in der svelte Komponente über export exportiert wurde. Die Komponenten werden in eine Shadow Dom geladen, um sie seperat vom restlichen code halten zu können.

43
docs/md/projektkonfig/collections/fields/datentypen.md Normal file
View File

@@ -0,0 +1,43 @@
# Datentypen
Via `type` wird der Datentyp des Feldes definiert. Diese Angaben sind für den Tibi Server relevant. 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.

BIN
docs/md/projektkonfig/collections/fields/defaultArray.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs/md/projektkonfig/collections/fields/foreign.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 32 KiB

131
docs/md/projektkonfig/collections/fields/widgets.md Normal file
View File

@@ -0,0 +1,131 @@
# Widgets
Die Verwendung von Widgets innerhalb der Anwendung tibi-admin dient zur Handhabung von Dateninputs und -outputs. Das genutzte Widget wird über das meta.widget Feld in der Konfiguration spezifiziert. Dabei wird der Name des Widgets als Textzeichenkette (String) angegeben.
Es ist zu beachten, dass nicht jedes Widget für jeden Datentyp geeignet ist. Im Weiteren werden die kompatiblen Datentypen für jedes Widget aufgeführt. Zusätzlich werden spezielle Konfigurationsmöglichkeiten für jedes Widget erläutert.
## Texteingabefeld-Widgets: string / text / input
Diese Bezeichnungen stehen alle für dasselbe Widget. Es handelt sich hierbei um ein Texteingabefeld. Dieses Widget wird für den Datentyp String verwendet. Sollte ein größeres Textfeld (Textarea) anstatt eines einfachen Eingabefeldes (Input) gewünscht sein, so kann dies erreicht werden, indem das Attribut multiline im inputProps Objekt auf true gesetzt wird.
!!!include(../api/collections/fields/pageTitle.yml)!!!
## Numerische Eingabefeld-Widgets: number / int / integer / float / double
Diese unterschiedlichen Bezeichnungen stehen alle für dasselbe Widget. Hierbei handelt es sich um ein Eingabefeld für Zahlen. Es wird für den Datentyp Number verwendet.
!!!include(../api/collections/fields/manualSort.yml)!!!
## Auswahl-Widgets: boolean / bool / check / switch / checkbox
Diese verschiedenen Bezeichnungen repräsentieren dasselbe Widget. Dieses Widget wird in Form einer Auswahlbox (Checkbox) dargestellt und wird für den Datentyp Boolean verwendet.
!!!include(../api/collections/fields/active.yml)!!!
## Auswahl-Widgets für mehrere Optionen: select / selectArray
Diese beiden Widgets sind im Prinzip das Gleiche, nur mit unterschiedlichen Namen. Intern wird die Unterscheidung zwischen Mehrfachauswahl und einfacher Auswahl anhand des Datentyps getroffen. Bei Datentypen mit einem "[]" am Ende wird die Mehrfachauswahl verwendet. Der Einsatz von selectArray ist für String-Arrays vorgesehen, select für einzelne Strings. Aktuell sind nur Strings möglich, da das Element alle Werte zu Strings konvertiert. Anpassungen sind jedoch bei Bedarf möglich. Es ist wichtig zu beachten, dass das name-Attribut den visuell dargestellten Wert darstellt, während die id den gespeicherten Wert repräsentiert. Wenn choices als Objekt angegeben wird, wird eine Anfrage an den spezifizierten Endpunkt mit den angegebenen Parametern gesendet und das gemappte name-Attribut davon angezeigt. Die id der ausgewählten Elemente wird intern als String gespeichert. Weiterhin ist die Angabe von chipStyle: (style) möglich. Dieser wird als Stil in das Element gerendert und ermöglicht zum Beispiel die visuelle Darstellung von Flaggen.
!!!include(../api/collections/fields/contentType.yml)!!!
## Bezug zu anderen Datenbankeinträgen: foreignKey
Dieses Widget wird verwendet, um eine Referenz zu einem anderen Datenbankeintrag herzustellen. Neben der Angabe von widget: foreignKey gibt es das foreign Attribut, welches die referenzierte Sammlung (collection) angibt. Zudem gibt es ein id Feld, welches die spezifische id für die Sicherheitsüberprüfung angibt. Wird hier "id" angegeben, wird es automatisch auf \_id gemappt, da dies der Name des ID-Feldes in MongoDB ist. Des Weiteren gibt es eine subNavigation, die die Struktur des Modals spezifiziert und neben dem Üblichen a) modal heißen sollte (Konvention) und b) einen defaultCallback haben sollte, der ausgelöst wird, wenn auf den Eintrag geklickt wird. Für die Auswahl gibt es auf dem Fensterobjekt (window Objekt) eine selectEntry Methode, die den ForeignEntry auswählt. Es gibt auch ein sort Attribut, falls die Auswahlmöglichkeiten sortiert werden sollen. Dieses wird einfach an die Anfrage angehängt. Wenn die zurückgegebenen Felder eingeschränkt werden sollen, kann eine Projektion (projection) für die Sammlung spezifiziert werden. Schließlich gibt es das render Attribut, welches ein Objekt ist und ein eval Feld enthält. Hier kann man unter anderem auf $foreignEntry und somit auf alle Werte der ausgewählten Projektion zugreifen. Der zurückgegebene Wert wird schließlich gerendert. Wenn das HTML roh gerendert werden soll, kann das raw Attribut auf true gesetzt werden.
!!!include(../api/collections/fields/images.yml)!!!
```yml
meta: #... in medialib collection
subNavigation:
- name: modalForeign # Name des Eingabefelds oder der Ansicht.
defaultSort: # Standard-Sortierkriterien, die angewendet werden, wenn keine anderen Sortierkriterien spezifiziert sind.
field: "path" # Standardmäßig wird nach dem "path"-Feld sortiert.
order: "ASC" # Standardmäßig wird in aufsteigender Reihenfolge (ASC) sortiert.
views: # Liste der Ansichten, die in diesem Feld angezeigt werden können.
- type: table # Es wird eine Tabellenansicht verwendet.
mediaQuery: "(min-width: 0px)" # Die Tabellenansicht wird nur angezeigt, wenn die Bildschirmbreite mindestens 0px beträgt.
columns: # Liste der Spalten, die in der Tabelle angezeigt werden.
- source: file
defaultCallback: # Standard-Callback-Funktion, die ausgeführt wird, wenn keine andere spezifiziert ist.
eval: | # Der Code wird als JavaScript evaluiert.
//js
(entry) => {
parent.selectEntry(entry)
}
//!js
```
Setzt man defaultCollectionViews auf true, so könnte das ergebnis wie folgt aussehen:
![defaultCollectionViews auf ture](foreign.png)
## Datums-Widgets: date / dateTime
Diese beiden Widgets können für den Typ "date" verwendet werden. date erzeugt ein Widget (nur das Datum), während dateTime ein Widget erzeugt (Datum und Uhrzeit).
!!!include(../api/collections/fields/from.yml)!!!
## Textbearbeitungs-Widgets: richtext / html
Diese beiden Bezeichnungen stehen für dasselbe Widget. Es handelt sich um ein Textfeld (Textarea) mit erweiterten Bearbeitungsmöglichkeiten (ähnlich wie in Word), wobei die Eingabe als HTML in einen String geladen wird. Das HTML kann auch manuell angepasst werden, indem die "source" Checkbox aktiviert wird.
!!!include(../api/collections/fields/text.yml)!!!
## Datei-Upload-Widgets: file / image / mediaLibraryFile
Diese verschiedenen Bezeichnungen stehen alle für das gleiche Widget. Es wird für den Datentyp File verwendet.
!!!include(../api/collections/fields/file.yml)!!!
## Mehrfachauswahl-Widgets: checkboxArray
Hierbei handelt es sich um eine Reihe von Auswahlboxen (Checkboxen). Jede einzelne Auswahlbox spiegelt das Array choices wider. Dies entspricht genau dem, was auch im selectArray geschieht, nur dass es hier anders dargestellt wird.
!!!include(../api/collections/fields/excludedDays.yml)!!!
## Eingabe mit Vorschlägen: chipArray
Dieses Widget hat eine ähnliche Funktion wie select, wird jedoch visuell anders dargestellt. Es bietet ein Eingabefeld, in dem nur Elemente akzeptiert werden, wenn ein Objekt im choices Array den gleichen name Wert wie das Eingabeelement hat. Darüber hinaus kann man im meta Objekt autocomplete auf true setzen, um die Autovervollständigung zu aktivieren. Dadurch werden dem Benutzer die möglichen Einträge angezeigt und können direkt ausgewählt werden, was die Benutzerfreundlichkeit erhöht.
```yml
name: tags # Name des Eingabefelds.
type: string[] # Datentyp des Eingabefelds.
meta:
label: { de: "Tags", en: "Tags" } # Feldlabel.
widget: chipArray # Verwendetes Widget.
choices: # Auswahlmöglichkeiten.
- name: "Tech" # Anzeigename der Auswahl.
id: "tech" # Wert der Auswahl.
- name: "Wissenschaft" # Anzeigename der Auswahl.
id: "science" # Wert der Auswahl.
autocomplete: true # Option für Autovervollständigung.
```
## object / objectArray / object[] / containerLessObjectArray / containerLessObject
Dieses Widget erfordert die weitere Angabe von subFields, die außerhalb des meta Objekts spezifiziert werden müssen. Hier werden die Felder angegeben, die in diesem Objekt enthalten sein sollen. containerLess bedeutet, dass das Objekt in der UI nicht dargestellt wird, und nur der Inhalt ausgegeben. Dadurch wird übermäßiges verschachteln unterbunden.
!!!include(../api/collections/fieldLists/formular/checkboxGroup.yml)!!!
## grid
Für Datentyp object[], dient als übersichtliche object[] alternative, speziell für pagebuilder entwickelt.
!!!include(../api/collections/fields/rows.yml)!!!
## jsonField
Wird für Daten genutzt, wo man die Struktur nicht absehen kann.
!!!include(../api/collections/fields/form.yml)!!!
## tabs
Dieses Widget hat im Prinzip die gleiche Funktion wie dasjenige in der Collection Meta-Konfiguration, ist jedoch etwas anders strukturiert. Ähnlich wie beim object Widget werden subFields verwendet, wobei das label von jedem subField der jeweilige Tab-Name ist. Würde man type auf number setzen, so hätte man in diesem Fall einfach einen Tab mit dem Namen "xyz" und ein number Feld im Tab mit dem gleichen Namen. Sinnvoller ist es natürlich, type auf object zu setzen, um mehrere Felder in einen Tab zu packen.
```yml
type: object
name: formular
meta:
label:
de: Formular
en: Form
widget: jsonField
```
# useDefaultArray
Wenn ein belibiger Datentyp in einem Array gefordert ist, so kann man jedes beliebige Widget dafür nutzten, indem man useDefaultArray: true benutzt. Damit kann jedes widget in das defaultArray widget gepackt werden. Wird Object[] in kombination mit useDefaultArray verwendet, so wird die einfache Objektdarstellung in diese darstellung implementiert.
![useDefaultArray auf true](defaultArray.png)
!!!include(../api/collections/fields/emailCC.yml)!!!

112
docs/md/projektkonfig/collections/hooks.md Normal file
View File

@@ -0,0 +1,112 @@
# hooks
Hooks in Tibi sind spezielle Funktionen, die bestimmte Teile der HTTP-Anfragen und -Antworten manipulieren können. Sie erlauben Ihnen, den Datenfluss und die Abläufe zu bestimmten Zeitpunkten im Lebenszyklus einer HTTP-Anfrage zu beeinflussen.
Jeder Hook ist einer bestimmten HTTP-Methode (z.B. GET, POST, PUT, DELETE) und einem bestimmten Schritt in diesem Prozess zugeordnet. Die verfügbaren Schritte variieren je nach Methode und können beinhalten:
- read (GET)
- return (GET, POST, PUT, DELETE)
- bind (POST, PUT)
- validate (POST, PUT)
- create (POST)
- update (PUT)
- delete (DELETE)
Jeder dieser Schritte wird an einem spezifischen Punkt während der Verarbeitung einer HTTP-Anfrage oder -Antwort ausgeführt. Die genaue Reihenfolge und das Verhalten der Hooks ist in dem betrag zur Collection definiert.
## Hook Implementierung
Jeder Hook ist in einer separaten JavaScript-Datei implementiert, die im hooks-Ordner Ihres Projekts gespeichert ist. Der Pfad zu dieser Datei wird in der jeweiligen collection yml Datei angegeben.
Ein Hook ist eine Funktion, die eine context-Variable zur Verfügung hat, welche Informationen und Methoden für die aktuelle Anfrage bereitstellt. Der Rückgabewert dieser Funktion wird verwendet, um die Verarbeitung der Anfrage oder Antwort zu beeinflussen.
Zwei spezielle Typen, `HookResponse` und `HookException`, werden in Hooks verwendet, um Daten zu manipulieren und Fehler zu signalisieren.
### HookResponse
Die HookResponse ist das Objekt, das von einem Hook zurückgegeben wird. Es kann verwendet werden, um Daten zu manipulieren, die in die Datenbank geschrieben oder an den Benutzer zurückgegeben werden.
Es beinhaltet:
- `data`: Daten, die in die Datenbank geschrieben werden. Sie können diese Daten im Hook ändern, bevor sie in die Datenbank geschrieben werden.
- `results`: Daten, die an den Benutzer zurückgegeben werden. Sie können diese Daten im Hook ändern, bevor sie an den Benutzer zurückgegeben werden. (return hook)
### HookException
Eine HookException ist ein Fehler, der in einem Hook geworfen werden kann. Sie können eine HookException verwenden, um einen Fehler zu signalisieren und die Verarbeitung der Anfrage oder Antwort zu stoppen. Er kann aber auch verwendet werden, um einen 200er zu werfen und zu verhindern, dass irgendetwas in die Datenbank geschrieben wird. Dies ist bei einer "actions" collection vom vorteil.
Eine HookException kann folgende Eigenschaften haben:
- `status`:
HTTP-Statuscode des Fehlers.
- `html`:
HTML-Nachricht des Fehlers.
- `message`:
Textnachricht des Fehlers.
- `bytes`:
Binäre Daten des Fehlers.
- `json`:
JSON-Daten des Fehlers.
- `file`:
Dateipfad der Fehlermeldung.
- `log`:
Wenn true, wird der Fehler im Serverprotokoll aufgezeichnet.
### Hook Beispiel
Hier ist ein Beispiel für einen Hook, der die GET-Methode bearbeitet:
```js
;(function () {
/** @type {HookResponse}*/ // @ts-ignore
let hookResponse
let request = context.request()
if (request.query("rateIt")) {
let orderNumber
orderNumber = Number(request.query("orderNumber"))
if (isNaN(orderNumber))
throw {
status: 400,
message: "Invalid order number.",
}
/** @type {Order} */ // @ts-ignore
let order = context.db.find("order", {
filter: {
sequence: orderNumber,
},
})[0]
if (!order)
throw {
status: 400,
message: "No entry with this order number.",
}
if (order.deliveryAddress.postcode != request.query("postalcode"))
throw {
status: 403,
message: "Error",
}
hookResponse = {
filter: {
orderId: order.id,
},
}
return hookResponse
}
})()
```
In diesem Beispiel wird zuerst die Anfrage analysiert und eine Bedingung überprüft. Wenn die Bedingung erfüllt ist, wird ein bestimmtes Element in der Datenbank gesucht. Wenn das Element gefunden wird und bestimmte Kriterien erfüllt, wird ein HookResponse-Objekt erstellt und zurückgegeben. Wenn während des Prozesses Fehler auftreten, werden entsprechende HookException-Objekte geworfen.
Hier ist ein beispiel für einen Posthook, welcher ein dynamisches formular validiert (Post create):
!!!include(../api/hooks/forms/post_create.js)!!!
Hier ist ein beispiel für einen Posthook, welcher ein dynamisches formular abschickt (Post return):
!!!include(../api/hooks/forms/post_return.js)!!!

29
docs/md/projektkonfig/collections/imageFilter.md Normal file
View File

@@ -0,0 +1,29 @@
# 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/fields/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 |

30
docs/md/projektkonfig/collections/indexes.md Normal file
View File

@@ -0,0 +1,30 @@
# indexes Liste
Die indexes-Anweisung in der Konfigurationsdatei einer Sammlung (collection.yml) ist ein Array von Indexdefinitionen. Indizes werden in Datenbanken verwendet, um die Suchleistung zu optimieren. Indem Sie die richtigen Indizes definieren, können Sie die Effizienz Ihrer Anwendung verbessern. Es ist NICHT MÖGLICH einen gesetzten Index über die yml Datei wieder zu entfernen, hierfür muss man direkt in die Datenbank gehen.
Jede Indexdefinition ist ein Objekt mit bestimmten Eigenschaften:
- `name`:
Ein eindeutiger Name für den Index. Es ist optional, wird jedoch empfohlen, um den Index später leicht identifizieren zu können.
- `key`:
Bestimmt, auf welche Felder der Index angewendet werden soll. Dies kann ein einfacher String sein, wenn der Index nur ein Feld umfasst, oder ein Array von Strings, wenn der Index mehrere Felder umfasst.
Zum Beispiel key: ["$text:$**"] definiert einen Volltextindex über alle Felder. Der spezielle Operator $text wird verwendet, um einen Volltextindex zu erstellen, und der Operator $\*\* bezeichnet alle Felder in der Sammlung.
Eine andere mögliche Indexdefinition könnte so aussehen: key: ["file.type"]. Dies würde einen Index auf dem Feld type innerhalb des Unterobjekts file erstellen.
- `unique`:
Wenn auf true gesetzt, erzwingt dies, dass der Index eindeutige Werte enthält. Wenn Sie versuchen, einen Eintrag mit einem bereits indizierten Wert hinzuzufügen, wird ein Fehler ausgelöst und der Vorgang abgebrochen.
- `background`:
Wenn auf true gesetzt, erstellt die Datenbank den Index im Hintergrund, um die Leistungsauswirkungen auf andere Operationen zu minimieren.
- `defaultLanguage`:
Wird verwendet, um die Sprache für Textindizes festzulegen. Dies ist wichtig für die Volltextsuche, da verschiedene Sprachen unterschiedliche Tokenisierungs- und Stemmungsregeln haben.
Ein Beispiel für die Verwendung von Indizes in der Sammlungskonfigurationsdatei könnte so aussehen:
!!!include(../api/collections/fields/textIndex.yml)!!!
In diesem Beispiel wird ein Textindex namens textindex erstellt, der alle Felder der Sammlung abdeckt. Der Index wird im Hintergrund erstellt und verwendet Deutsch als Standardtextsprache.

76
docs/md/projektkonfig/collections/meta.md Normal file
View File

@@ -0,0 +1,76 @@
# 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.
Möchte man, dass in der view selection Navbar vor den View namen bestimme Icons angezeigt werden, so kann man diese einfach per muiIcon im jeweiligen View Objekt angeben.
Folgende möglche Einträge für `views` gibt es derzeit:
### simpleList
!!!include(../api/collections/fields/medialibSimpleList.yml)!!!
### table
!!!include(../api/collections/fields/medialibTable.yml)!!!
### cardList
!!!include(../api/collections/fields/medialibCardList.yml)!!!
## quickEdit
!!!include(../api/collections/fields/quickEditMedialib.yml)!!!
### dashboardSimpleList
Fürs dashboard type: table
```yml
type: dashboardSimpleList
mediaQuery: "(max-width: 600px)"
primaryText: email
secondaryText: subject
```
### dashboardTable
Fürs dashboard type: table
```yml
type: dashboardTable
mediaQuery: "(min-width: 600px)"
columns:
- subject
- file
- file
- subject
- file
```
## 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.
## multiupload
Der mutliupload kann bei jedem view type verwendet werden. Über $file kann man in eval auf das aktuelle file Objekt zugreifen. Hier ist eine Beispielscollection, welchen diesen verwendet.
!!!include(../api/collections/medialib.yml)!!!
## backups
im meta Objekt einer collection können backups für diese collection konfiguriert werden. Die backups werden in der Datenbank gespeichert und können über das tibi-admin in der selben collection angewandt werden. Wird ein collectoneintrag gelöscht, kann man diesen über den gelöschte einträge checkbox wiederherstellen.
folgende collection ist ein beispiel für eine backup collection sowie die aktvierung der backupfunktion in einer "normalen" collection (Im Meta objekt...).
!!!include(../api/collections/fields/backup.yml)!!!
!!!include(../api/collections/backups.yml)!!!

BIN
docs/md/projektkonfig/collections/validator.webm Normal file
View File

Binary file not shown.

34
docs/md/projektkonfig/config.yml.md Normal file
View File

@@ -0,0 +1,34 @@
# config.yml
Die Datei **config.yml** ist der Einstieg in die API-Konfiguration eines Projekts. Die Datei kann sich an einem beliebigen Ort befinden. Die einzige Bedingung ist, dass sie durch den tibi-server lesbar ist.
Es hat sich jedoch als günstig erwiesen bei Webprojekten die Datei und alle anderen Datein, die zur API-Konfiguration gehören, im ordner [api/](./ordnerstruktur.md) unterhalb des eigentlichen Webprojektes anzuordnen. Die Quellen des Frontends und der API können somit in ein Mono-Repo eingecheckt werden.
## Aufbau
!!!include(../api/config.yml)!!!
Der Namespace legt die eigentliche Projektbezeichnung und den Datenbankkontext fest.
Er sollte nach Projektinitialisierung auf dem tibi-server nicht mehr angepasst werden.
In den Projekteinstellungen im tibi-server kann der Namespace durch einen Datenbankeintrag
Überschrieben werden.
Über die Bezeichnung des Namespace plus einen Prefix der in der globalen Server-Konfig
hinterlegt ist, definiert sich der Datenbank-Name innerhalb der MongoDB.
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.
Das imageUrl objekt definiert den Pfad zu einer Bilddatei die als Projektbild im tibi-admin verwendet wird
"collections" ist eine Auflistung von Kollektions-Konfigurationen.
Hier bietet sich eine Auslagerung und Einbindung via YAML-Tag "!include" an.
Unter "jobs" können Jobs definiert werden, die regelmäßig ausgeführt werden sollen.
Werden Dateien innerhalb vom tibi-admin benötigt, bietet es sich an diese über
"assets"-Pfade erreichbar zu machen
### siehe
- [dashboard](./dashboard.md)
- [collections](./collections.md)
- [jobs](./jobs.md)
- [assets](./assets.md)

BIN
docs/md/projektkonfig/dashboard.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 109 KiB

13
docs/md/projektkonfig/jobs.md Normal file
View File

@@ -0,0 +1,13 @@
# 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/lighthouse.yml)!!!
Die Möglichkeiten innerhalb der Javascript-Datei werden im Kapitel [Javascript Kontext](./../server-javascript-kontext/allgemeines.md) beschrieben. Ein Beispiel für eine solche Datei wäre die folgende:
!!!include(../api/jobs/lighthouse.js)!!!

65
docs/md/projektkonfig/ordnerstruktur.md Normal file
View File

@@ -0,0 +1,65 @@
# Ordnerstruktur
Als Konvention für neue Projekte hat sich folgende Ordnerstruktur etabliert:
![Ordnerstruktur](api-ordner.png)
Die Aufteilung der YAML-Konfiguration ist durch den YAML-Tag `!include` möglich. Genaueres dazu wird auf den nachfolgenden Seiten beschrieben.
## /api
Der Einstiegsordner in die Konfiguration ist frei wählbar. "/api" innerhalb des Projektrepositories hat sich jedoch bewährt.
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.
### JSON-Schema
Das JSON-Schema ist in die package.json einzubinden via:
```json
...
"devDependencies": {
...,
"tibi-types": "https://gitbase.de/cms/tibi-types.git"
},
...
```
Die im Projekt liegende VSCode-Konfig sollte dementsprechend ergänzt werden:
```json
...
"yaml.schemas": {
"node_modules/tibi-types/schemas/api-config/config.json": "api/config.y*ml",
"node_modules/tibi-types/schemas/api-config/collection.json": "api/collections/*.y*ml",
"node_modules/tibi-types/schemas/api-config/field.json": "api/collections/fields/*.y*ml",
"node_modules/tibi-types/schemas/api-config/fieldArray.json": "api/collections/fieldLists/*.y*ml"
},
"yaml.customTags": ["!include scalar"],
...
```
Sollte Yarn2 verwendet werden ist die Verlinkung von **node_modules** nötig. Dazu ist folgendes in der **.yarnrc.yml** einzutragen:
```yaml
...
nodeLinker: node-modules
```
## /api/collections
Bei Aufteilung der Kollektionskonfigurationen in einzelne Dateien, sollten diese in diesem Ordner gespeichert werden. Für jede Kollektion sollte eine eigene Datei verwendet werden, hier im Beispiel [api/collections/democol.yml](./collections.md).
### /api/collections/fields
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/](./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
Ist es nötig im Projekt Templates zu rendern (z.B. für den Email-Versand), sind diese im Ordner **templates** gut aufgehoben.