docs in sub package
This commit is contained in:
BIN
docs/md/projektkonfig/collections/dependsOn.webm
Normal file
BIN
docs/md/projektkonfig/collections/dependsOn.webm
Normal file
Binary file not shown.
120
docs/md/projektkonfig/collections/fields.md
Normal file
120
docs/md/projektkonfig/collections/fields.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# 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
|
||||
|
||||
<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 [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
|
||||
|
||||
<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`.
|
||||
44
docs/md/projektkonfig/collections/fields/datentypen.md
Normal file
44
docs/md/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.
|
||||
|
||||
39
docs/md/projektkonfig/collections/fields/widgets.md
Normal file
39
docs/md/projektkonfig/collections/fields/widgets.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# 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
|
||||
|
||||
siehe: [ContentBuilder](./widgets/contentbuilder.md)
|
||||
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,35 @@
|
||||
# contentbuilder
|
||||
|
||||
> Der ContentBuilder ist ein Drittanbieter-Produkt und steht nicht in jeder Lizenz zur Verfügung. Bitte kontaktieren Sie uns, wenn Sie Interesse an diesem Widget haben.
|
||||
|
||||
Für die Gestaltung von HTML-Inhalten ist der ContentBuilder eine einfache und intuitive Lösung. Es sind Layout-Hilfmittel wie Spalten und Zeilen ebenso verfügbar, wie die Möglichkeit Dateien (Bilder, Video, Downloads) direkt in den HTML-Code einzubinden.
|
||||
|
||||
Wie der ContentBuilder an einem Feld konfiguriert wird verdeutlicht folgendes Beispiel:
|
||||
|
||||
!!!include(../api/collections/fields/content.yml)!!!
|
||||
|
||||
## Mediathek Kollektion
|
||||
|
||||
<video width="100%" controls autoplay muted loop>
|
||||
<source src="contentbuilder-medialib.webm" type="video/webm">
|
||||
</video>
|
||||
|
||||
Wie aus der obigen Definition unterhalb von z.B. "imageSelect" zu lesen, bedarf es einer eigenen Kollektion für Bilder und andere Dateien. Diese Kollektion könnte wie folgt aussehen:
|
||||
|
||||
> Die Bedeutung der hier nicht beschriebenen Eigenschaften ist unter [collections](./../../../collections.md) zu finden.
|
||||
|
||||
!!!include(../api/collections/medialib.yml)!!!
|
||||
|
||||
## Module (customTags)
|
||||
|
||||
Die Einbindung des konfigurierten Beispiel-Moduls aus obiger Definition erfolgt im ContentBuilder wie im folgenden Video zu sehen ist:
|
||||
|
||||
<video width="100%" controls autoplay muted loop>
|
||||
<source src="contentbuilder-module.webm" type="video/webm">
|
||||
</video>
|
||||
|
||||
Wie oben schon erwähnt, sind die `placeholder` frei wählbar. Eine HTML5-Schreibweise bietet sich aber sowohl für das Styling, als auch für die spätere Einbindung in ein Frontend an.
|
||||
|
||||
In unserem Beispiel hier wurden zusättzlich zum eigentlichen Modul-Tag noch Attribute (`title` und `description`) definiert. Diese können dann im Frontend das eigentliche Modul beeinflussen.
|
||||
|
||||
Im Frontend könnte ein Modul dann später als "Custom Element" implementiert werden oder es wird ein HTML-Parser verwendet, der die Tags durch eigene Komponenten ersetzt, wie er im Anhang [TODO] zu finden ist.
|
||||
1
docs/md/projektkonfig/collections/hooks.md
Normal file
1
docs/md/projektkonfig/collections/hooks.md
Normal file
@@ -0,0 +1 @@
|
||||
# hooks
|
||||
30
docs/md/projektkonfig/collections/imageFilter.md
Normal file
30
docs/md/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/md/projektkonfig/collections/indexes.md
Normal file
3
docs/md/projektkonfig/collections/indexes.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# indexes Liste
|
||||
|
||||
TODO
|
||||
29
docs/md/projektkonfig/collections/meta.md
Normal file
29
docs/md/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)!!!
|
||||
BIN
docs/md/projektkonfig/collections/validator.webm
Normal file
BIN
docs/md/projektkonfig/collections/validator.webm
Normal file
Binary file not shown.
Reference in New Issue
Block a user