generated from cms/tibi-docs
backend & types
This commit is contained in:
@@ -1,21 +0,0 @@
|
||||
# TibiCMS Dokumentation
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
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 Version des _tibi-admin_ sollte synchron zur _tibi-server_ Version gehalten werden, damit alle Datentypen bedient werden können.
|
||||
@@ -1,9 +0,0 @@
|
||||
{
|
||||
"docs": "md",
|
||||
"markdown": {
|
||||
"plugins": {
|
||||
"code-include": {}
|
||||
}
|
||||
},
|
||||
"css": ["md/docpress.css", "md/github-dark-dimmed.css"]
|
||||
}
|
||||
@@ -1,106 +0,0 @@
|
||||
const path = require('path');
|
||||
const fs = require('fs');
|
||||
|
||||
const INCLUDE_RE = /!{3}\s*include(.+?)!{3}/i;
|
||||
const BRACES_RE = /\((.+?)\)/i;
|
||||
|
||||
const include_plugin = (md, options) => {
|
||||
const defaultOptions = {
|
||||
root: '.',
|
||||
getRootDir: (pluginOptions/*, state, startLine, endLine*/) => pluginOptions.root,
|
||||
includeRe: INCLUDE_RE,
|
||||
throwError: false,
|
||||
bracesAreOptional: false,
|
||||
notFoundMessage: 'File \'{{FILE}}\' not found.',
|
||||
circularMessage: 'Circular reference between \'{{FILE}}\' and \'{{PARENT}}\'.'
|
||||
};
|
||||
|
||||
if (typeof options === 'string') {
|
||||
options = {
|
||||
...defaultOptions,
|
||||
root: options
|
||||
};
|
||||
} else {
|
||||
options = {
|
||||
...defaultOptions,
|
||||
...options
|
||||
};
|
||||
}
|
||||
|
||||
const _replaceIncludeByContent = (src, rootdir, parentFilePath, filesProcessed) => {
|
||||
filesProcessed = filesProcessed ? filesProcessed.slice() : []; // making a copy
|
||||
let cap, filePath, mdSrc, errorMessage;
|
||||
|
||||
// store parent file path to check circular references
|
||||
if (parentFilePath) {
|
||||
filesProcessed.push(parentFilePath);
|
||||
}
|
||||
while ((cap = options.includeRe.exec(src))) {
|
||||
let includePath = cap[1].trim();
|
||||
const sansBracesMatch = BRACES_RE.exec(includePath);
|
||||
|
||||
if (!sansBracesMatch && !options.bracesAreOptional) {
|
||||
errorMessage = `INCLUDE statement '${src.trim()}' MUST have '()' braces around the include path ('${includePath}')`;
|
||||
} else if (sansBracesMatch) {
|
||||
includePath = sansBracesMatch[1].trim();
|
||||
} else if (!/^\s/.test(cap[1])) {
|
||||
// path SHOULD have been preceeded by at least ONE whitespace character!
|
||||
/* eslint max-len: "off" */
|
||||
errorMessage = `INCLUDE statement '${src.trim()}': when not using braces around the path ('${includePath}'), it MUST be preceeded by at least one whitespace character to separate the include keyword and the include path.`;
|
||||
}
|
||||
|
||||
if (!errorMessage) {
|
||||
filePath = path.resolve(rootdir, includePath);
|
||||
|
||||
// check if child file exists or if there is a circular reference
|
||||
if (!fs.existsSync(filePath)) {
|
||||
// child file does not exist
|
||||
errorMessage = options.notFoundMessage.replace('{{FILE}}', filePath);
|
||||
} else if (filesProcessed.indexOf(filePath) !== -1) {
|
||||
// reference would be circular
|
||||
errorMessage = options.circularMessage.replace('{{FILE}}', filePath).replace('{{PARENT}}', parentFilePath);
|
||||
}
|
||||
}
|
||||
|
||||
// check if there were any errors
|
||||
if (errorMessage) {
|
||||
if (options.throwError) {
|
||||
throw new Error(errorMessage);
|
||||
}
|
||||
mdSrc = `\n\n# INCLUDE ERROR: ${errorMessage}\n\n`;
|
||||
} else {
|
||||
// get content of child file
|
||||
mdSrc = fs.readFileSync(filePath, 'utf8');
|
||||
// check if child file also has includes
|
||||
mdSrc = _replaceIncludeByContent(mdSrc, path.dirname(filePath), filePath, filesProcessed);
|
||||
// remove one trailing newline, if it exists: that way, the included content does NOT
|
||||
// automatically terminate the paragraph it is in due to the writer of the included
|
||||
// part having terminated the content with a newline.
|
||||
// However, when that snippet writer terminated with TWO (or more) newlines, these, minus one,
|
||||
// will be merged with the newline after the #include statement, resulting in a 2-NL paragraph
|
||||
// termination.
|
||||
const len = mdSrc.length;
|
||||
if (mdSrc[len - 1] === '\n') {
|
||||
mdSrc = mdSrc.substring(0, len - 1);
|
||||
}
|
||||
}
|
||||
|
||||
const labelStyle = `padding: 0 4px; font-size: 12px; font-weight: bold; color: #ffffff; background: #444444; opacity: .6;`
|
||||
|
||||
const fileLabel = `<div style="position:relative; height: 0px;"><div class="code-file-label" style="position:absolute; top: -10px;${labelStyle}">${includePath}</div></div>\n\n`
|
||||
const fileExt = includePath.replace(/^.+\./, "")
|
||||
|
||||
// replace include by file content
|
||||
src = src.slice(0, cap.index) + fileLabel + "```" + fileExt + "\n" + mdSrc + "\n```" + src.slice(cap.index + cap[0].length, src.length);
|
||||
}
|
||||
return src;
|
||||
};
|
||||
|
||||
const _includeFileParts = (state, startLine, endLine/*, silent*/) => {
|
||||
state.src = _replaceIncludeByContent(state.src, options.getRootDir(options, state, startLine, endLine));
|
||||
};
|
||||
|
||||
md.core.ruler.before('normalize', 'include', _includeFileParts);
|
||||
};
|
||||
|
||||
module.exports = include_plugin;
|
||||
@@ -1,24 +0,0 @@
|
||||
{
|
||||
"name": "markdown-it-code-include",
|
||||
"version": "0.0.0",
|
||||
"description": "A markdown-it plugin to include code blocks.",
|
||||
"main": "./index.js",
|
||||
"scripts": {
|
||||
},
|
||||
"keywords": [
|
||||
"markdown",
|
||||
"markdown-it",
|
||||
"markdown-it-plugin",
|
||||
"code-blocks",
|
||||
"fence"
|
||||
],
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"node-html-parser": "^1.3.1"
|
||||
},
|
||||
"devDependencies": {
|
||||
"markdown-it": "^12.0.0",
|
||||
"markdown-it-testgen": "^0.1.6",
|
||||
"path": "^0.12.7"
|
||||
}
|
||||
}
|
||||
@@ -1,52 +0,0 @@
|
||||
- [TibiCMS](../README.md)
|
||||
- [Begriffe](begriffe.md)
|
||||
- Servergrundlagen
|
||||
|
||||
- [Konfiguration](servergrundlagen/konfiguration.md)
|
||||
- [Entitäten](servergrundlagen/entitaeten.md)
|
||||
- [SSR & htaccess](servergrundlagen/ssr&htaccess.md)
|
||||
|
||||
- RestAPI Endpunkte
|
||||
- [/login](restapi/login.md)
|
||||
- [/user](restapi/user.md)
|
||||
- [/project](restapi/project.md)
|
||||
- [/\_/NS/COLLECTION](restapi/collection.md)
|
||||
- [/_/NS/_/assets/ASSETSNAME](restapi/assets.md)
|
||||
- Projekt Konfiguration
|
||||
- [Ordnerstruktur](projektkonfig/ordnerstruktur.md)
|
||||
- [config.yml](projektkonfig/config.yml.md)
|
||||
- [collections](projektkonfig/collections.md)
|
||||
- [fields](projektkonfig/collections/fields.md)
|
||||
- [Datentypen](projektkonfig/collections/fields/datentypen.md)
|
||||
- [Admin Widgets](projektkonfig/collections/fields/widgets.md)
|
||||
- [· ContentBuilder](projektkonfig/collections/fields/widgets/contentbuilder.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)
|
||||
- [dashboard](projektkonfig/dashboard.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)
|
||||
- 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)
|
||||
- [pdf](server-javascript-kontext/packages/pdf.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)
|
||||
@@ -1,47 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,9 +0,0 @@
|
||||
# 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` |
|
||||
@@ -1,104 +0,0 @@
|
||||
# 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"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,53 +0,0 @@
|
||||
# Begriffe
|
||||
|
||||
## TibiCMS
|
||||
|
||||
Oberbegrff der den gesamten Stack, bestehend aus _tibi-server_ mit *MongoDB\*\* und *tibi-admin\* beschreibt.
|
||||
|
||||
## tibi-server
|
||||
|
||||
Rest-API Server des _TibiCMS_ Stack
|
||||
|
||||
## tibi-admin
|
||||
|
||||
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)
|
||||
|
||||
## project / Projekt
|
||||
|
||||
Projekt innerhalb des _TibiCMS_ welches üblicherweise die Datengrundlage für eine Website im _TibiCMS_ ist
|
||||
|
||||
## collection / Kollektion
|
||||
|
||||
Datensammlung innerhalb eines Projekte (z.B. Newsartikel), in relationalen Datenbanken oft eine Tabelle
|
||||
|
||||
## field / Feld
|
||||
|
||||
Ein Datenfeld innerhalb einer Kollektion mit einem bestimmten Datentyp (z.B. string, number, ...)
|
||||
|
||||
## validator / Validator
|
||||
|
||||
Code oder Anweisung zur Überprüfung der Gültigkeit von Feld-Daten
|
||||
|
||||
## filter / Filter
|
||||
|
||||
Bildfilter zum Verkleinern oder Bearbeiten von Bildern beim Abruf von der API
|
||||
|
||||
## projection / Projektion
|
||||
|
||||
Abbildung der Daten auf ein Subset der Originaldaten
|
||||
|
||||
## hook
|
||||
|
||||
Vorerst nur in Javascript geschriebene Algorithmen, die die sich in die API einklinken um Daten oder Abläufe zu manipulieren
|
||||
|
||||
## user / Benutzer
|
||||
|
||||
Ein Benutzer mit Login innerhalb des _TibiCMS_
|
||||
|
||||
## permission / Berechtigung
|
||||
|
||||
Berechtigung innerhalb eines Projektes, welche einem Benutzer zugeordnet werden kann
|
||||
@@ -1,34 +0,0 @@
|
||||
.title, h1, h2, h3, h4, h5, .link.title.link-index {
|
||||
color: #531414!important;
|
||||
}
|
||||
|
||||
.link.title {
|
||||
color: black!important;
|
||||
}
|
||||
|
||||
.toc-menu .link.-active, .toc-menu .hlink.-active {
|
||||
box-shadow: inset -2px 0 #7c2828!important;
|
||||
}
|
||||
|
||||
ul.heading-list .hlink, ul.heading-list .hlink:visited {
|
||||
color: #414141!important;
|
||||
}
|
||||
|
||||
.menu-toggle:hover, .footer-nav a:hover, .footer-nav a:hover:after, .footer-nav a:hover:before {
|
||||
color: #7c2828!important;
|
||||
}
|
||||
|
||||
.code-file-label {
|
||||
background: #dcd9d9!important;
|
||||
color: #3a0909!important;
|
||||
right: 0px;
|
||||
opacity: 1!important;
|
||||
}
|
||||
|
||||
a {
|
||||
color: #7c2828!important;
|
||||
}
|
||||
|
||||
code {
|
||||
color:#3a0909!important;
|
||||
}
|
||||
@@ -1,130 +0,0 @@
|
||||
/*!
|
||||
Theme: GitHub Dark Dimmed
|
||||
Description: Dark dimmed theme as seen on github.com
|
||||
Author: github.com
|
||||
Maintainer: @Hirse
|
||||
Updated: 2021-05-15
|
||||
|
||||
Colors taken from GitHub's CSS
|
||||
*/
|
||||
|
||||
.hljs, pre, pre code {
|
||||
color: #adbac7!important;
|
||||
background: #22272e!important;
|
||||
}
|
||||
|
||||
.hljs-doctag,
|
||||
.hljs-keyword,
|
||||
.hljs-meta .hljs-keyword,
|
||||
.hljs-template-tag,
|
||||
.hljs-template-variable,
|
||||
.hljs-type,
|
||||
.hljs-variable.language_,
|
||||
.pl-k {
|
||||
/* prettylights-syntax-keyword */
|
||||
color: #f47067!important;
|
||||
}
|
||||
|
||||
.hljs-title,
|
||||
.hljs-title.class_,
|
||||
.hljs-title.class_.inherited__,
|
||||
.hljs-title.function_i,
|
||||
.pl-s {
|
||||
/* prettylights-syntax-entity */
|
||||
color: #dcbdfb!important;
|
||||
}
|
||||
|
||||
.hljs-attr,
|
||||
.hljs-attribute,
|
||||
.hljs-literal,
|
||||
.hljs-meta,
|
||||
.hljs-number,
|
||||
.hljs-operator,
|
||||
.hljs-variable,
|
||||
.hljs-selector-attr,
|
||||
.hljs-selector-class,
|
||||
.hljs-selector-id,
|
||||
.pl-e {
|
||||
/* prettylights-syntax-constant */
|
||||
color: #6cb6ff!important;
|
||||
}
|
||||
|
||||
.hljs-regexp,
|
||||
.hljs-string,
|
||||
.hljs-meta .hljs-string,
|
||||
.pl-s {
|
||||
/* prettylights-syntax-string */
|
||||
color: #96d0ff!important;
|
||||
}
|
||||
|
||||
.hljs-built_in,
|
||||
.hljs-symbol,
|
||||
.pl-c1 {
|
||||
/* prettylights-syntax-variable */
|
||||
color: #f69d50!important;
|
||||
}
|
||||
|
||||
.hljs-comment,
|
||||
.hljs-code,
|
||||
.hljs-formula,
|
||||
.pl-c {
|
||||
/* prettylights-syntax-comment */
|
||||
color: #768390!important;
|
||||
}
|
||||
|
||||
.hljs-name,
|
||||
.hljs-quote,
|
||||
.hljs-selector-tag,
|
||||
.hljs-selector-pseudo {
|
||||
/* prettylights-syntax-entity-tag */
|
||||
color: #8ddb8c!important;
|
||||
}
|
||||
|
||||
.hljs-subst {
|
||||
/* prettylights-syntax-storage-modifier-import */
|
||||
color: #adbac7!important;
|
||||
}
|
||||
|
||||
.hljs-section {
|
||||
/* prettylights-syntax-markup-heading */
|
||||
color: #316dca!important;
|
||||
font-weight: bold!important;
|
||||
}
|
||||
|
||||
.hljs-bullet {
|
||||
/* prettylights-syntax-markup-list */
|
||||
color: #eac55f!important;
|
||||
}
|
||||
|
||||
.hljs-emphasis {
|
||||
/* prettylights-syntax-markup-italic */
|
||||
color: #adbac7!important;
|
||||
font-style: italic!important;
|
||||
}
|
||||
|
||||
.hljs-strong {
|
||||
/* prettylights-syntax-markup-bold */
|
||||
color: #adbac7!important;
|
||||
font-weight: bold!important;
|
||||
}
|
||||
|
||||
.hljs-addition {
|
||||
/* prettylights-syntax-markup-inserted */
|
||||
color: #b4f1b4!important;
|
||||
background-color: #1b4721!important;
|
||||
}
|
||||
|
||||
.hljs-deletion {
|
||||
/* prettylights-syntax-markup-deleted */
|
||||
color: #ffd8d3!important;
|
||||
background-color: #78191b!important;
|
||||
}
|
||||
|
||||
.hljs-char.escape_,
|
||||
.hljs-link,
|
||||
.hljs-params,
|
||||
.hljs-property,
|
||||
.hljs-punctuation,
|
||||
.hljs-tag {
|
||||
/* purposely ignored */
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB |
@@ -1,6 +0,0 @@
|
||||
# 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)!!!
|
||||
@@ -1,17 +0,0 @@
|
||||
# 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/democol.yml)!!!
|
||||
|
||||
### siehe
|
||||
|
||||
- [fields](./collections/fields.md)
|
||||
- [indexes](./collections/indexes.md)
|
||||
- [hooks](./collections/hooks.md)
|
||||
- [imageFilter](./collections/imageFilter.md)
|
||||
- [meta](./collections/meta.md)
|
||||
Binary file not shown.
@@ -1,237 +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
|
||||
|
||||
<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.
|
||||
@@ -1,43 +0,0 @@
|
||||
# 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.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 53 KiB |
@@ -1,97 +0,0 @@
|
||||
# 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/title.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/age.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/isEmployed.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/gender.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/image.yml)!!!
|
||||
!!!include(../api/collections/medialib.yml)!!!
|
||||
|
||||
Setzt man defaultCollectionViews auf true, so könnte das ergebnis wie folgt aussehen:
|
||||
|
||||
|
||||
## 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/date.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/description.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/profilePic.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/skills.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.
|
||||
!!!include(../api/collections/fields/tags.yml)!!!
|
||||
|
||||
## object
|
||||
|
||||
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.
|
||||
!!!include(../api/collections/fields/info.yml)!!!
|
||||
|
||||
## objectArray / object[]
|
||||
|
||||
Genau das gleiche wie object, nur das hier mehrere Objekte erstellt werden können.
|
||||
|
||||
## grid
|
||||
|
||||
Für Datentyp object[], dient als übersichtliche object[] alternative, speziell für pagebuilder entwickelt.
|
||||
!!!include(../api/collections/fields/employmentDetails.yml)!!!
|
||||
|
||||
## jsonField
|
||||
|
||||
Wird für Daten genutzt, wo man die Struktur nicht absehen kann.
|
||||
!!!include(../api/collections/fields/additionalData.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.
|
||||
|
||||
!!!include(../api/collections/fields/emplymentDetails.yml)!!!
|
||||
|
||||
# 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.
|
||||
|
||||
|
||||
|
||||
!!!include(../api/collections/fieldLists/useDefaultArray.yml)!!!
|
||||
|
||||
## contentbuilder - DEPRECATED
|
||||
|
||||
siehe: [ContentBuilder](./widgets/contentbuilder.md)
|
||||
Binary file not shown.
Binary file not shown.
@@ -1,35 +0,0 @@
|
||||
# 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,104 +0,0 @@
|
||||
# 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 der jeweiligen Methode 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.
|
||||
|
||||
### 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.
|
||||
|
||||
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.
|
||||
@@ -1,30 +0,0 @@
|
||||
# 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 |
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
# 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/democol/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.
|
||||
@@ -1,87 +0,0 @@
|
||||
# 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/democol/simpleList.yml)!!!
|
||||
|
||||
### table
|
||||
|
||||
!!!include(../api/collections/democol/table.yml)!!!
|
||||
|
||||
### cardList
|
||||
|
||||
!!!include(../api/collections/democol/cardList.yml)!!!
|
||||
|
||||
## quickEdit
|
||||
|
||||
```yml
|
||||
# wenn keine fields gesetzt sind, werden alle Felder der Kollektion angezeigt
|
||||
quickEdit:
|
||||
enabled: true # Standardmäßig ist die Schnellbearbeitung aktiviert
|
||||
fields:
|
||||
- title
|
||||
- age
|
||||
- date
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
backup:
|
||||
active: true
|
||||
collectionName: backups
|
||||
|
||||
## 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
|
||||
|
||||
!!!include(../api/collections/backups.yml)!!!
|
||||
Binary file not shown.
@@ -1,17 +0,0 @@
|
||||
# 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)!!!
|
||||
|
||||
### siehe
|
||||
|
||||
|
||||
- [dashboard](./dashboard.md)
|
||||
- [collections](./collections.md)
|
||||
- [jobs](./jobs.md)
|
||||
- [assets](./assets.md)
|
||||
@@ -1,511 +0,0 @@
|
||||
# dashboard
|
||||
|
||||
# Übersicht
|
||||
|
||||
Die bereitgestellte Konfiguration ist eine Spezifikation für ein Dashboard-Layout und seine Komponenten. Dieses Layout bestimmt die Anzeige und Interaktion von verschiedenen Datenvisualisierungen, vor allem in Form von Diagrammen (Graphen). Die Konfiguration ist in zwei Hauptabschnitte unterteilt: "majorItems" und "minorItems". Die "majorItems" sind größere, prominentere Darstellungen von Daten, während die "minorItems" kleinere, weniger prominente Datenelemente repräsentieren. Jedes Element innerhalb dieser Abschnitte ist ein einzelnes Modul oder eine Komponente auf dem Dashboard und kann verschiedene Arten von Datenvisualisierungen darstellen, einschließlich Linien-, Balken-, Kreis- (donut) und Flächendiagramme. Generell ist zu sagen, dass bei jeder string angabe auch I18n verwendet werden kann und bei nahezu jeder String angabe ist ebenfalls die eval angabe möglich. Sollten Nutzer keinen Zugriff auf die Daten haben dürfen, so wird das bestimmte Diagramm nicht gerendert und stattdessen ein Placeholder mit Zugriff verweigert angezeigt.
|
||||
|
||||
# Elementbeschreibungen
|
||||
|
||||
## type
|
||||
|
||||
Der Typ des Dashboard-Elements ist ein entscheidendes Attribut.
|
||||
|
||||
- ˋgraphˋ:
|
||||
Wenn der Typ "graph" ist, wird das Element als Diagramm dargestellt. Dies ermöglicht eine Vielzahl von Visualisierungen wie Linien-, Balken-, Kuchen-, Donut- oder Flächendiagramme, abhängig vom graphType.
|
||||
|
||||
- ˋswiperˋ:
|
||||
Der Typ "swiper" erstellt ein Karussell-ähnliches Element, das eine Reihe von anderen Elementen enthält, die durchgeblättert werden können. Jedes Element innerhalb des "swiper"-Typs wird genauso konfiguriert wie ein normales Dashboard-Element, was bedeutet, dass sie jeweils ihren eigenen type, title, etc. haben können.
|
||||
|
||||
- ˋreferenceˋ:
|
||||
Die "reference"-Typ Elemente sind Verweise auf Collections.
|
||||
|
||||
- ˋcomparisonˋ:
|
||||
Außerdem gibt es den type "comparison", wobei man ein timespan auswählt und dieser timespan und der timespan davor mit einander auf einen bestimmten Wert verglichen werden.
|
||||
|
||||
- ˋtableˋ:
|
||||
Desweiteren gibt es einen type "table" wobei über das additionalApiParams Objekt mit dem limit attribut gesetzt wird wie viele Einträge von der ausgewählten collection Angezeigt werden sollen. Per Default sind es 5
|
||||
|
||||
- ˋsectionTitleˋ
|
||||
Der "sectionTitle" type ist wie der name schon sagt, ein Titel für einen Abschnitt vom dashboard
|
||||
|
||||
## title
|
||||
|
||||
Der Titel eines Elements ist ein Objekt, das einen eval, value, contentBefore und contentAfter haben kann. value repräsentiert den Hauptteil des Titels, während contentBefore und contentAfter optionale Textstücke sind, die vor bzw. nach dem Haupttitel platziert werden. Eval kann als ersatz für value verwendet werden. Auch ist eine normale String angabe möchglich. Diese wird hier, sowie überall anders auch in die genutzte sprache konvertiert, daher ist die angabe über das {de:”xyz”, en:”xyz”} sinnvoll.
|
||||
|
||||
## subTitle
|
||||
|
||||
Dies ist ein Untertitel für das Dashboard-Element.
|
||||
|
||||
## additionalApiParams
|
||||
|
||||
Dies ist ein Objekt und kann folgende Parameter haben:
|
||||
|
||||
```ts
|
||||
interface APIParams {
|
||||
offset?: number
|
||||
limit?: number
|
||||
sort?: string
|
||||
filter?: {
|
||||
[key: string]: any
|
||||
}
|
||||
projection?: string
|
||||
count?: 1
|
||||
}
|
||||
```
|
||||
|
||||
Sollte es komntextabhängig bereits automatisch genertierte Filter Objekt attirbute geben, so werden, wenn man welche angibt, seine eigenen über Object.assign zu diesen hinzu gefügt.
|
||||
|
||||
## subNavigation
|
||||
|
||||
Das Attrbiut bei type: reference dient dazu, den Link zu einer bestimmten subKategorie zu machen. Nimmt den index der gewüpnschten subNavigation als Wert.
|
||||
|
||||
## graphType
|
||||
|
||||
Das Attribut graphType bestimmt die spezifische Art der Datenvisualisierung für ein Element vom Typ "graph". Die möglichen Werte sind "line" (Linien-Diagramm), "bar" (Balkendiagramm), "donut" (Kreisdiagramm), “pie” (Kuchendiagramm) und "area" (Flächendiagramm).
|
||||
|
||||
## xAxis und yAxis
|
||||
|
||||
Diese Attribute definieren die Daten, die auf den Achsen des Diagramms angezeigt werden. xAxis immer "timeline", was bedeutet, dass die Daten über die Zeit dargestellt werden. yAxis kann “sum” oder “amount” sein. Sum summiert die Werte des angegebenen feldes im time interval, wohingegen amount die Menge des angegebenen Feldes im time interval aufsummiert und angibt. Möchte man die menge von den Kollektionen angeben, so ist kein weiterer schritt nötig. Möchte man angeben, wie oft ein feld in den kollektionen vor kommt, so hat man 2 möglichkeiten. Wenn das feld einmal pro kollektion vor kommt, so gibt man einfach über den field parameter den pfad dorthin an also bspw. wenn im root einfach nur xyz oder xyz.yxz.... Wenn das feld aber in einer object[] struktur ist, so gibt man den pfad dorthin an (über path) und dann ausgehend von dem objekt wird die field angabe genutzt. Bei sum ist das prinzip das selbe.
|
||||
|
||||
## 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"
|
||||
```
|
||||
|
||||
## graphs
|
||||
|
||||
Ein Array von Objekten, wobei jedes Objekt ein einzelnes Diagramm darstellt, das innerhalb des Dashboard-Elements dargestellt wird. Bei meherer Angabe werden auch mehrere graphen im selben chart angezeigt, für unterschiedliche y Achsen im selben Chart ist multipleYAxes auf true zu setzen, hier ist dann auch die YAxisTitle vorgenommen. Jedes dieser Diagrammobjekte hat mehrere Attribute, darunter field,path, dateTimeField, collection und graphName. field gibt an, welches Datenfeld aus der Sammlung zur Erzeugung des Diagramms verwendet werden soll. Path gibt den weg zum feld an, wenn das feld direkt im objekt liegt, so ist “this” oder garkeine angabe valide. dateTimeField bestimmt das Feld, das die Zeitskala für das Diagramm liefert. collection ist der Name der Datenkollektion, aus der die Daten bezogen werden. Schließlich definiert graphName den Namen des Diagramms.
|
||||
|
||||
## style
|
||||
|
||||
Ein Objekt, das CSS-Stilinformationen für das Dashboard-Element enthält. Es ist für die reference elemente gedacht.
|
||||
|
||||
## collection
|
||||
|
||||
Dieses Feld bezieht sich auf die Datenquelle oder Sammlung, auf die das Dashboard-Element zugreifen wird.
|
||||
|
||||
## timeInterval
|
||||
|
||||
Dieses Feld definiert den Zeitraum, der im Diagramm angezeigt wird. Die möglichen Werte können "day", "month", "year" sein, je nachdem, welche Granularität für die Datenvisualisierung gewünscht wird.
|
||||
|
||||
## timespan
|
||||
|
||||
Der Zeitraum für die Vergleichsdaten. Es kann "QTD" für das aktuelle Quartal und das Quartal davor sein, "MTD" für den aktuellen Monat und den Monat davor sein oder YTD für das aktuelle Jahr und das Jahr davor sein. Immer nur bis zum heutigem Tag dieser Zeitspanne, also bspw. vom 1.1.2023 bis zum 28.5.2023 wäre YTD wobei das vergleichs Jahr dann vom 1.1.2022 bis zum 28.5.2022 wäre:
|
||||
|
||||
```js
|
||||
switch (input) {
|
||||
case "YTD": // Year to date
|
||||
begin = new Date(date.getFullYear(), 0, 1)
|
||||
end = currentDate
|
||||
lastBegin = new Date(date.getFullYear() - 1, 0, 1)
|
||||
lastEnd = new Date(date.getFullYear() - 1, date.getMonth(), date.getDate())
|
||||
break
|
||||
case "QTD": // Quarter to date
|
||||
let quarterStartMonth = Math.floor(date.getMonth() / 3) * 3
|
||||
begin = new Date(date.getFullYear(), quarterStartMonth, 1)
|
||||
end = currentDate
|
||||
lastBegin = new Date(date.getFullYear(), quarterStartMonth - 3, 1)
|
||||
lastEnd = new Date(date.getFullYear(), date.getMonth() - 3, date.getDate())
|
||||
break
|
||||
case "MTD": // Month to date
|
||||
begin = new Date(date.getFullYear(), date.getMonth(), 1)
|
||||
end = currentDate
|
||||
lastBegin = new Date(date.getFullYear(), date.getMonth() - 1, 1)
|
||||
lastEnd = new Date(date.getFullYear(), date.getMonth() - 1, date.getDate())
|
||||
break
|
||||
}
|
||||
```
|
||||
|
||||
## until
|
||||
|
||||
Dieses Feld definiert den Endpunkt des Zeitintervalls für die Datenvisualisierung. Mögliche Werte sind "lastWeek", “lastMonth”, “lastYear” und "allTime", welches jedoch default ist. Zum Beispiel, wenn until auf "lastMonth" gesetzt ist, wird das Diagramm maximal Daten bis zum letzten Monat anzeigen. Außerdem sind alle Optionen darunter für den Nutzer auswählbar. Um dies zu unterbinden, muss das filter attribut auf false gesetzt werden.
|
||||
|
||||
## defaultUntil
|
||||
|
||||
Dieses Attribut setzt den default Filter. Es ist anzumerken, dass mit jedem Filter change eine Neue Request einhergeht, und immer mit dem aktuellem Filter requested wird, dieser sollte also ggf. für perfomance per default niedrig gesetzt werden.
|
||||
|
||||
## filter
|
||||
|
||||
Wird filter auf false gesetzt, so ist der Filter nicht länger sichtbar.
|
||||
|
||||
## multipleYAxes
|
||||
|
||||
Dieses Boolean-Feld gibt an, ob das Diagramm mehrere Y-Achsen haben soll. Wenn auf true gesetzt, hat jedes Diagramm im graphs Array eine eigene Y-Achse haben. Hierfür ist dann eine Achsenbeschriftung sinnvoll. Diese wird dann mit yAxisTitle im jeweiligen Graphs objekt angegeben.
|
||||
|
||||
## graphBaseColor
|
||||
|
||||
Dies definiert die Basisfarbe des Diagramms. Die Farbe muss in einem gültigen CSS-Farbformat angegeben werden.
|
||||
|
||||
## value
|
||||
|
||||
Im Kontext des title-Feldes repräsentiert value den Hauptteil des Titels. In Bezug auf Diagramme, insbesondere bei Donut- und Kuchendiagrammen, repräsentiert value den numerischen Wert, der im Diagramm dargestellt wird. Hier sind mögliche werte: “total”, welches die Summe vom ausgewählten feld bis zu until ausgibt, “amount”, welches das gleiche macht, nur nicht summiert sondern zählt und “count” wobei die Einträge selbst gezählt werden.
|
||||
|
||||
## valueType
|
||||
|
||||
Wird bei "comparison" verwendet, um den vergleich relativ oder absolut vorzunehmen. Valide angaben sind: "relative" und "absolute".
|
||||
|
||||
## path
|
||||
|
||||
Dieses Feld kann verwendet werden, um den genauen Pfad zu der spezifischen Datenstruktur zu definieren, welches in der Sammlung für die Datenvisualisierung als referenz Array für den field parameter verwendet wird. Dies ist also sinvoll, wenn das Feld in einem Object[] ist, andernfalls ist bei field die angabe über xyz.yxz.zyx erwünscht. Ist das feld im root oder über den field parameter erreichbar, so kann man path leeer lassen oder "this" angeben.
|
||||
|
||||
## dateTimeField
|
||||
|
||||
Dies ist das Feld, das den Zeitstempel in der Datensammlung repräsentiert. Es wird verwendet, um die Zeitskala für das Diagramm zu liefern. Hier ist das erwünschte Datumsfeld in der collection auszuwählen.
|
||||
|
||||
## limit
|
||||
|
||||
gibt an wie viele Elemente maximal returned werden sollen.
|
||||
|
||||
## newPageRef
|
||||
|
||||
boolean, wenn explizit auf false, dann wird bei type reference kein Neue Seite hinzufügen button angezeigt.
|
||||
|
||||
# Code Beispiel
|
||||
|
||||
```yaml
|
||||
dashboard:
|
||||
majorItems: # Liste der Hauptelemente des Dashboards
|
||||
- type: sectionTitle
|
||||
title: "Overview" #i18n or eval
|
||||
|
||||
- type: swiper
|
||||
containerProps:
|
||||
class: "random-class"
|
||||
layout:
|
||||
breakBefore: false # no html elements before
|
||||
breakAfter: false #no html elmenets after
|
||||
size: #different classes depending on innerWidth
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
elements:
|
||||
- type: comparison
|
||||
collection: contact_form
|
||||
timespan: "QTD" #QTD & MTD with last quarter, month or year
|
||||
value: total
|
||||
valueType: absolute #oder relative (prozentual)
|
||||
path: paymentValues
|
||||
additionalApiParams: #Nimmt APIParams entgegen und fügt sie zusätzlich ein, filter Objekt Parameter wird ggf. zum automatisch generierten Assigned, also vorsicht!
|
||||
limit: 3
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
title: toller titel #string or eval
|
||||
subTitle: { de: "YTD Vergleich zum Vorjahr", en: "YTD comparison with last year" }
|
||||
|
||||
- type: comparison
|
||||
collection: contact_form
|
||||
timespan: "QTD" #QTD & MTD with last quarter, month or year
|
||||
value: total
|
||||
valueType: absolute #oder relative (prozentual)
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
title: toller titel #i18n or eval
|
||||
subTitle: { de: "YTD Vergleich zum Vorjahr", en: "YTD comparison with last year" }
|
||||
|
||||
- type: swiper
|
||||
css:
|
||||
graph:
|
||||
wrapper:
|
||||
eval: |
|
||||
`
|
||||
background-color: green ;
|
||||
`
|
||||
containerProps:
|
||||
class: "random-class"
|
||||
layout:
|
||||
breakBefore: false # no html elements before
|
||||
breakAfter: true #no html elmenets after
|
||||
size: #different classes depending on innerWidth
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
elements:
|
||||
- type: comparison
|
||||
collection: contact_form
|
||||
timespan: "QTD" #QTD & MTD with last quarter, month or year
|
||||
value: total
|
||||
valueType: relative #oder relative (prozentual)
|
||||
path: paymentValues
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
title: toller titel #string or eval
|
||||
subTitle: { de: "YTD Vergleich zum Vorjahr", en: "YTD comparison with last year" }
|
||||
|
||||
- type: comparison
|
||||
collection: contact_form
|
||||
timespan: "QTD" #QTD & MTD with last quarter, month or year
|
||||
value: total
|
||||
valueType: relative #oder relative (prozentual)
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
title: toller titel #string or eval
|
||||
subTitle: { de: "YTD Vergleich zum Vorjahr", en: "YTD comparison with last year" }
|
||||
|
||||
- type: sectionTitle
|
||||
title: "Details"
|
||||
|
||||
- type: graph # Art des Elements, hier ein Graph
|
||||
css:
|
||||
graph:
|
||||
wrapper:
|
||||
eval: |
|
||||
`
|
||||
background-color: yellow ;
|
||||
`
|
||||
title: # Titel des Graphen
|
||||
#eval anstelle von value möglich
|
||||
value: total #o. amount Haupttitel des Graphen
|
||||
contentAfter: "€" # Nach dem Haupttitel hinzugefügte Inhalte
|
||||
contentBefore: "xyz" # Vor dem Haupttitel hinzugefügte Inhalte
|
||||
timeInterval: "day" # Zeitintervall der Daten im Graphen
|
||||
until: "lastMonth" # Ende des Zeitintervalls (Ab dem aktuellen Datum)
|
||||
graphType: "line" # Art des Graphen, hier ein Liniendiagramm
|
||||
graphBaseColor: "#ff0000" # Basisfarbe des Graphen
|
||||
subTitle: { de: "Umsatz", en: "sales volume" } # Untertitel des Graphen, mehrsprachig
|
||||
xAxis: timeline # Art der x-Achse, hier eine Zeitachse
|
||||
class: "random-class" #Class added
|
||||
additionalApiParams:
|
||||
limit: 2
|
||||
containerProps:
|
||||
#optional class prop
|
||||
layout:
|
||||
breakBefore: false
|
||||
breakAfter: false
|
||||
size:
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
|
||||
graphs: # Liste der Graphen in diesem Element
|
||||
- yAxis: sum # Art der y-Achse, hier eine Summe
|
||||
field: paymentValue # Feld der Daten für den Graphen
|
||||
dateTimeField: Date # Feld für den Zeitstempel der Daten
|
||||
yAxisTitle: Graph titel # Titel der y-Achse
|
||||
collection: contact_form # Sammlung, aus der die Daten stammen
|
||||
graphName: { de: "Umsatz", en: "sales volume" } # Name des Graphen, mehrsprachig
|
||||
- graphName: { de: "Umsatz anderes feldes", en: "Sum of other values" }
|
||||
path: paymentValues # Pfad zu den Daten im Feld
|
||||
yAxis: sum
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
collection: contact_form
|
||||
- type: graph
|
||||
title:
|
||||
value: total
|
||||
contentAfter: "€"
|
||||
contentBefore: "xyz"
|
||||
timeInterval: "day"
|
||||
until: "lastMonth"
|
||||
graphType: "line"
|
||||
graphBaseColor: "#ff0000"
|
||||
subTitle: { de: "Umsatz", en: "sales volume" }
|
||||
xAxis: timeline
|
||||
multipleYAxes: true # Option für mehrere y-Achsen
|
||||
containerProps:
|
||||
#optional class prop
|
||||
layout:
|
||||
breakBefore: false
|
||||
breakAfter: false
|
||||
size:
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
|
||||
graphs:
|
||||
- yAxis: sum
|
||||
yAxisTitle: Summe nr 1
|
||||
graphType: "bar" # Art des Graphen, hier ein Balkendiagramm
|
||||
field: paymentValue
|
||||
dateTimeField: Date
|
||||
collection: contact_form
|
||||
graphName: { de: "Umsatz", en: "sales volume" }
|
||||
|
||||
- graphName: { de: "Umsatz anderes feldes", en: "Sum of other values" }
|
||||
path: paymentValues
|
||||
yAxisTitle: Summe nr 2
|
||||
yAxis: sum
|
||||
graphType: "line"
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
collection: contact_form
|
||||
- type: swiper # Art des Elements, hier ein Swiper
|
||||
containerProps:
|
||||
#optional class prop
|
||||
layout:
|
||||
breakBefore: false
|
||||
breakAfter: false
|
||||
size:
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
|
||||
elements: # Liste der Elemente in diesem Swiper
|
||||
- type: graph
|
||||
title:
|
||||
value: total
|
||||
contentAfter: "€"
|
||||
contentBefore: "xyz"
|
||||
until: "lastMonth"
|
||||
graphType: "donut" # Art des Graphen, hier ein Donut-Diagramm
|
||||
value: total # Summe aller werte in spezifiziertem Feld, welche dann im Diagramm dargestellt werden
|
||||
graphBaseColor: "#ff0000"
|
||||
subTitle: { de: "Umsatz", en: "sales volume" }
|
||||
graphs:
|
||||
- field: paymentValue
|
||||
dateTimeField: Date
|
||||
collection: contact_form
|
||||
graphName: { de: "Umsatz", en: "sales volume" }
|
||||
- graphName: { de: "Umsatz anderes feldes", en: "Sum of other values" }
|
||||
path: paymentValues
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
collection: contact_form
|
||||
- type: graph
|
||||
title:
|
||||
value: total
|
||||
contentAfter: "€"
|
||||
contentBefore: "xyz"
|
||||
until: "lastMonth"
|
||||
graphType: "pie" # Art des Graphen, hier ein Kuchendiagramm
|
||||
value: total
|
||||
graphBaseColor: "#ff0000"
|
||||
subTitle: { de: "Umsatz", en: "sales volume" }
|
||||
graphs:
|
||||
- field: paymentValue
|
||||
dateTimeField: Date
|
||||
collection: contact_form
|
||||
graphName: { de: "Umsatz", en: "sales volume" }
|
||||
- graphName: { de: "Umsatz anderes feldes", en: "Sum of other values" }
|
||||
path: paymentValues
|
||||
dateTimeField: Date
|
||||
field: paymentValue
|
||||
collection: contact_form
|
||||
|
||||
- containerProps:
|
||||
#optional class prop
|
||||
layout:
|
||||
breakBefore: false
|
||||
breakAfter: false
|
||||
size:
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
type: graph
|
||||
title:
|
||||
value: total
|
||||
contentAfter: "€"
|
||||
subTitle: { de: "Umsatz", en: "sales volume" }
|
||||
xAxis: timeline
|
||||
timeInterval: "day"
|
||||
graphType: "area" # Art des Graphen, hier ein Flächendiagramm
|
||||
graphs:
|
||||
- field: paymentValue
|
||||
dateTimeField: Date
|
||||
yAxis: sum
|
||||
collection: contact_form
|
||||
path: "this" # Pfad zu den Daten im Feld, hier das aktuelle Objekt, keine Angabe hat den gleichen Wert
|
||||
graphName: { de: "Umsatz", en: "sales volume" }
|
||||
- type: swiper
|
||||
containerProps:
|
||||
#optional class prop
|
||||
layout:
|
||||
breakBefore: false
|
||||
breakAfter: true
|
||||
size:
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-4"
|
||||
elements:
|
||||
- class: col-6
|
||||
type: graph
|
||||
subTitle: { de: "Produktmenge", en: "Amount of products" }
|
||||
xAxis: timeline
|
||||
timeInterval: "day"
|
||||
filter: false #deaktiviert die Filter möglichkeit für den Nutzer beim diagramm, normalerweise aktiviert. Hierbei sind alle kombinationen x >= until möglich
|
||||
dateTimeField: Date
|
||||
until: "lastMonth"
|
||||
graphType: "bar"
|
||||
graphs:
|
||||
- graphName: { de: "Menge", en: "Amount" }
|
||||
yAxis: amount # Art der y-Achse, hier die Anzahl von allen Feldern im spezifiziertem intervall
|
||||
dateTimeField: Date
|
||||
collection: contact_form
|
||||
- class: col-8
|
||||
type: graph
|
||||
filter: false
|
||||
title:
|
||||
value: total
|
||||
contentAfter: "€"
|
||||
subTitle: { de: "Umsatz", en: "sales volume" }
|
||||
xAxis: timeline
|
||||
timeInterval: "day"
|
||||
dateTimeField: Date
|
||||
graphType: "line"
|
||||
until: "lastMonth"
|
||||
graphs:
|
||||
- field: paymentValue
|
||||
yAxis: sum # Art der y-Achse, hier eine Summe
|
||||
collection: contact_form # Sammlung, aus der die Daten stammen
|
||||
dateTimeField: Date # Feld für den Zeitstempel der Daten
|
||||
path: "this" # Pfad zu den Daten im Feld, hier das aktuelle Objekt
|
||||
graphName: { de: "Umsatz", en: "sales volume" } # Name des Graphen, mehrsprachig
|
||||
- type: table #shows entries from specified collection
|
||||
containerProps:
|
||||
#optional class prop
|
||||
layout:
|
||||
breakBefore: false
|
||||
breakAfter: true
|
||||
size:
|
||||
default: "col-8"
|
||||
small: "col-12"
|
||||
large: "col-7"
|
||||
collection: contact_form
|
||||
title: Konaktformular Titel
|
||||
subTitle: subtitel oder so
|
||||
additionalApiParams:
|
||||
limit: 3
|
||||
|
||||
- collection: content # Sammlung, aus der die Daten für das nächste Element stammen
|
||||
type: reference # Art des Elements, hier ein Referenz-Element
|
||||
style: # Stil des Elements
|
||||
upper: rgba(3, 50, 59, 0.7) # Farbe des oberen Teils
|
||||
lower: rgba(3, 50, 59) # Farbe des unteren Teils
|
||||
- collection: content # Wiederholung der vorherigen Elemente
|
||||
type: reference
|
||||
style:
|
||||
upper: rgba(3, 50, 59, 0.7)
|
||||
lower: rgba(3, 50, 59)
|
||||
- collection: contact_form
|
||||
subNavigation: 1
|
||||
type: reference
|
||||
style:
|
||||
upper: rgba(3, 50, 59, 0.7)
|
||||
lower: rgba(3, 50, 59)
|
||||
|
||||
minorItems: # Liste der Nebenelemente des Dashboards
|
||||
- collection: contact_form # Referenz auf collections
|
||||
subNavigation: 0
|
||||
- collection: contact_form # Wiederholung der vorherigen Nebenelemente
|
||||
subNavigation: 0
|
||||
- collection: contact_form
|
||||
subNavigation: 0
|
||||
- collection: contact_form
|
||||
subNavigation: 0
|
||||
- collection: contact_form
|
||||
subNavigation: 0
|
||||
- collection: contact_form
|
||||
newPageRef: false
|
||||
```
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 109 KiB |
@@ -1,11 +0,0 @@
|
||||
# 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/allgemeines.md) beschrieben.
|
||||
@@ -1,65 +0,0 @@
|
||||
# Ordnerstruktur
|
||||
|
||||
Als Konvention für neue Projekte hat sich folgende Ordnerstruktur etabliert:
|
||||
|
||||
|
||||
|
||||
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.
|
||||
@@ -1,27 +0,0 @@
|
||||
# /assets
|
||||
|
||||
Die /assets-API ist dazu gedacht, den Zugriff auf bestimmte Ordnerpfade zu ermöglichen, die direkt über den Tibi-Server erreichbar sind. Diese Pfade werden in der Konfigurationsdatei (config.yml) definiert und relativ zu dieser Datei interpretiert. Jeder dieser Pfade wird durch einen eindeutigen Namen identifiziert, der in der URL verwendet wird.
|
||||
|
||||
## URL-Struktur
|
||||
|
||||
Die Struktur der URL für den Zugriff auf die Assets ist wie folgt:
|
||||
|
||||
- TIBI-SERVER-URL/api/v1/_/NAMESPACE/_/assets/NAME/
|
||||
|
||||
Hierbei steht NAME für den in der Konfigurationsdatei festgelegten Namen für den Pfad. Wenn beispielsweise ein Pfad mit dem Namen _dist_ definiert ist, der auf den Ordner ../frontend/_dist_ relativ zur config.yml zeigt, würde die entsprechende URL so aussehen:
|
||||
|
||||
- TIBI-SERVER-URL/api/v1/_/NAMESPACE/_/assets/_dist_/
|
||||
|
||||
## Zugriffsmethode
|
||||
|
||||
Über die /assets-API ist ausschließlich ein unbeschränkter Lesezugriff (GET-Methode) möglich. Dies bedeutet, dass Sie über diese API Dateien aus den definierten Pfaden abrufen können, aber keine Änderungen vornehmen oder Dateien hochladen können.
|
||||
Konfigurationsbeispiel
|
||||
|
||||
In der config.yml könnten Sie einen Asset-Pfad wie folgt definieren:
|
||||
|
||||
```yaml
|
||||
name: _dist_
|
||||
path: ../frontend/_dist_
|
||||
```
|
||||
|
||||
Dies würde den Zugriff auf Dateien im Ordner ../frontend/_dist_ relativ zur config.yml über die URL TIBI-SERVER-URL/api/v1/_/NAMESPACE/_/assets/_dist_/ ermöglichen.
|
||||
@@ -1,239 +0,0 @@
|
||||
# `/_/NAMESPACE/COLLECTION`
|
||||
|
||||
Dieser Endpoint ermöglicht Interaktionen mit den Collectionen, die flexible Strukturen zur Organisation und Kategorisierung von Daten darstellen. Sie können einen Collectioneintrag abrufen, aktualisieren, erstellen und löschen. Jede Collection wird durch einen eindeutigen Namespace und Namen identifiziert.
|
||||
|
||||
## GET /{namespace}/{collection}
|
||||
|
||||
Diese Anforderung ruft alle Einträge einer bestimmten Collection ab. Sie nimmt den Namespace und den Namen der Collection sowie optionale API-Parameter für die Anpassung der Anfrage als Parameter an.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein Objekt mit folgenden Eigenschaften:
|
||||
|
||||
- `data`: Ein Array von CollectionEntry Objekten.
|
||||
|
||||
- `count`: Die Gesamtzahl der Einträge.
|
||||
|
||||
```ts
|
||||
interface Collection {
|
||||
name: string
|
||||
meta?: CollectionMeta
|
||||
permissions?: {
|
||||
public?: CollectionPermission
|
||||
user?: CollectionPermission
|
||||
[token: string]: CollectionPermission
|
||||
}
|
||||
projections?: {
|
||||
[projectionName: string]: {
|
||||
select: {
|
||||
[field: string]: 1 | 0
|
||||
}
|
||||
}
|
||||
}
|
||||
fields: CollectionField[]
|
||||
}
|
||||
```
|
||||
|
||||
## GET /{namespace}/{collection}/{id}
|
||||
|
||||
Diese Anforderung ruft einen bestimmten Eintrag in einer Collection ab. Sie nimmt den Namespace und Namen der Collection sowie die ID des abzurufenden Eintrags als Parameter an.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
- `id`: Die ID des abzurufenden Eintrags.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist das entsprechende CollectionEntry Objekt.
|
||||
|
||||
## PUT /{namespace}/{collection}/{id}
|
||||
|
||||
Diese Anforderung aktualisiert die Daten eines vorhandenen Eintrags in einer Collection. Sie nimmt den Namespace und den Namen der Collection, die ID des zu aktualisierenden Eintrags und ein Änderungssatz-Objekt, das die zu aktualisierenden Daten enthält, als Parameter an.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
id: Die ID des zu aktualisierenden Eintrags.
|
||||
|
||||
data: Ein Änderungssatz-Objekt, das die zu aktualisierenden Daten enthält.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist das aktualisierte CollectionEntry Objekt.
|
||||
|
||||
## POST /{namespace}/{collection}
|
||||
|
||||
Diese Anforderung erstellt einen neuen Eintrag in einer Collection. Sie nimmt den Namespace und den Namen der Collection und ein Datenobjekt, das die Informationen des neuen Eintrags enthält, als Parameter an. Optional kann eine Funktion für den Fortschritt des Uploads übergeben werden.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
- `data`: Ein Datenobjekt, das die Informationen des neuen Eintrags enthält.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist das neu erstellte CollectionEntry Objekt.
|
||||
|
||||
## DELETE /{namespace}/{collection}/{id}
|
||||
|
||||
Diese Anforderung löscht einen vorhandenen Eintrag in einer Collection. Sie nimmt den Namespace und den Namen der Collection und die ID des zu löschenden Eintrags als Parameter an.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
- `id`: Die ID des zu löschenden Eintrags.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein boolean, das true zurückgibt, wenn das Löschen erfolgreich war.
|
||||
|
||||
Jede Collection besteht aus mehreren Feldern (CollectionField), die verschiedene Datenpunkte repräsentieren. Jedes Feld hat einen Namen, einen Typ und ggf. eine Reihe von Subfeldern. Die Metadaten eines Feldes (CollectionFieldMeta) können zusätzliche Informationen über das Feld enthalten, wie z.B. ein Label, Hilfstexte, Widget-Typen, InputProps und mehr.
|
||||
|
||||
Eine Collection kann auch Metadaten (CollectionMeta) enthalten, die Informationen über die Collection selbst enthalten.
|
||||
|
||||
```ts
|
||||
interface CollectionNavigation {
|
||||
label?: I18Text
|
||||
muiIcon?: string
|
||||
defaultSort?: {
|
||||
field: string
|
||||
order?: "ASC" | "DESC" | "MANUALLY"
|
||||
}
|
||||
defaultImageFilter?: string
|
||||
views?: View[]
|
||||
filter?: { [key: string]: any }
|
||||
defaultCallback?:
|
||||
| "edit"
|
||||
| "view"
|
||||
| {
|
||||
eval: string
|
||||
}
|
||||
}
|
||||
|
||||
interface CollectionMeta extends CollectionNavigation {
|
||||
singleton: boolean
|
||||
rowIdentTpl?:
|
||||
| string
|
||||
| {
|
||||
twig: string
|
||||
}
|
||||
|
||||
subNavigation?: CollectionNavigation[]
|
||||
|
||||
tablist?: {
|
||||
activeTab?: string
|
||||
tabs: CollectionMetaTab[]
|
||||
}
|
||||
|
||||
[key: string]: any
|
||||
}
|
||||
|
||||
interface CollectionMetaTab {
|
||||
name: string
|
||||
label: I18Text
|
||||
dependsOn?: DependsOn
|
||||
subFields: {
|
||||
source: string
|
||||
name?: string
|
||||
}[]
|
||||
_resolvedSubFields?: CollectionField[]
|
||||
_hide?: boolean
|
||||
}
|
||||
|
||||
interface EntryViewTab {
|
||||
name: string
|
||||
meta: {
|
||||
[key: string]: any
|
||||
}
|
||||
}
|
||||
|
||||
interface CollectionPermission {
|
||||
methods?: MethodPermission
|
||||
filter?: any
|
||||
validProjections?: string[]
|
||||
}
|
||||
|
||||
interface CollectionField {
|
||||
name: string
|
||||
type?: string
|
||||
index?: ("single" | "unique")[]
|
||||
meta?: CollectionFieldMeta
|
||||
subFields?: CollectionField[]
|
||||
}
|
||||
|
||||
type CssWithEval = string | { [key: string]: string | number } | { eval: string }
|
||||
|
||||
interface ContainerProps {
|
||||
class?: string
|
||||
style?: string
|
||||
layout?: {
|
||||
breakBefore: boolean
|
||||
breakAfter: boolean
|
||||
size: {
|
||||
default: string
|
||||
small: string
|
||||
large: string
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
interface CollectionFieldMeta {
|
||||
source?: string
|
||||
label?: I18Text
|
||||
helperText?: I18Text
|
||||
widget?: string
|
||||
valueMap?: {
|
||||
[value: "string" | number]: {
|
||||
name?: I18Text
|
||||
muiIcon?: string
|
||||
style?: string
|
||||
}
|
||||
}
|
||||
containerProps?: ContainerProps
|
||||
choices?: ArrayFieldChoice[] | EndpointOptions
|
||||
filter?: boolean | FilterConfig
|
||||
defaultValue?: DefaultValue
|
||||
addAllowed?: boolean
|
||||
props?: {
|
||||
step?: string | number
|
||||
[key: string]: string | number | boolean
|
||||
}
|
||||
inputProps?: {
|
||||
step?: string | number
|
||||
[key: string]: any
|
||||
}
|
||||
dependsOn?: DependsOn
|
||||
|
||||
css?: {
|
||||
input?: {
|
||||
wrapper?: CssWithEval
|
||||
element?: CssWithEval
|
||||
foreignEntry?: CssWithEval
|
||||
}
|
||||
view?: {
|
||||
wrapper?: CssWithEval
|
||||
element?: CssWithEval
|
||||
foreignEntry?: CssWithEval
|
||||
}
|
||||
filter?: {
|
||||
wrapper?: CssWithEval
|
||||
element?: CssWithEval
|
||||
foreignEntry?: CssWithEval
|
||||
}
|
||||
}
|
||||
folding?: {
|
||||
unfolded?: boolean
|
||||
previewFolded?:
|
||||
| string
|
||||
| {
|
||||
eval: string
|
||||
raw?: boolean
|
||||
}
|
||||
previewUnfolded?:
|
||||
| string
|
||||
| {
|
||||
eval: string
|
||||
raw?: boolean
|
||||
}
|
||||
}
|
||||
|
||||
[key: string]: any
|
||||
}
|
||||
```
|
||||
@@ -1,63 +0,0 @@
|
||||
# `/login`
|
||||
|
||||
## POST /login
|
||||
|
||||
Dieser Endpoint ermöglicht es Benutzern, sich in das System einzuloggen. Dabei wird eine Authentifizierung durchgeführt und bei erfolgreicher Authentifizierung ein Token zurückgegeben, der für nachfolgende API-Aufrufe verwendet wird.
|
||||
|
||||
## Anforderungsparameter
|
||||
|
||||
Der /login Endpoint erwartet folgende Daten im Body:
|
||||
|
||||
- `username`: Der Benutzername des Benutzers, der sich anmelden möchte. Typ: String.
|
||||
|
||||
- `password`: Das Passwort des Benutzers, der sich anmelden möchte. Typ: String.
|
||||
|
||||
Die Daten müssen als LoginData Objekt übergeben werden.
|
||||
|
||||
```ts
|
||||
const loginData: LoginData = {
|
||||
username: "IhrBenutzername",
|
||||
password: "IhrPasswort",
|
||||
}
|
||||
```
|
||||
|
||||
## Antwort
|
||||
|
||||
Bei erfolgreicher Anmeldung gibt der /login Endpoint ein LoginResponse Objekt zurück. Dieses Objekt enthält:
|
||||
|
||||
- `token`: Ein Authentifizierungstoken, das für nachfolgende API-Aufrufe verwendet wird. Typ: String.
|
||||
|
||||
- `user`: Ein User Objekt, das Informationen über den eingeloggten Benutzer enthält.
|
||||
|
||||
```ts
|
||||
interface User {
|
||||
id: string // Eindeutige ID des Benutzers
|
||||
insertTime: string // Zeitpunkt der Erstellung des Benutzerkontos
|
||||
updateTime: string // Letzter Zeitpunkt der Aktualisierung des Benutzerkontos
|
||||
username: string // Benutzername des Benutzers
|
||||
role: number // Rolle des Benutzers im System (0=admin, 1 = editor, 2 = user)
|
||||
permissions: any[] // Berechtigungen des Benutzers
|
||||
meta: {
|
||||
// Weitere optionale Benutzerinformationen
|
||||
[key: string]: any
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Beispielaufruf
|
||||
|
||||
```ts
|
||||
const loginData: LoginData = {
|
||||
username: "IhrBenutzername",
|
||||
password: "IhrPasswort",
|
||||
}
|
||||
|
||||
postLogin(loginData)
|
||||
.then((response) => {
|
||||
console.log("Erfolgreiche Anmeldung! Token: ", response.token)
|
||||
console.log("Benutzerinformationen: ", response.user)
|
||||
})
|
||||
.catch((error) => {
|
||||
console.log("Fehler beim Login: ", error)
|
||||
})
|
||||
```
|
||||
@@ -1,99 +0,0 @@
|
||||
# `/project`
|
||||
|
||||
Dieser Endpoint bietet eine Schnittstelle für den Zugriff und die Manipulation von Projektdaten. Benutzer können Projekte erstellen, abrufen, aktualisieren und löschen.
|
||||
|
||||
## GET /project
|
||||
|
||||
Mit dieser Funktion können Sie eine Liste aller Projekte abrufen. Diese Funktion nimmt optionale Parameter an, die verwendet werden können, um die abgerufenen Projekte zu sortieren oder zu filtern.
|
||||
|
||||
Diese request ruft eine Liste aller Projekte ab. Sie kann optionale Parameter verwenden, um die abgerufenen Projekte zu sortieren oder zu filtern.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort auf diese request ist ein Objekt mit zwei Eigenschaften:
|
||||
|
||||
- `data`: Ein Array von Projekt-Objekten.
|
||||
- `count`: Die Gesamtzahl der Projekte die es gibt.
|
||||
|
||||
Jedes Projekt-Objekt hat die folgenden Eigenschaften:
|
||||
|
||||
```ts
|
||||
interface Project {
|
||||
id?: string // Eindeutiger Identifikator für das Projekt
|
||||
insertTime?: string // Zeitpunkt der Erstellung des Projekts
|
||||
updateTime?: string // Letzter Zeitpunkt der Aktualisierung des Projekts
|
||||
configFile: string // Pfad zur config.yml des Projekts
|
||||
name: string // Name des Projekts
|
||||
description: string // Beschreibung des Projekts
|
||||
users?: string[] // Array von Benutzer-IDs mit Zugriff auf das Projekt
|
||||
api?: ProjectAPI // Zusätzliche Projektinformationen
|
||||
yourPermissions?: {
|
||||
// Berechtigungen des aktuellen Benutzers für das Projekt
|
||||
[collectionName: string]: MethodPermission
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## PUT /project/{id}
|
||||
|
||||
Diese Anforderung aktualisiert ein vorhandenes Projekt. Sie nimmt die ID des zu aktualisierenden Projekts und ein Änderungsset als Parameter an. Das Änderungsset ist ein Objekt, das die zu ändernden Eigenschaften und ihre neuen Werte enthält.
|
||||
Anforderungsparameter
|
||||
|
||||
- `id`: Die ID des zu aktualisierenden Projekts.
|
||||
|
||||
- `data`: Ein Objekt, das die zu ändernden Eigenschaften und ihre neuen Werte enthält.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist das aktualisierte Project Objekt.
|
||||
|
||||
## DELETE /project/{id}
|
||||
|
||||
Diese Anforderung löscht ein vorhandenes Projekt. Sie nimmt die ID des zu löschenden Projekts als Parameter an.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
- `id`: Die ID des zu löschenden Projekts.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein Objekt mit einer message Eigenschaft, die eine Bestätigungsnachricht enthält.
|
||||
|
||||
## POST /project
|
||||
|
||||
Diese Anforderung erstellt ein neues Projekt. Sie nimmt ein Objekt als Parameter an, das die Eigenschaften des zu erstellenden Projekts enthält.
|
||||
Anforderungsparameter
|
||||
|
||||
- `data`: Ein Objekt vom typ Project.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein Objekt mit einer message Eigenschaft, die eine Bestätigungsnachricht enthält.
|
||||
|
||||
```ts
|
||||
interface MethodPermission {
|
||||
get: boolean
|
||||
post: boolean
|
||||
put: boolean
|
||||
delete: boolean
|
||||
}
|
||||
|
||||
interface ProjectPermission {
|
||||
name: string
|
||||
label: I18Text
|
||||
}
|
||||
|
||||
type ProjectImageUrl = string | EvalObject
|
||||
|
||||
interface ProjectAPI {
|
||||
isOnline: boolean
|
||||
namespace: string
|
||||
meta?: {
|
||||
imageUrl?: ProjectImageUrl
|
||||
permissions?: ProjectPermission[]
|
||||
dashboard?: Dashboard
|
||||
[key: string]: any
|
||||
}
|
||||
collections: Collection[]
|
||||
}
|
||||
```
|
||||
@@ -1,81 +0,0 @@
|
||||
# `/user`
|
||||
|
||||
Dieser Endpoint bietet eine Schnittstelle für den Zugriff und die Manipulation von Benutzerdaten. Sie können Benutzerinformationen abrufen, aktualisieren, erstellen und löschen. Jeder Benutzer wird durch eine eindeutige Benutzer-ID identifiziert.
|
||||
|
||||
## GET /user
|
||||
|
||||
Diese Anforderung ruft eine Liste aller Benutzer ab. Sie kann optionale Parameter verwenden, um die abgerufenen Benutzerdaten zu sortieren oder zu filtern.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort auf diese Anforderung ist ein Users Objekt mit folgenden Eigenschaften:
|
||||
|
||||
- `data`: Ein Array von User Objekten.
|
||||
|
||||
- `count`: Die Gesamtzahl der Benutzer.
|
||||
|
||||
Jedes User Objekt hat die folgenden Eigenschaften:
|
||||
|
||||
```ts
|
||||
interface User {
|
||||
id: string // Eindeutiger Identifikator des Benutzers
|
||||
insertTime: string // Zeitpunkt der Erstellung des Benutzers
|
||||
updateTime: string // Letzter Zeitpunkt der Aktualisierung des Benutzers
|
||||
username: string // Benutzername des Benutzers
|
||||
role: number // Rolle des Benutzers, repräsentiert durch eine Zahl
|
||||
permissions: any[] // Array von Berechtigungen des Benutzers
|
||||
meta: {
|
||||
// Zusätzliche Informationen über den Benutzer
|
||||
[key: string]: any
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## GET /user/{id}
|
||||
|
||||
Diese Anforderung ruft einen bestimmten Benutzer ab. Sie nimmt die ID des abzurufenden Benutzers als Parameter an.
|
||||
Anforderungsparameter
|
||||
|
||||
- `id`: Die ID des abzurufenden Benutzers.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist das entsprechende User Objekt.
|
||||
|
||||
## POST /user
|
||||
|
||||
Diese Anforderung erstellt einen neuen Benutzer. Sie nimmt ein Objekt als Parameter an, das die Eigenschaften des zu erstellenden Benutzers enthält.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
- `data`: Ein Objekt, das die Eigenschaften des zu erstellenden Benutzers enthält.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein Objekt, das das neu erstellte User Objekt enthält.
|
||||
|
||||
## PUT /user/{id}
|
||||
|
||||
Diese Anforderung aktualisiert die Daten eines vorhandenen Benutzers. Sie nimmt die ID des zu aktualisierenden Benutzers und ein Objekt, das die zu aktualisierenden Daten enthält, als Parameter an.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
- `id`: Die ID des zu aktualisierenden Benutzers.
|
||||
|
||||
- `data`: Ein Objekt, das die zu aktualisierenden Daten enthält.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein Objekt, das das aktualisierte User Objekt enthält.
|
||||
|
||||
## DELETE /user/{id}
|
||||
|
||||
Diese Anforderung löscht einen vorhandenen Benutzer. Sie nimmt die ID des zu löschenden Benutzers als Parameter an.
|
||||
|
||||
### Anforderungsparameter
|
||||
|
||||
`id`: Die ID des zu löschenden Benutzers.
|
||||
|
||||
### Antwort
|
||||
|
||||
Die Antwort ist ein boolean, das true zurückgibt, wenn das Löschen erfolgreich war.
|
||||
@@ -1,71 +0,0 @@
|
||||
Das HookContext-Interface bietet ein zentrales Objekt, um Zugang zu verschiedenen Attributen und Paketen zu erhalten. Es wird als context in den Hooks des tibi-server genutzt und stellt wichtige Funktionalitäten zur Verfügung, die zur Manipulation der Daten und Abläufe in den HTTP-Methoden und Schritten der API benötigt werden.
|
||||
|
||||
Das HookContext-Interface setzt sich aus mehreren Schnittstellen zusammen, darunter GetHookData, GetHookGetOnlyData, PostHookData, JobData, request und mehrere third-party Pakete. Hierbei sind mit ausnahme von den request und den third-party-paketen attributen alle attribute direkt auf dem context Objekt vorhanden. Request ist eine funktion die ihre Objekte zurückgibt und ist somit rechenaufwendig. Daher ist es ratsam bei mehrfacher nutzung des request attributs, sich den Wert in einer variable zwischen zu speichern. Die Attribute auf den paketen werden über context.paketname.attribut aufgerufen.
|
||||
|
||||
## GetHookData
|
||||
|
||||
Das GetHookData-Interface enthält Attribute, die spezifisch für die Manipulation von GET-Anfragen in den Hooks sind:
|
||||
|
||||
- `filter`: Ein Filter-Objekt, das die Anfragebedingungen für die zu abrufenden Dokumente enthält.
|
||||
- `selector`: Ein Selektor-Objekt, das festlegt, welche Felder in den zurückgegebenen Dokumenten enthalten sein sollten.
|
||||
- `offset`: Ein numerischer Wert, der den Startpunkt für die Rückgabe von Dokumenten festlegt.
|
||||
- `limit` Ein numerischer Wert, der die maximale Anzahl von Dokumenten festlegt, die zurückgegeben werden sollen.
|
||||
- `sort`: Ein String oder ein Array von Strings, der die Sortierreihenfolge der zurückgegebenen Dokumente bestimmt.
|
||||
- `pipelineMod`: Eine Funktion, die es ermöglicht, die MongoDB-Abfragepipeline zu modifizieren.
|
||||
|
||||
## PostHookData Interface
|
||||
|
||||
Das PostHookData-Interface enthält ein Attribut, das speziell für POST- und PUT-Hooks relevant ist:
|
||||
|
||||
`data`: Das Dokument oder die Daten, die gesendet wurden. Dies ist ein CollectionDocument-Objekt und wird in die Datenbank geschrieben. Will man den Datenbankeinträge im hook also modifizieren, so muss dieses Objekt modifiziert werden. Mann muss dieses Objekt idealerweise also einfach modifiziert in dem HookResponse data attribut abspeichern, dies wird nämlich zwischen allen Hooks immer ausgetauscht. Demzufolge ist das veränderte data Objekt dann auch so im nächsten Hook verfügbar.
|
||||
|
||||
## JobConfig und JobData Interfaces
|
||||
|
||||
Das JobConfig-Interface definiert die Konfiguration für einen Cron-Job, diese ist jene Konfig die im zugehörigen yaml definiert wurde:
|
||||
|
||||
- `meta`: Ein Metadatenobjekt.
|
||||
- `cron`: Ein String, der die Cron-Job-Intervallspezifikation enthält.
|
||||
- `type`: Der Typ des Jobprogramms. Derzeit wird nur "javascript" unterstützt.
|
||||
- `file`: Der Pfad zur Datei des Jobprogramms.
|
||||
|
||||
Das JobData-Interface enthält ein job-Attribut, das ein JobConfig-Objekt ist und die Konfiguration des aktuellen Jobs repräsentiert.
|
||||
|
||||
## request
|
||||
|
||||
Die request Funktion liefert ein Objekt zurück, das Informationen über die HTTP-Anfrage enthält:
|
||||
|
||||
- `method`: Die HTTP-Methode der Anfrage (GET, POST, PUT, DELETE etc.).
|
||||
- `remoteAddr`: Die remote IP-Adresse der Anfrage.
|
||||
- `clientIp()`: Funktion zum Abrufen der Client-IP-Adresse der Anfrage.
|
||||
- `host`: Der Host der Anfrage.
|
||||
- `url`: Die vole URL der Anfrage.
|
||||
- `path`: Der Pfad der Anfrage.
|
||||
- `param(p: string)`: Funktion zum Abrufen von URL-Parametern.
|
||||
- `query(q: string`: Funktion zum Abrufen von URL-Abfrageparametern.
|
||||
- `header(h: string)`: Funktion zum Abrufen von HTTP-Headern.
|
||||
- `body()`: Funktion zum Abrufen des HTTP-Body.
|
||||
- `bodyBytes()`: Funktion zum Abrufen des HTTP-Body als byte array. Wird z.B. für die Umwandlung von iso8859 zu utf8 genutzt.
|
||||
|
||||
## Pakete
|
||||
|
||||
Jedes der folgenden Attribute ist ein Paket, das spezifische Funktionen bereitstellt:
|
||||
|
||||
- `db`: Stellt Funktionen zur Interaktion mit der Datenbank zur Verfügung (DbPackage).
|
||||
- `smtp`: Bietet Funktionen zum Senden von E-Mails (SmtpPackage).
|
||||
- `fs`: Bietet Funktionen zum Interagieren mit dem Dateisystem (FsPackage).
|
||||
- `tpl`: Stellt Funktionen zum Arbeiten mit Templates zur Verfügung (TplPackage).
|
||||
- `http`: Bietet Funktionen zum Senden von HTTP-Anfragen (HttpPackage).
|
||||
- `debug`: Stellt Funktionen zum Debuggen zur Verfügung (DebugPackage).
|
||||
- `response`: Bietet Funktionen zur Manipulation der HTTP-Antwort (ResponsePackage).
|
||||
- `user`: Bietet Funktionen zum Arbeiten mit Benutzern (UserPackage).
|
||||
- `bcrypt`: Stellt Funktionen zum Hashen und Überprüfen von Passwörtern zur Verfügung (BcryptPackage)`
|
||||
- `jwt`: Bietet Funktionen zum Arbeiten mit JSON Web Tokens (JwtPackage).
|
||||
- `charset`: Bietet Funktionen zur Arbeit mit Zeichensätzen (CharsetPackage).
|
||||
- `image`: Bietet Funktionen zur Arbeit mit Bildern (ImagePackage).
|
||||
- `xml`: Stellt Funktionen zum Arbeiten mit XML-Daten zur Verfügung (XmlPackage).
|
||||
- `cookie`: Bietet Funktionen zum Arbeiten mit Cookies (CookiePackage).
|
||||
- `pdf`: Bietet Funktionen zum Arbeiten mit PDF-Dokumenten (PdfPackage).
|
||||
- `crypt`: Bietet Funktionen für Kryptografie (CryptoPackage).
|
||||
- `json`: Bietet Funktionen zum Arbeiten mit JSON-Daten (JsonPackage).
|
||||
|
||||
Diese Pakete erweitern die Möglichkeiten des Context Objektes und ermöglichen es, eine Vielzahl von Aufgaben auszuführen. Für detaillierte Informationen zu jedem Paket, siehe die spezifische Dokumentation des jeweiligen Pakets.
|
||||
@@ -1,34 +0,0 @@
|
||||
## bcrypt
|
||||
|
||||
Das BcryptPackage-Interface bietet Funktionen zur Passworthashing und -überprüfung mit dem bcrypt-Algorithmus. Es beinhaltet folgende Methoden:
|
||||
|
||||
- `hash(password: string, options?: {}: string`:
|
||||
Diese Methode nimmt ein Klartextpasswort und optionale Hashing-Optionen entgegen und gibt das gehashte Passwort zurück. Die Optionen können den "cost"-Parameter steuern, der die Komplexität des Hashings bestimmt.
|
||||
|
||||
- `check(password: string, hash: string): boolean`:
|
||||
Diese Methode nimmt ein Klartextpasswort und ein gehashtes Passwort entgegen und gibt zurück, ob das Klartextpasswort nach dem Hashing mit dem gehashten Passwort übereinstimmt.
|
||||
|
||||
```ts
|
||||
interface BcryptPackage {
|
||||
/**
|
||||
* hash password via bcrypt algo
|
||||
*
|
||||
* @param password clear text password
|
||||
* @param options hashing options
|
||||
*/
|
||||
hash(
|
||||
password: string,
|
||||
options?: {
|
||||
cost?: number
|
||||
}
|
||||
): string
|
||||
|
||||
/**
|
||||
* check password against hashed password via bcrypt algo
|
||||
*
|
||||
* @param password clear text password
|
||||
* @param hash hashed password
|
||||
*/
|
||||
check(password: string, hash: string): boolean
|
||||
}
|
||||
```
|
||||
@@ -1,17 +0,0 @@
|
||||
## charset
|
||||
|
||||
Das CharsetPackage-Interface bietet Funktionen zur Zeichensatzkonvertierung. Es enthält folgende Methode:
|
||||
|
||||
- `iso8859ToUtf8(iso8859: string): string`:
|
||||
Diese Methode nimmt einen String im ISO-8859-Zeichensatz entgegen und konvertiert ihn in den UTF-8-Zeichensatz. Dies kann verwendet werden, um Kompatibilität zwischen verschiedenen Systemen und Standards zu gewährleisten.
|
||||
|
||||
```ts
|
||||
interface CharsetPackage {
|
||||
/**
|
||||
* convert iso8859 to utf8
|
||||
*
|
||||
* @param iso8859 iso string
|
||||
*/
|
||||
iso8859ToUtf8(iso8859: string): string
|
||||
}
|
||||
```
|
||||
@@ -1,39 +0,0 @@
|
||||
## cookie
|
||||
|
||||
Das CookiePackage-Interface bietet Funktionen zur Verwaltung von HTTP-Cookies. Es beinhaltet folgende Methoden:
|
||||
|
||||
- `get(name: string): string`:
|
||||
Diese Methode nimmt den Namen eines Cookies entgegen und gibt den Wert dieses Cookies zurück.
|
||||
|
||||
- `set(name: string, value: string, options?: {}): void`:
|
||||
Diese Methode nimmt den Namen und den Wert eines Cookies sowie optionale Cookie-Optionen entgegen und setzt das Cookie. Die Optionen können das Ablaufdatum, den Pfad, die Domain und die Secure- und HttpOnly-Flags steuern.
|
||||
|
||||
```ts
|
||||
interface CookiePackage {
|
||||
/**
|
||||
* get cookie from http header
|
||||
*
|
||||
* @param name cookie name
|
||||
*/
|
||||
get(name: string): string
|
||||
|
||||
/**
|
||||
* set cookie via http header
|
||||
*
|
||||
* @param name cookie name
|
||||
* @param value cookie value
|
||||
* @param options cookie options
|
||||
*/
|
||||
set(
|
||||
name: string,
|
||||
value: string,
|
||||
options?: {
|
||||
maxAge?: number
|
||||
path?: string
|
||||
domain?: string
|
||||
secure?: boolean
|
||||
httpOnly?: boolean
|
||||
}
|
||||
): void
|
||||
}
|
||||
```
|
||||
@@ -1,87 +0,0 @@
|
||||
## db
|
||||
|
||||
Das Database (Db) Paket stellt Methoden bereit, um Operationen auf einer Datenbank auszuführen. Es umfasst die folgenden Hauptmethoden:
|
||||
|
||||
- `find(colName: string, options?: DbReadOptions): CollectionDocument[]`:
|
||||
Diese Methode ermöglicht das Suchen von Dokumenten in einer bestimmten Sammlung basierend auf den bereitgestellten Optionen.
|
||||
|
||||
- `count(colName: string, options?: DbReadOptions): number`:
|
||||
Diese Methode gibt die Anzahl der Dokumente in einer bestimmten Sammlung zurück, die den Optionen entsprechen.
|
||||
|
||||
- `update(colName: string, id: string, data: CollectionDocument): CollectionDocument:`:
|
||||
Diese Methode aktualisiert das Dokument in einer bestimmten Sammlung, welches die angegebene ID besitzt.
|
||||
|
||||
- `delete(colName: string, id: string): { message: "ok" }:`:
|
||||
Diese Methode entfernt ein Dokument aus einer bestimmten Sammlung, das die angegebene ID besitzt.
|
||||
- `deleteMany(colName: string, options?: DbReadOptions): { message: "ok"; removed: number }:`
|
||||
Diese Methode entfernt mehrere Dokumente aus einer bestimmten Sammlung, die den bereitgestellten Optionen entsprechen.
|
||||
|
||||
- `create(colName: string, data: CollectionDocument): CollectionDocument`
|
||||
Diese Methode fügt ein neues Dokument in eine bestimmte Sammlung ein.
|
||||
|
||||
```ts
|
||||
interface DbPackage {
|
||||
/**
|
||||
* read results from a collection
|
||||
*
|
||||
* @param colName collection name
|
||||
* @param options options map
|
||||
*/
|
||||
find(colName: string, options?: DbReadOptions): CollectionDocument[]
|
||||
|
||||
/**
|
||||
* read count of documents for filter from a collection
|
||||
*
|
||||
* @param colName collection name
|
||||
* @param options options map (only filter is valid)
|
||||
*/
|
||||
count(colName: string, options?: DbReadOptions): number
|
||||
|
||||
/**
|
||||
* create a document in a collection
|
||||
*
|
||||
* @param colName collection name
|
||||
* @param data data map
|
||||
*/
|
||||
create(colName: string, data: CollectionDocument): CollectionDocument
|
||||
|
||||
/**
|
||||
* update a document in a collection
|
||||
*
|
||||
* @param colName collection name
|
||||
* @param id id of entry
|
||||
* @param data new/changed data
|
||||
*/
|
||||
update(colName: string, id: string, data: CollectionDocument): CollectionDocument
|
||||
|
||||
/**
|
||||
* deletes one document by id from collection
|
||||
*
|
||||
* @param colName collection name
|
||||
* @param id id of entry
|
||||
*/
|
||||
delete(colName: string, id: string): { message: "ok" }
|
||||
|
||||
/**
|
||||
* deletes documents by filter from collection
|
||||
*
|
||||
* @param colName collection name
|
||||
* @param options options map, only filter valid
|
||||
*/
|
||||
deleteMany(colName: string, options?: DbReadOptions): { message: "ok"; removed: number }
|
||||
}
|
||||
|
||||
interface DbReadOptions {
|
||||
filter?: {
|
||||
[key: string]: any
|
||||
}
|
||||
selector?: {
|
||||
[key: string]: any
|
||||
}
|
||||
projection?: string
|
||||
offset?: number
|
||||
limit?: number
|
||||
sort?: string[]
|
||||
pipelineMod?: (pipe: { [key: string]: any }[]) => { [key: string]: any }[]
|
||||
}
|
||||
```
|
||||
@@ -1,25 +0,0 @@
|
||||
## debug
|
||||
|
||||
Das DebugPackage-Interface bietet Funktionen zur Fehlersuche. Es enthält folgende Methoden:
|
||||
|
||||
- `dump(...toDump): any`:
|
||||
void: Diese Methode nimmt eine oder mehrere Datenvariablen entgegen und schreibt diese Daten sowohl in den Server-Log als auch in den Header. Dies kann zur Fehlersuche und -behebung verwendet werden.
|
||||
|
||||
- `sentryTraceId(): string`:
|
||||
Diese Methode gibt die ID des aktuellen Sentry-Trace zurück, der zur Überwachung und Nachverfolgung von Fehlern verwendet werden kann.
|
||||
|
||||
```ts
|
||||
interface DebugPackage {
|
||||
/**
|
||||
* dumps data to header and server log
|
||||
*
|
||||
* @param toDump data to dump
|
||||
*/
|
||||
dump(...toDump: any): void
|
||||
|
||||
/**
|
||||
* get Sentry trace id
|
||||
*/
|
||||
sentryTraceId(): string
|
||||
}
|
||||
```
|
||||
@@ -1,93 +0,0 @@
|
||||
## fs
|
||||
|
||||
Das FsPackage-Interface bietet Funktionen zur Datei- und Verzeichnisverwaltung. Es beinhaltet folgende Methoden:
|
||||
|
||||
- `configDir(): string`:
|
||||
Diese Methode gibt den Pfad zum Verzeichnis der API-Konfigurationsdatei zurück.
|
||||
|
||||
- `readFile(path: string, options?: {}): string | any`:
|
||||
Diese Methode nimmt einen relativen Pfad zu einer Datei und optionale Leseoptionen entgegen und gibt den Inhalt dieser Datei zurück. Die Optionen können steuern, ob der Inhalt als Byte-Array oder als Zeichenkette zurückgegeben wird.
|
||||
|
||||
- `writeFile(path: string, data: string | any): null`:
|
||||
Diese Methode nimmt einen relativen Pfad zu einer Datei und Daten entgegen und schreibt diese Daten in die Datei.
|
||||
|
||||
- `stat(path: string): {}`:
|
||||
Diese Methode nimmt einen Pfad zu einer Datei oder einem Verzeichnis entgegen und gibt Informationen über diese Datei oder dieses Verzeichnis zurück.
|
||||
|
||||
- `readDir(path: string): {}[]`:
|
||||
Diese Methode nimmt einen Pfad zu einem Verzeichnis entgegen und gibt eine Liste der darin enthaltenen Dateien und Verzeichnisse zurück.
|
||||
|
||||
- `mkDir(path: string): void`:
|
||||
Diese Methode nimmt einen Pfad entgegen und erstellt an diesem Ort ein neues Verzeichnis.
|
||||
|
||||
- `remove(path: string): void`:
|
||||
Diese Methode nimmt einen Pfad entgegen und löscht die Datei oder das leere Verzeichnis an diesem Pfad.
|
||||
|
||||
```ts
|
||||
interface FsPackage {
|
||||
/**
|
||||
* get directory path of api config file
|
||||
*
|
||||
*/
|
||||
configDir(): string
|
||||
|
||||
/**
|
||||
* read a file relative to config dir and return its content
|
||||
*
|
||||
* @param path relative file path
|
||||
* @param options optional options
|
||||
*/
|
||||
readFile(
|
||||
path: string,
|
||||
options?: {
|
||||
bytes: boolean // if true return []byte instead of string
|
||||
}
|
||||
): string | any
|
||||
|
||||
/**
|
||||
* write data to a file relative to config dir
|
||||
*
|
||||
* @param path relative file path
|
||||
* @param data string or []byte data
|
||||
*/
|
||||
writeFile(path: string, data: string | any): null
|
||||
|
||||
/**
|
||||
* stat file or directory
|
||||
*
|
||||
* @param path
|
||||
*/
|
||||
stat(path: string): {
|
||||
name: string
|
||||
size: number
|
||||
isDir: boolean
|
||||
modTime: string
|
||||
}
|
||||
|
||||
/**
|
||||
* list directory entries
|
||||
*
|
||||
* @param path
|
||||
*/
|
||||
readDir(path: string): {
|
||||
name: string
|
||||
size: number
|
||||
isDir: boolean
|
||||
modTime: string
|
||||
}[]
|
||||
|
||||
/**
|
||||
* make directory and all missing sub directories, no error if directory already exists
|
||||
*
|
||||
* @param path
|
||||
*/
|
||||
mkDir(path: string): void
|
||||
|
||||
/**
|
||||
* remove file or empty directory
|
||||
*
|
||||
* @param path
|
||||
*/
|
||||
remove(path: string): void
|
||||
}
|
||||
```
|
||||
@@ -1,37 +0,0 @@
|
||||
## http
|
||||
|
||||
Das HttpPackage-Interface bietet Funktionen zum Senden von HTTP-Anfragen. Es enthält die folgende Methode:
|
||||
|
||||
- `fetch(url: string, options?: {}): {}`:
|
||||
Diese Methode nimmt eine URL und optionale Anforderungsoptionen entgegen und sendet eine HTTP-Anfrage an die angegebene URL. Die Optionen können die HTTP-Methode, Header, den Body und das Timeout steuern. Die Methode gibt ein Objekt zurück, das den Status, den StatusText, die Header, den Trailer, die URL und den Body der Antwort enthält.
|
||||
|
||||
```ts
|
||||
interface HttpPackage {
|
||||
/**
|
||||
* http request
|
||||
*
|
||||
* @param url url for request
|
||||
* @param options request options
|
||||
*/
|
||||
fetch(
|
||||
url: string,
|
||||
options?: {
|
||||
method?: string
|
||||
headers?: { [key: string]: string }
|
||||
body?: string
|
||||
// timeout in seconds
|
||||
timeout?: number
|
||||
}
|
||||
): {
|
||||
status: number
|
||||
statusText: string
|
||||
headers: { [key: string]: string }
|
||||
trailer: { [key: string]: string }
|
||||
url: string
|
||||
body: {
|
||||
text(): string
|
||||
json(): any
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,39 +0,0 @@
|
||||
## image
|
||||
|
||||
ImagePackage Interface
|
||||
|
||||
Das ImagePackage-Interface bietet Funktionen zur Bildmanipulation. Es enthält folgende Methode:
|
||||
|
||||
- `filter(sourceFile: string, targetFile: string, filters: {}[]): void`:
|
||||
Diese Methode nimmt den Pfad zur Quellbilddatei, den Pfad zur Zieldatei und eine Reihe von Filtern entgegen und wendet diese Filter auf das Bild an. Die Filter können Aspekte des Bildes wie Größe, Helligkeit, Sättigung, Kontrast, Gamma, Unschärfe, Schärfe, Inversion, Graustufen und Qualität steuern.
|
||||
|
||||
```ts
|
||||
interface ImagePackage {
|
||||
/**
|
||||
* convert image from source file to target file with filters
|
||||
*
|
||||
* @param sourceFile
|
||||
* @param targetFile
|
||||
* @param filters
|
||||
*/
|
||||
filter(
|
||||
sourceFile: string,
|
||||
targetFile: string,
|
||||
filters: {
|
||||
fit?: boolean
|
||||
fill?: boolean
|
||||
width?: number
|
||||
height?: number
|
||||
brightness?: number
|
||||
saturation?: number
|
||||
contrast?: number
|
||||
gamma?: number
|
||||
blur?: number
|
||||
sharpen?: number
|
||||
invert?: boolean
|
||||
grayscale?: boolean
|
||||
quality?: number
|
||||
}[]
|
||||
): void
|
||||
}
|
||||
```
|
||||
@@ -1,59 +0,0 @@
|
||||
## jwt
|
||||
|
||||
JwtPackage Interface
|
||||
|
||||
Das JwtPackage-Interface bietet Funktionen zum Erstellen und Analysieren von JWT (JSON Web Token). Es enthält folgende Methoden:
|
||||
|
||||
- `create(claims: { [key: string]: any }, options?: { secret?: string, validityDuration?: number }): string`:
|
||||
Diese Methode nimmt ein claims-Objekt und optionale Einstellungen entgegen und gibt einen signierten JWT-String zurück. Mit dieser Methode können Sie JWTs erstellen, die Daten enthalten und mit einem geheimen Schlüssel signiert sind.
|
||||
|
||||
- `parse(token: string, options?: { secret?: string }): { error?: string, valid: boolean, method: { Name: string, Hash: number }, header: { alg: string, typ: string }, claims: { exp?: number, [key: string]: any } }`:
|
||||
Diese Methode nimmt einen JWT-String und Einstellungen entgegen, welche den Token secret beeinhalten, und gibt ein Objekt zurück, das Informationen über den Token enthält. Mit dieser Methode können Sie JWTs analysieren und die in ihnen enthaltenen Daten extrahieren.
|
||||
|
||||
```ts
|
||||
interface JwtPackage {
|
||||
/**
|
||||
* create a jwt signed token string
|
||||
*
|
||||
* @param claims data object
|
||||
* @param options options (secret, validityDuration = expiry in X seconds)
|
||||
*/
|
||||
create(
|
||||
claims: {
|
||||
[key: string]: any
|
||||
},
|
||||
options?: {
|
||||
secret?: string
|
||||
validityDuration?: number
|
||||
}
|
||||
): string
|
||||
|
||||
/**
|
||||
* parse jwt token string
|
||||
*
|
||||
* @param token token string
|
||||
* @param options options (secret)
|
||||
*/
|
||||
parse(
|
||||
token: string,
|
||||
options?: {
|
||||
secret?: string
|
||||
}
|
||||
): {
|
||||
error?: string
|
||||
valid: boolean
|
||||
method: {
|
||||
Name: string
|
||||
Hash: number
|
||||
}
|
||||
header: {
|
||||
alg: string
|
||||
typ: string
|
||||
}
|
||||
claims: {
|
||||
exp?: number
|
||||
[key: string]: any
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,113 +0,0 @@
|
||||
## pdf
|
||||
|
||||
PdfPackage Interface
|
||||
|
||||
Das PdfPackage-Interface bietet Funktionen zur Erzeugung und Manipulation von PDF-Dateien. Es enthält folgende Methoden:
|
||||
|
||||
- `fromHTML(html: string, options?: {}): an`:
|
||||
Diese Methode nimmt einen HTML-String und optionale Einstellungen entgegen und gibt die binären Daten eines PDF-Dokuments zurück. Mit dieser Methode können Sie ein PDF-Dokument aus HTML-Inhalten erstellen. Die optionalen Einstellungen ermöglichen es Ihnen, verschiedene Aspekte des PDF-Dokuments zu steuern, einschließlich der Ausrichtung, Seitengröße, Ränder, Kopf- und Fußzeilen und vieles mehr.
|
||||
|
||||
- `cpu(command: "watermark" | "stamp" | "merge" | "rotate" | "create", pdfData: any | any[], options?: {}): any`:
|
||||
Diese Methode nimmt einen Befehl, PDF-Daten und optionale Einstellungen entgegen und gibt die binären Daten eines neuen PDF-Dokuments zurück. Mit dieser Methode können Sie verschiedene Operationen auf einem oder mehreren PDF-Dokumenten durchführen, einschließlich:
|
||||
|
||||
- `watermark`: Fügen Sie ein Wasserzeichen zum PDF hinzu.
|
||||
- `stamp`: Fügen Sie einen Stempel zum PDF hinzu.
|
||||
- `merge`: Kombinieren Sie mehrere PDF-Dokumente zu einem.
|
||||
- `rotate`: Drehen Sie Seiten im PDF.
|
||||
- `create`: Erstellen Sie ein neues PDF.
|
||||
|
||||
Die pdfData-Parameter können die binären Daten eines einzelnen PDF-Dokuments, ein Array von PDF-Dokumenten (zum Zusammenführen) oder ein Objekt mit einer Beschreibung (zum Erstellen) enthalten. Die optionalen Einstellungen variieren je nach Befehl und ermöglichen es Ihnen, verschiedene Aspekte der Operation zu steuern.
|
||||
|
||||
```ts
|
||||
interface PdfPackage {
|
||||
/**
|
||||
* generate pdf from html
|
||||
*
|
||||
* @param html html string
|
||||
* @param options options
|
||||
*
|
||||
* @returns []byte of pdf data
|
||||
*/
|
||||
fromHTML(
|
||||
html: string,
|
||||
options?: {
|
||||
copies?: number // Number of copies to print into the pdf file (default 1)
|
||||
dpi?: number // Change the dpi explicitly (this has no effect on X11 based systems)
|
||||
grayscale?: boolean // PDF will be generated in grayscale
|
||||
imageDpi?: number // When embedding images scale them down to this dpi (default 600)
|
||||
imageQuality?: number // When jpeg compressing images use this quality (default 94)
|
||||
lowQuality?: boolean // Generates lower quality pdf/ps. Useful to shrink the result document space
|
||||
marginBottom?: number // Set the page bottom margin
|
||||
marginLeft?: number // Set the page left margin (default 10mm)
|
||||
marginRight?: number // Set the page right margin (default 10mm)
|
||||
marginTop?: number // Set the page top margin
|
||||
noCollate?: boolean // Do not collate when printing multiple copies (default collate)
|
||||
noPdfCompression?: boolean // Do not use lossless compression on pdf objects
|
||||
orientation?: "Portrait" | "Landscape" // Set orientation to Landscape or Portrait (default Portrait)
|
||||
pageHeight?: number // Page height
|
||||
pageSize?: string // Set paper size to: A4, Letter, etc. (default A4)
|
||||
pageWidth?: number // Page width
|
||||
title?: string // The title of the generated pdf file (The title of the first document is used if not specified)
|
||||
// page settings
|
||||
printMediaType?: boolean // Use print media-type instead of screen
|
||||
footerCenter?: string // Centered footer text
|
||||
footerFontName?: string // Set footer font name (default Arial)
|
||||
footerFontSize?: number // Set footer font size (default 12)
|
||||
footerLeft?: string // Left aligned footer text
|
||||
footerLine?: boolean // Display line above the footer
|
||||
footerRight?: string // Right aligned footer text
|
||||
footerSpacing?: number // Spacing between footer and content in mm (default 0)
|
||||
footerHTML?: string // URL to footer html
|
||||
headerCenter?: string // Centered header text
|
||||
headerFontName?: string // Set header font name (default Arial)
|
||||
headerFontSize?: number // Set header font size (default 12)
|
||||
headerLeft?: string // Left aligned header text
|
||||
headerLine?: boolean // Display line below the header
|
||||
headerRight?: string // Right aligned header text
|
||||
headerSpacing?: number // Spacing between header and content in mm (default 0)
|
||||
headerHTML?: string // URL to header html
|
||||
}
|
||||
): any
|
||||
|
||||
/**
|
||||
* process existing pdf data
|
||||
*
|
||||
* @param command pdfcpu command
|
||||
* @param pdfData []byte of pdf data, multiple []byte as array of pdf's to merge or object with description to create
|
||||
* @param options options
|
||||
*
|
||||
* @returns []byte of new pdf data
|
||||
*/
|
||||
cpu(
|
||||
command: "watermark" | "stamp" | "merge" | "rotate" | "create",
|
||||
pdfData: any | any[],
|
||||
options?: {
|
||||
pages?: (string | number)[]
|
||||
description?: {
|
||||
fontname?: string
|
||||
points?: number
|
||||
rtl?: boolean
|
||||
position?: "full" | "tl" | "tc" | "tr" | "l" | "c" | "r" | "bl" | "bc" | "br"
|
||||
offset?: string
|
||||
scalefactor?: number | string
|
||||
aligntext?: "left" | "center" | "right" | "justified"
|
||||
strokecolor?: string
|
||||
fillcolor?: string
|
||||
backgroundcolor?: string
|
||||
rotation?: number
|
||||
diagonal?: 1 | 2
|
||||
opacity?: number
|
||||
rendermode?: 0 | 1 | 2
|
||||
margins?: number | string
|
||||
border?: number | string
|
||||
url?: string
|
||||
}
|
||||
mode?: "text" | "image" | "pdf"
|
||||
bytes?: any // []byte of watermark image
|
||||
file?: string // file for pdf watermark
|
||||
text?: string // text for text watermark
|
||||
rotation?: number
|
||||
}
|
||||
): any
|
||||
}
|
||||
```
|
||||
@@ -1,18 +0,0 @@
|
||||
## image
|
||||
|
||||
Das ResponsePackage-Interface bietet Funktionen zur Manipulation von HTTP-Antwort-Headern. Es enthält die folgende Methode:
|
||||
|
||||
- `header(name: string, value: any): void`:
|
||||
Diese Methode nimmt den Namen und den Wert eines Headers entgegen und setzt diesen Header in der HTTP-Antwort.
|
||||
|
||||
```ts
|
||||
interface ResponsePackage {
|
||||
/**
|
||||
* set response header
|
||||
*
|
||||
* @param name header name
|
||||
* @param value value
|
||||
*/
|
||||
header(name: string, value: any): void
|
||||
}
|
||||
```
|
||||
@@ -1,32 +0,0 @@
|
||||
## smtp
|
||||
|
||||
Das Smtp-Paket ermöglicht das Senden von E-Mails. Es stellt eine sendMail Methode zur Verfügung, die eine E-Mail an einen oder mehrere Empfänger sendet. Die Methode nimmt eine Reihe von Parametern, einschließlich des SMTP-Hosts, des Benutzernamens und Passworts für die Authentifizierung, der Empfängeradressen, des Betreffs, des Absenders und der Nachricht, sowie optionaler Anhänge, entgegen.
|
||||
Das SmtpPackage-Interface bietet Funktionen zum Senden von E-Mails. Es enthält die folgende Methode:
|
||||
|
||||
- `sendMail(options: {}): void`:
|
||||
Diese Methode nimmt eine Reihe von Optionen für das Senden einer E-Mail entgegen und sendet die E-Mail entsprechend diesen Optionen. Die Optionen können den SMTP-Host, den Benutzernamen und das Passwort für die Authentifizierung, die Empfänger, den Betreff, den Absender und den Inhalt der E-Mail sowie optionale Anhänge steuern.
|
||||
|
||||
```ts
|
||||
interface SmtpPackage {
|
||||
/**
|
||||
* send an email
|
||||
*
|
||||
* @param options email options map
|
||||
*/
|
||||
sendMail(options: {
|
||||
host?: string
|
||||
username?: string
|
||||
password?: string
|
||||
to: string | string[]
|
||||
cc?: string | string[]
|
||||
bcc?: string | string[]
|
||||
subject?: string
|
||||
from: string
|
||||
fromName?: string
|
||||
replyTo?: string
|
||||
plain?: string
|
||||
html?: string
|
||||
attach?: string | string[]
|
||||
}): void
|
||||
}
|
||||
```
|
||||
@@ -1,23 +0,0 @@
|
||||
## tpl
|
||||
|
||||
Das TplPackage-Interface bietet Funktionen zur Ausführung von Template-Code. Es enthält folgende Methode:
|
||||
|
||||
`execute(code: string, contextData?: { [key: string]: any }): string`:
|
||||
Diese Methode nimmt einen Template-Code und optionale Kontextdaten entgegen und gibt das Ergebnis der Template-Ausführung als String zurück. Mit dieser Methode können Sie dynamischen Code ausführen und das Ergebnis in Ihrem Programm verwenden. Genutzt wird dies meist um E-Mail templates zu rendern.
|
||||
|
||||
```ts
|
||||
interface TplPackage {
|
||||
/**
|
||||
* execute a template code and return result
|
||||
*
|
||||
* @param code template code
|
||||
* @param contextData template context map
|
||||
*/
|
||||
execute(
|
||||
code: string,
|
||||
contextData?: {
|
||||
[key: string]: any
|
||||
}
|
||||
): string
|
||||
}
|
||||
```
|
||||
@@ -1,20 +0,0 @@
|
||||
## user
|
||||
|
||||
Das UserPackage-Interface bietet Funktionen zur Arbeit mit den Informationen des derzeit authentifizierten Benutzers. Es enthält die folgende Methode:
|
||||
|
||||
- `auth(): {}`:
|
||||
Diese Methode gibt ein Objekt zurück, das die ID, den Benutzernamen, die Rolle und die Berechtigungen des derzeit authentifizierten Benutzers enthält. Es ist wichtig zu beachten, dass diese Informationen nur dann verfügbar sind, wenn der Benutzer authentifiziert ist.
|
||||
|
||||
```ts
|
||||
interface UserPackage {
|
||||
/**
|
||||
* get JWT authentication
|
||||
*/
|
||||
auth(): {
|
||||
id: string
|
||||
username: string
|
||||
role: number
|
||||
permissions: string[]
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,29 +0,0 @@
|
||||
## xml
|
||||
|
||||
Das XmlPackage-Interface bietet Funktionen zum Erstellen und Analysieren von XML-Strings. Es enthält folgende Methoden:
|
||||
|
||||
- `create(data: any, options?: {}): string`:
|
||||
Diese Methode nimmt ein Objekt oder ein Array als Daten sowie optionale Einstellungen entgegen und gibt einen XML-String zurück. Mit dieser Methode können Sie beispielsweise ein JavaScript-Objekt oder -Array in einen XML-String umwandeln.
|
||||
|
||||
- `parse(xml: string, options?: {}): any`:
|
||||
Diese Methode nimmt einen XML-String und optionale Einstellungen entgegen und gibt ein JavaScript-Objekt zurück. Mit dieser Methode können Sie XML-Strings analysieren und in ein Format umwandeln, das in JavaScript leichter zu handhaben ist.
|
||||
|
||||
```ts
|
||||
interface XmlPackage {
|
||||
/**
|
||||
* create xml string
|
||||
*
|
||||
* @param data object or array
|
||||
* @param options options
|
||||
*/
|
||||
create(data: any, options?: {}): string
|
||||
|
||||
/**
|
||||
* parse xml string to json
|
||||
*
|
||||
* @param xml xml string
|
||||
* @param options options
|
||||
*/
|
||||
parse(xml: string, options?: {}): any
|
||||
}
|
||||
```
|
||||
@@ -1,26 +0,0 @@
|
||||
# Entitäten
|
||||
|
||||
## Projekt
|
||||
|
||||
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](../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.
|
||||
|
||||
## Benutzer
|
||||
|
||||
Im Tibi gibt es 3 Benutzerarten:
|
||||
|
||||
- `admin`: Zugriff auf alle Projekte & alle Berechtigungen auf diesen Projekten.
|
||||
- `editor`: Zugrff auf jene Projekte, denen er zugeordnet wird.
|
||||
- `user`: Kein Zugriff auf Tibi admin Oberfläche, jedoch über API auf jene Projekte, denen er zu gewiesen wurde und in den jeweiligen Collections jene Berechtigungen, die er über das Permissions Objekt in der Collection erhalten hat.
|
||||
```yaml
|
||||
permissions:
|
||||
user:
|
||||
methods:
|
||||
get: true
|
||||
post: true
|
||||
put: true
|
||||
delete: true
|
||||
```
|
||||
@@ -1,3 +0,0 @@
|
||||
# Serverkonfiguration
|
||||
|
||||
TODO
|
||||
@@ -1,143 +0,0 @@
|
||||
# Funktionsweise von SSR:
|
||||
|
||||
## Teil 1: Apache-Konfigurationsdokumentation
|
||||
|
||||
## Allgemeine Informationen
|
||||
|
||||
Diese Konfigurationsdatei ist für einen Apache Webserver bestimmt und beinhaltet spezielle Regeln für das Umleiten von Anfragen und die Verarbeitung von Single Page Applications (SPAs).
|
||||
|
||||
## htaccess Konfigurationsdetails
|
||||
|
||||
- MIME-Type Definition für .mjs Dateien
|
||||
- AddType application/javascript .mjs
|
||||
- Diese Anweisung sorgt dafür, dass Dateien mit der Endung .mjs als JavaScript-Dateien (application/javascript) behandelt werden.
|
||||
- Default Directory Index
|
||||
- DirectoryIndex noindex
|
||||
- Legt noindex als Standard-Indexdatei fest, wenn ein Verzeichnis aufgerufen wird. Dies verhindert, dass Apache automatisch eine Datei wie index.html oder spa.html lädt, wenn keine spezifische Datei in der URL angegeben ist. -> Emöglicht SSR
|
||||
- mod_rewrite Konfiguration
|
||||
- IfModule mod_rewrite.c
|
||||
- Diese Sektion ist nur aktiv, wenn das mod_rewrite-Modul verfügbar ist. mod_rewrite ermöglicht die Umleitung und Umformung von URLs.
|
||||
- RewriteEngine On
|
||||
- Aktiviert die Umleitungsfunktionen von mod_rewrite.
|
||||
- RewriteBase /
|
||||
- Setzt den Basispfad für Rewrite-Regeln auf das Wurzelverzeichnis.
|
||||
- API-Umleitung
|
||||
- RewriteRule ^/?api/(.*)$ http://tibi-server:8080/api/v1/_/vde8_tibi_2023/$1 [P,QSA,L]
|
||||
- Leitet Anfragen, die mit /api/ beginnen, an einen anderen Server (tibi-server) um. Behält den Rest des Pfades bei und fügt ihn an den Ziel-URL an. Die Flags bedeuten:
|
||||
- [P] Proxy: Die Anfrage wird intern an den angegebenen Server weitergeleitet.
|
||||
- [QSA] Query String Append: Erhält bestehende Query-Parameter.
|
||||
- [L] Last: Keine weiteren Regeln werden verarbeitet, wenn diese Regel greift.
|
||||
- Fallback für Nichtexistierende Dateien/Verzeichnisse
|
||||
- RewriteCond %{REQUEST_FILENAME} !-f und RewriteCond %{REQUEST_FILENAME} !-d
|
||||
- Prüft, ob der angeforderte Pfad weder einer existierenden Datei noch einem Verzeichnis entspricht.
|
||||
- RewriteRule ^/?(.*)$ http://tibi-server:8080/api/v1/_/vde8_tibi_2023/ssr?token=XYZ&url=/$1 [P,QSA,L]
|
||||
- Leitet Anfragen, die nicht existierenden Dateien/Verzeichnissen entsprechen, an einen Server-seitigen Rendering-Prozess weiter.
|
||||
- token=XYZ muss an den SSR_TOKEN angepasst werden (welcher auch in der server seinigen env steht.)
|
||||
- Kommentierte Regel
|
||||
- #RewriteRule (.*) /spa.html [QSA,L]
|
||||
- Eine auskommentierte Regel, die alle Anfragen zu spa.html umleiten würde. Da sie auskommentiert ist, hat sie keinen Effekt.
|
||||
|
||||
### Zusätzliche Hinweise
|
||||
|
||||
- Die Konfiguration ist speziell für die Handhabung von Single Page Applications und API-Anfragen zugeschnitten.
|
||||
- Es ist wichtig, dass das mod_rewrite-Modul aktiviert ist, damit diese Regeln funktionieren.
|
||||
- Die Reihenfolge der Regeln ist entscheidend für die korrekte Funktionsweise.
|
||||
|
||||
## Teil 2: Grundlegender SSR-Prozess
|
||||
|
||||
- Initiale Anfrage und Umleitung
|
||||
- Anfragen für spa.html werden durch die .htaccess-Datei umgeleitet zur SSR-Collection.
|
||||
- Der originale Pfad wird als URL-Query-Parameter an die neue URL angehängt.
|
||||
- Beispiel: Eine Anfrage an /dimitrisBuecher/veraltet wird umgeleitet, da die /api/ Rewrite-Regel nicht greift.
|
||||
- Verarbeitung im Tibi-Server
|
||||
- Gibt die Angefrage Seite zurück.
|
||||
|
||||
## Teil 3: Detaillierte Erklärung des Caching und Rendering-Prozesses im SSR-Kontext
|
||||
|
||||
- URL-Extraktion im SSR-Hook
|
||||
- Der Prozess beginnt mit der Extraktion der URL im SSR-Hook.
|
||||
- Diese Extraktion dient als Grundlage für die nachfolgenden Schritte des Rendering-Prozesses.
|
||||
- Optionale Unterbindung von Caching
|
||||
- Ein Boolean-Feld namens „Caching“ kann in der Content-Collection implementiert werden, um Caching selektiv zu steuern oder zu unterbinden.
|
||||
- URL-Normalisierung und Existenzprüfung
|
||||
- Die URL wird normalisiert, um Konsistenz zu gewährleisten.
|
||||
- Anschließend wird überprüft, ob die normalisierte URL bereits in der SSR-Collection vorhanden ist.
|
||||
- Für zeitlich begrenzte Sichtbarkeit von Seiten wird ein validUntil-Feld im Cache eingeführt und überprüft.(Nur wenn es für die Seite notwendig ist implementieren - aktuell in vde8 mit drin)
|
||||
- Validierung des Pfades
|
||||
- Der Pfad wird validiert, indem geprüft wird, ob die URL als Pfad in der Content-Collection existiert.
|
||||
- Rückgabewerte bei der Validierung:
|
||||
- -1, wenn der Pfad nicht gefunden wird (not found).
|
||||
- 0, wenn der Pfad existiert, aber nicht gecacht werden darf.
|
||||
- 1, wenn der Pfad existiert und gecacht werden darf.
|
||||
- Cache-Vorbereitung bei Erlaubnis
|
||||
- Bei Erlaubnis zum Cachen wird im Kontext-Objekt das ssrCache-Objekt sowie die ssrRequest-Funktion initialisiert.
|
||||
- Diese Initialisierung ist entscheidend für das serverseitige App-Rendering.
|
||||
- Serverseitiges App-Rendering
|
||||
- In Server-Umgebungen (überprüft durch typeof window == "undefined") werden keine normalen Fetch-Requests ausgeführt, sondern stattdessen die ssrRequest-Funktion verwendet.
|
||||
- Zugriff auf das Kontext-Objekt ist auch im serverseitigen App-Reader möglich, was die Nutzung der ssrRequest-Funktion ermöglicht.
|
||||
- Setzen von ValidUntil und Durchführung der SSR-Request
|
||||
- ValidUntil wird gesetzt, indem relevante Datensätze über context.db.find abgerufen werden.
|
||||
- Überprüfung, ob Datensätze ein publishDate-Feld haben und ob dieses Datum relevant für das validUntil-Datum ist.
|
||||
- Eine Request wird an die URL gesendet, das Ergebnis wird dann im ssrCache gespeichert.
|
||||
- Cache-Key Generierung
|
||||
- Der Cache-Key wird generiert, indem ein Objekt, das aus dem Endpoint und relevanten Parametern besteht, in einen String konvertiert wird.
|
||||
- Als Wert wird die standardmäßige Response aus dem Frontend verwendet.
|
||||
- Speicherung von Header und Body des Renderings
|
||||
- Nach dem App-Rendering werden Header und Body in Variablen head und html gespeichert.
|
||||
- Ein script-Tag, das window.**SSR_CACHE** auf context.ssrCache setzt, wird zum Header hinzugefügt.
|
||||
- Clientseitige Fetch-Request-Optimierung
|
||||
- Überprüfung, ob die aktuelle Anfrage bereits im window.**SSR_CACHE** vorhanden ist.
|
||||
- Bei vorhandenen Anfragen wird der gespeicherte Wert über Promise.resolve() zurückgegeben, um redundante Anfragen zu vermeiden.
|
||||
- Deaktivierung von SSR-Caching für spezielle Seiten
|
||||
- Für Seiten wie Produktseiten wird empfohlen, das SSR-Caching über den Boolean zu deaktivieren, um zu verhindern, dass solche Anfragen in den Cache gelangen.
|
||||
- Finalisierung des HTML-Dokuments
|
||||
- Das Standard-spa.html-Dokument wird verwendet und mit den ermittelten Werten für Head, Body, Fehlermeldungen und Kommentaren ergänzt.
|
||||
- Das resultierende HTML-Dokument wird in der SSR-Collection gespeichert und als Response an den Client gesendet.
|
||||
- Ergebnis
|
||||
- Der Client erhält eine vollständig gerenderte HTML-Seite, die serverseitig verarbeitet wurde, was die Effizienz erhöht und die Notwendigkeit zahlreicher Requests reduziert.
|
||||
|
||||
## Teil 3: SSR-Cache-Management
|
||||
|
||||
- Cache-Management in der Content-Collection
|
||||
- Löschung der SSR-Collection bei jedem POST und PUT-Request.
|
||||
- Workflow-Integration
|
||||
- Als Teil des Workflows wird der SSR-Cache gelöscht, um die Auslieferung veralteter Seiten zu verhindern.
|
||||
|
||||
### Dokumentation: SSR in der Entwicklungsumgebung
|
||||
|
||||
#### Überblick
|
||||
|
||||
In der Entwicklungsumgebung unterscheidet sich der Umgang mit Server-Side Rendering (SSR) von der Produktion, da hier die .htaccess keine Rolle spielt. Es sind spezielle Maßnahmen bei der Konfiguration von esbuild erforderlich.
|
||||
|
||||
#### Schritte für die SSR-Konfiguration in der Entwicklungsumgebung
|
||||
|
||||
- Anpassung der .env-Datei
|
||||
- Setzen von START_SCRIPT=:ssr in der .env-Datei.
|
||||
- Diese Einstellung wird in der Docker-compose-Datei verwendet, um zu bestimmen, welches Startskript für das Frontend verwendet werden soll.
|
||||
- Auch auf dem Server muss logischerweise der SSR_TOKEN in der env gesetzt sein, damit einerseits die yml config Datei darauf zugreifen kann, aber esbuild auch darauf zugreifen kann (in der htaccess wird er statisch geschrieben)
|
||||
- Verwendung von start:ssr
|
||||
- Bei Verwendung von start:ssr wird die SSR-Variable gesetzt.
|
||||
- Diese Variable ist notwendig für esbuild, um zu entscheiden, ob ein Proxy aktiviert werden soll.
|
||||
- Proxy-Funktionalität in esbuild
|
||||
- Der Proxy in esbuild übernimmt die Rolle der .htaccess.
|
||||
- Er leitet Anfragen, die normalerweise an spa.html gehen würden, an die SSR-Collection weiter.
|
||||
- Handhabung von Frontend-Änderungen
|
||||
- Änderungen am Frontend werden nicht automatisch in SSR übernommen.
|
||||
- Um die serverseitig vorliegende Version der App zu aktualisieren, muss yarn Build:server ausgeführt werden.
|
||||
- Bewusster manueller Prozess
|
||||
- Eine automatische Übernahme von Änderungen könnte die Ladezeiten nach einem Reload erheblich erhöhen.
|
||||
- Um die Effizienz der Entwicklungsumgebung zu erhalten, wird der manuelle Prozess bevorzugt.
|
||||
- Notwendige Nachbearbeitung nach Updates
|
||||
- Nach dem Neubau der serverseitigen App-Version müssen aktuelle SSR-Einträge gelöscht werden.
|
||||
- Ein Reboot des Tibi-Servers (durch Speichern in den Einstellungen) ist erforderlich, damit dieser die neue App-Version in den Cache aufnimmt.
|
||||
- Integration von SSR im Entwicklungsprozess
|
||||
- Aufgrund des aufwendigeren Prozesses wird empfohlen, SSR erst in einem späteren Stadium der Entwicklung zu integrieren.
|
||||
- Dies ermöglicht eine effizientere Entwicklung ohne SSR, bevor dieses für die finale Version implementiert wird.
|
||||
|
||||
### Anmerkungen:
|
||||
|
||||
Anzumerken ist, dass alle zugriffe auf window, document, oder Funktionen wie setTimeout in der frontend app beim SSR Fehler werfen werden, daher muss immer eine Prüfung sicherstellen, das window nicht undefined ist.
|
||||
|
||||
In der notFound komponente sollte man idealerweise context.is404 auf true setzen, damit sichergestellt wird, das die Seite unter keinen umständen gecached wird (backup zur vorherigen Prüfung in isValidPath Funktion…)
|
||||
|
||||
Natürlich muss in der Serverseitigen env der entsprechende key für SSR access gesetzt werden. Dieser wird in esbuild gelesen und ist damit notwendig
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 291 KiB |
@@ -1,19 +0,0 @@
|
||||
{
|
||||
"name": "tibi-docs",
|
||||
"version": "1.0.0",
|
||||
"main": "README.md",
|
||||
"repository": "https://gitbase.de/cms/tibi-docs",
|
||||
"author": "Sebastian Frank <sebastian@webmakers.de>",
|
||||
"license": "MIT",
|
||||
"packageManager": "yarn@3.2.4",
|
||||
"scripts": {
|
||||
"docpress:serve": "docpress serve",
|
||||
"docpress:build": "docpress build"
|
||||
},
|
||||
"devDependencies": {
|
||||
"docpress": "^0.8.2"
|
||||
},
|
||||
"dependencies": {
|
||||
"markdown-it-code-include": "./markdown-it-code-include"
|
||||
}
|
||||
}
|
||||
7181
docs/yarn.lock
7181
docs/yarn.lock
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user