collection docs

.gitignore

@@ -1 +1,2 @@
 _docpress
+node_modules

.yarnrc.yml

@@ -1 +1,9 @@
+globalFolder: .yarn/global
+
+nodeLinker: node-modules
+
+plugins:
+  - path: .yarn/plugins/@yarnpkg/plugin-interactive-tools.cjs
+    spec: "@yarnpkg/plugin-interactive-tools"
+
 yarnPath: .yarn/releases/yarn-3.2.4.cjs

api/collections/democol.yml

@@ -1,92 +1,200 @@
-name: content
+# Der Name der Kollektion wird in der Rest-API-URL verwendet, z.B.
+# /_/demo/democol
+name: democol
 
-uploadPath: ../media/content
+# Enthält die Kollektion Felder vom Typ "file", so werden die
+# hochgeladenen Dateien unter dem Ordner abgelegt, der mit
+# "uploadPath" bestimmt wird.
+uploadPath: ../media/democol
 
-meta:
+# Wie auch in der Top-Level-Konfig "config.yml" ist auch hier ein
+# "meta" Objekt möglich und nötig für die Konfiguration der
+# Admin-UI.
+# Mögliche Angaben werden im seperaten Kapitel behandelt.
+meta: !include meta/meta.yml
 
+# "imageFilter" definieren Filter, die Bilder bearbeiten, wie
+# z.B. Verkleinerung.
+# Mögliche Angaben werden im seperaten Kapitel behandelt.
 imageFilter: !include ../_imagefilter.yml
 
+# Projektionen der Daten werden via GET-Parameter "projection=..."
+# referenziert.
+# "projections" is ein Objekt, dass die Namen der Projektionen
+# als Key führt.
 projections:
-  list:
+    # "list" = Name der Projektion
-    select:
+    list:
-      title: 1
+        # "select" definiert als Keys die Felder, die beim Abruf
-      date: 1
+        # dieser Projektion in den Ausgabe-Daten enthalten sind.
-  full:
+        # Felder werden über die Punkt-Notation referenziert.
-    select:
+        select:
-        
+            title: 1
+            date: 1
+            # refenziert das "subField" "author" unterhalb von "meta"
+            meta.author: 1
+    details:
+        # Alternativ kann "select" auch Auschlussregeln definieren.
+        # Eine Mischung von Inkludieren und Auschluss ist NICHT
+        # möglich.
+        select:
+            comment: -1
+    full:
+        # Ein leeres "select" Objekt beschränkt die Ausgabe der
+        # Daten nicht und ist Standard, wenn der "projection="
+        # Parameter nicht verwendet wurde.
+        select:
+
+# Allgeine Zugriffsregeln auf Kollektions-Ebene werden mit dem
+# "permissions" Objekt festgelegt.
 permissions:
-  public:
+    # Unter "public" werden die Zugriffsrechte für die Öffentlichkeit
-    methods:
+    # definiert.
-      get: true
+    public:
-      post: false
+        # "methods" führt die HTTP-Methoden auf, die erlaubt sind
-      put: false
+        methods:
-      delete: false
+            # "get: true" bedeutet hier, dass jeder die Daten lesen darf
+            get: true
+            # "post", also Einträge erstellen, "put" = Bearbeiten und
+            # "delete" = löschen darf die Öffentlichkeit nicht.
+            post: false
+            put: false
+            delete: false
+        # Ist "validProjections" definiert, sind auch nur genau die
+        # aufgelisteten Projektionen erlaubt, welche zwingend mit dem
+        # GET-Parameter "projection=..." ausgewählt werden müssen.
+        validProjections:
+            - list
+            - details
 
-  user:
+    # Der Key "user" steht für ALLE Benutzer die dem Projekt
-    methods:
+    # zugeordnet sind.
-      get: true
+    # D.h. eine feinere Abstufung auf Benutzerebene ist mit dem
-      post: false
+    # Key "user" allein nicht möglich.
-      put: false
+    # Für eine feinere Abstufung können nachgelagerte Hooks
-      delete: false
+    # dienen oder die Verwendung von zugeordneten benutzerdefinierten
+    # "permissions" (siehe meta Objekt).
+    user:
+        methods:
+            get: true
+            post: false
+            put: false
+            delete: false
+        # Fehlt "validProjections", sind automatisch alle Projektionen
+        # erlaubt, wobei hier auch der GET-Parameter "projection="
+        # weggelassen werden darf und somit alle Felder in der Ausgabe
+        # zu finden sind.
 
-  token:${TOKEN}:
+    # Folgende Brechtigung wird angewandt, wenn der Zugriff über
-      get: true
+    # den GET-Parameter "token=" oder die Header-Anweisung "token: "
-      post: true
+    # angefragt wird.
-      put: true
+    # "token" ist dabei die Markierung, dass es sich um einen Token
-      delete: true
+    # handelt und "${TOKEN}" ist der benutzerdefinierte Token selbst.
+    # Dieser wird hier über eine Umgebungsvariable "TOKEN" injiziert,
+    # die in "config.yml.env" definiert werden kann mit "TOKEN=...".
+    token:${TOKEN}:
+        get: true
+        post: true
+        put: true
+        delete: true
 
-  pages:
+    # Alle Berechtigungs-Namen, die nicht "public", "user" oder "token:..."
-    methods:
+    # heißen, sind benutzerdefinierte Berechtigungen, die Benutzern
-      get: true
+    # zugeordnet werden können.
-      post: true
+    # Eine mögliche Auflistung um Vorschläge in der Admin-UI anzubieten,
-      put: true
+    # werden im Top-Level meta-Objekt der "config.yml" unter "permissions"
-      delete: true
+    # definiert.
-            
+    pages:
+        methods:
+            get: true
+            post: true
+            put: true
+            delete: true
+
+# "hooks" definieren die Algorithmen, die Daten und Abläufe zu bestimmten
+# HTTP-Methoden und Schritten der API manipulieren können.
 hooks:
-  get:
+    # Hooks für die Methode "get"
-    read:
+    get:
-      type: javascript
+        # "read"-Schritt wird ausgeführt, bevor die Daten von der Datenbank
-      file: hooks/democol/get_read.js
+        # gelesen werden.
-    return:
+        read:
-      type: javascript
+            # "type" ist derzeit immer "javascript"
-      file: hooks/democol/get_return.js
+            type: javascript
+            # "file" zeigt auf die Datei mit dem Javascript-Code relativ zum
+            # Ordner der "config.yml" Datei.
+            file: hooks/democol/get_read.js
+        # "return"-Schritt wird ausgeführt, bevor die gelesenen Daten über
+        # HTTP übertragen werden.
+        return:
+            type: javascript
+            file: hooks/democol/get_return.js
 
-  post:
+    # Hooks für die Methode "post"
-    bind:
+    post:
-      type: javascript
+        # "bind" wird ausgeführt, bevor die übertragenen Daten in eine
-      file: hooks/democol/post_bind.js
+        # Objekt-Struktur umgewandelt werden.
-    validate:
+        # Der tibi-server erwarten nach diesem Schritt gültige JSON-Daten,
-      type: javascript
+        # d.h. sollte es möglich gemacht werden, dass andere Daten übertragen
-      file: hooks/democol/post_validate.js
+        # werden, sind diese in diesem Hook abzufangen und zu verarbeiten.
-    create:
+        bind:
-      type: javascript
+            type: javascript
-      file: hooks/democol/post_create.js
+            file: hooks/democol/post_bind.js
-    return:
+        # "validate" wird ausgeführt, bevor die Daten validiert werden.
-      type: javascript
+        validate:
-      file: hooks/democol/post_return.js
+            type: javascript
+            file: hooks/democol/post_validate.js
+        # "create" wird ausgeführt, bevor das Objekt/Dokument in der Datenbank
+        # angelegt wird.
+        create:
+            type: javascript
+            file: hooks/democol/post_create.js
+        # "return" wird ausgeführt, bevor die Serverantwort über HTTP
+        # übertragen wird.
+        return:
+            type: javascript
+            file: hooks/democol/post_return.js
 
-  put:
+    # Hooks für die Methode "put"
-    bind:
+    put:
-      type: javascript
+        bind:
-      file: hooks/democol/put_bind.js
+            type: javascript
-    validate:
+            file: hooks/democol/put_bind.js
-      type: javascript
+        validate:
-      file: hooks/democol/put_validate.js
+            type: javascript
-    update:
+            file: hooks/democol/put_validate.js
-      type: javascript
+        # "bind" und "validate" habe die gleiche Bedeutung wie Hooks der
-      file: hooks/democol/put_create.js
+        # Methode "post".
-    return:
+        # "update" wird ausgeführt bevor das Objekt in der Datenbank
-      type: javascript
+        # aktualisiert wird.
-      file: hooks/democol/put_return.js
+        update:
+            type: javascript
+            file: hooks/democol/put_create.js
+        # "return" wird auch hier vor der Serverantwort ausgeführt.
+        return:
+            type: javascript
+            file: hooks/democol/put_return.js
 
-  delete:
+    # Hooks für die Methode "delete"
     delete:
-      type: javascript
+        # Der "delete"-Hook wird vor dem eigentlichen Löschen ausgeführt
-      file: hooks/democol/delete_delete.js
+        delete:
-    return:
+            type: javascript
-      type: javascript
+            file: hooks/democol/delete_delete.js
-      file: hooks/democol/delete_return.js
+        # "return"-Hook kann ebenso hier die Serverantwort manipulieren
-
+        return:
+            type: javascript
+            file: hooks/democol/delete_return.js
 
+# "fields" stellen die Eigentliche Struktur der Kollektion dar.
+# "fields" ist als Array angelegt um eine Standard-Sortierung
+# in der Admin-UI vorzugeben.
 fields:
-  - !include fields/title.yml
+    # Das Einbinden von Feldern über extra Dateien bietet sich nur
+    # an, wenn das jeweilige Feld mehrfach von dieser oder anderen
+    # Kollektionen verwendet wird.
+    # Auf die möglichen Definitionen wird im Kapitel "fields"
+    # eingegangen.
+    - !include fields/title.yml
+    - !include fields/date.yml
+    - !include fields/type.yml

api/collections/meta/meta.yml

@@ -0,0 +1,70 @@
+# Ein Label für die Admin-UI wird mehrsprachig folgendermaßen definiert
+label:
+    de: Demo-Kolletion
+    en: Demo-Collection
+
+# Jede Kolletion kann ein eigenes Icon aus mdijs bekommen.
+muiIcon: web
+
+# Die Standardsortierung bei ersten Aufruf der Kollektion.
+defaultSort:
+    # Nach welchem Feld soll sortiert werden?
+    field: updatedTime
+    # ASC für aufsteigend oder DESC für absteigend
+    order: DESC
+
+# Ist ein Javascript Message-Object-Empfänger implementiert, der empfangene
+# Daten als Vorschau rendern kann, so ist dieser hier zu definieren.
+# Implementierungshinweise zu einem Solchen gibt es später.
+previewUrl: https://demo.testversion.online/preview
+
+# Aus den definierten "imageFilter"-Angaben kann ein Filter für die
+# Ausgabe der Thunbnails in der Admin-Ansicht ausgewählt werden.
+defaultImageFilter: s
+
+# Jede Kollektion kann über media-Querys mit mehreren Ansichten veknüpft werden.
+# Mögliche Ansichten und die dazugehörigen CSS-Queries sind hier zu defineren.
+views:
+    # Natürlich können die Angaben auch ausgelagert und mehrfach verwendet werden.
+    # Die möglichen Angaben werden im Kapitel "views" gezeigt.
+    - !include views/simpleList.yml
+    - !include views/table.yml
+
+# Wird eine Kollektion als eine Gesamtliste schnell unübersichtlich, hild die 
+# Definition von "subNavigation".
+# Die meisten Angaben sind aus obiger Beschreibung den meta-Objektes bekannt.
+# Es wird hier nur auf die zusätzlichen Angaben eingegangen.
+subNavigation:
+    - # Jede Unternavigation braucht einen eindeutigen Namen um diese später
+      # in z.B. Javascript-Code wieder erkennen zu können.
+      name: pages
+      label:
+          de: Seiten
+          en: Pages
+      muiIcon: page-layout-body
+      defaultSort:
+          field: titel
+          order: ASC
+      views:
+          - !include views/simpleList.yml
+          - !include views/table.yml
+      # Um mehr Übersicht zu bekommen können zum Einen andere "views" und "defaultSort"
+      # genutzt werden. Es kann aber auch eine Einschränkung der Daten über eine 
+      # Vorfilterung via "filter" geben. "filter" ist ein Objekt mit MongoDB-Filterangaben.
+      # siehe: https://www.mongodb.com/docs/compass/current/query/filter/
+      filter:
+          type: page
+          
+    - name: news
+      label:
+          de: Neuigkeiten
+          en: News
+      muiIcon: newspaper
+      defaultSort:
+          field: date
+          order: DESC
+      views:
+          - !include views/simpleList.yml
+          - !include views/table.yml
+      filter:
+          type: news

docs/begriffe.md

@@ -32,6 +32,18 @@ Ein Datenfeld innerhalb einer Kollektion mit einem bestimmten Datentyp (z.B. str
 
 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

docs/projektkonfig/collections.md

@@ -2,8 +2,301 @@
 
 Die Konfiguration einer Kollektion sollte zur besseren Übersicht innerhalb einer gesonderten Datei im Unterorder "/api/collections/" erfolgen und via "!include" in die "config.yml" eingebunden werden.
 
+## Grundlegender Aufbau
+
 Eine solche Datei (z.B. democol.yml) hat folgenden Aufbau:
 
 ```yaml
+# Der Name der Kollektion wird in der Rest-API-URL verwendet, z.B.
+# /_/demo/democol
+name: democol
 
-```
+# Enthält die Kollektion Felder vom Typ "file", so werden die
+# hochgeladenen Dateien unter dem Ordner abgelegt, der mit
+# "uploadPath" bestimmt wird.
+uploadPath: ../media/democol
+
+# Wie auch in der Top-Level-Konfig "config.yml" ist auch hier ein
+# "meta" Objekt möglich und nötig für die Konfiguration der
+# Admin-UI.
+# Mögliche Angaben werden im seperaten Kapitel behandelt.
+meta: !include meta/meta.yml
+
+# "imageFilter" definieren Filter, die Bilder bearbeiten, wie
+# z.B. Verkleinerung.
+# Mögliche Angaben werden im seperaten Kapitel behandelt.
+imageFilter: !include ../_imagefilter.yml
+
+# Projektionen der Daten werden via GET-Parameter "projection=..."
+# referenziert.
+# "projections" is ein Objekt, dass die Namen der Projektionen
+# als Key führt.
+projections:
+    # "list" = Name der Projektion
+    list:
+        # "select" definiert als Keys die Felder, die beim Abruf
+        # dieser Projektion in den Ausgabe-Daten enthalten sind.
+        # Felder werden über die Punkt-Notation referenziert.
+        select:
+            title: 1
+            date: 1
+            # refenziert das "subField" "author" unterhalb von "meta"
+            meta.author: 1
+    details:
+        # Alternativ kann "select" auch Auschlussregeln definieren.
+        # Eine Mischung von Inkludieren und Auschluss ist NICHT
+        # möglich.
+        select:
+            comment: -1
+    full:
+        # Ein leeres "select" Objekt beschränkt die Ausgabe der
+        # Daten nicht und ist Standard, wenn der "projection="
+        # Parameter nicht verwendet wurde.
+        select:
+
+# Allgeine Zugriffsregeln auf Kollektions-Ebene werden mit dem
+# "permissions" Objekt festgelegt.
+permissions:
+    # Unter "public" werden die Zugriffsrechte für die Öffentlichkeit
+    # definiert.
+    public:
+        # "methods" führt die HTTP-Methoden auf, die erlaubt sind
+        methods:
+            # "get: true" bedeutet hier, dass jeder die Daten lesen darf
+            get: true
+            # "post", also Einträge erstellen, "put" = Bearbeiten und
+            # "delete" = löschen darf die Öffentlichkeit nicht.
+            post: false
+            put: false
+            delete: false
+        # Ist "validProjections" definiert, sind auch nur genau die
+        # aufgelisteten Projektionen erlaubt, welche zwingend mit dem
+        # GET-Parameter "projection=..." ausgewählt werden müssen.
+        validProjections:
+            - list
+            - details
+
+    # Der Key "user" steht für ALLE Benutzer die dem Projekt
+    # zugeordnet sind.
+    # D.h. eine feinere Abstufung auf Benutzerebene ist mit dem
+    # Key "user" allein nicht möglich.
+    # Für eine feinere Abstufung können nachgelagerte Hooks
+    # dienen oder die Verwendung von zugeordneten benutzerdefinierten
+    # "permissions" (siehe meta Objekt).
+    user:
+        methods:
+            get: true
+            post: false
+            put: false
+            delete: false
+        # Fehlt "validProjections", sind automatisch alle Projektionen
+        # erlaubt, wobei hier auch der GET-Parameter "projection="
+        # weggelassen werden darf und somit alle Felder in der Ausgabe
+        # zu finden sind.
+
+    # Folgende Brechtigung wird angewandt, wenn der Zugriff über
+    # den GET-Parameter "token=" oder die Header-Anweisung "token: "
+    # angefragt wird.
+    # "token" ist dabei die Markierung, dass es sich um einen Token
+    # handelt und "${TOKEN}" ist der benutzerdefinierte Token selbst.
+    # Dieser wird hier über eine Umgebungsvariable "TOKEN" injiziert,
+    # die in "config.yml.env" definiert werden kann mit "TOKEN=...".
+    token:${TOKEN}:
+        get: true
+        post: true
+        put: true
+        delete: true
+
+    # Alle Berechtigungs-Namen, die nicht "public", "user" oder "token:..."
+    # heißen, sind benutzerdefinierte Berechtigungen, die Benutzern
+    # zugeordnet werden können.
+    # Eine mögliche Auflistung um Vorschläge in der Admin-UI anzubieten,
+    # werden im Top-Level meta-Objekt der "config.yml" unter "permissions"
+    # definiert.
+    pages:
+        methods:
+            get: true
+            post: true
+            put: true
+            delete: true
+
+# "hooks" definieren die Algorithmen, die Daten und Abläufe zu bestimmten
+# HTTP-Methoden und Schritten der API manipulieren können.
+hooks:
+    # Hooks für die Methode "get"
+    get:
+        # "read"-Schritt wird ausgeführt, bevor die Daten von der Datenbank
+        # gelesen werden.
+        read:
+            # "type" ist derzeit immer "javascript"
+            type: javascript
+            # "file" zeigt auf die Datei mit dem Javascript-Code relativ zum
+            # Ordner der "config.yml" Datei.
+            file: hooks/democol/get_read.js
+        # "return"-Schritt wird ausgeführt, bevor die gelesenen Daten über
+        # HTTP übertragen werden.
+        return:
+            type: javascript
+            file: hooks/democol/get_return.js
+
+    # Hooks für die Methode "post"
+    post:
+        # "bind" wird ausgeführt, bevor die übertragenen Daten in eine
+        # Objekt-Struktur umgewandelt werden.
+        # Der tibi-server erwarten nach diesem Schritt gültige JSON-Daten,
+        # d.h. sollte es möglich gemacht werden, dass andere Daten übertragen
+        # werden, sind diese in diesem Hook abzufangen und zu verarbeiten.
+        bind:
+            type: javascript
+            file: hooks/democol/post_bind.js
+        # "validate" wird ausgeführt, bevor die Daten validiert werden.
+        validate:
+            type: javascript
+            file: hooks/democol/post_validate.js
+        # "create" wird ausgeführt, bevor das Objekt/Dokument in der Datenbank
+        # angelegt wird.
+        create:
+            type: javascript
+            file: hooks/democol/post_create.js
+        # "return" wird ausgeführt, bevor die Serverantwort über HTTP
+        # übertragen wird.
+        return:
+            type: javascript
+            file: hooks/democol/post_return.js
+
+    # Hooks für die Methode "put"
+    put:
+        bind:
+            type: javascript
+            file: hooks/democol/put_bind.js
+        validate:
+            type: javascript
+            file: hooks/democol/put_validate.js
+        # "bind" und "validate" habe die gleiche Bedeutung wie Hooks der
+        # Methode "post".
+        # "update" wird ausgeführt bevor das Objekt in der Datenbank
+        # aktualisiert wird.
+        update:
+            type: javascript
+            file: hooks/democol/put_create.js
+        # "return" wird auch hier vor der Serverantwort ausgeführt.
+        return:
+            type: javascript
+            file: hooks/democol/put_return.js
+
+    # Hooks für die Methode "delete"
+    delete:
+        # Der "delete"-Hook wird vor dem eigentlichen Löschen ausgeführt
+        delete:
+            type: javascript
+            file: hooks/democol/delete_delete.js
+        # "return"-Hook kann ebenso hier die Serverantwort manipulieren
+        return:
+            type: javascript
+            file: hooks/democol/delete_return.js
+
+# "fields" stellen die Eigentliche Struktur der Kollektion dar.
+# "fields" ist als Array angelegt um eine Standard-Sortierung
+# in der Admin-UI vorzugeben.
+fields:
+    # Das Einbinden von Feldern über extra Dateien bietet sich nur
+    # an, wenn das jeweilige Feld mehrfach von dieser oder anderen
+    # Kollektionen verwendet wird.
+    # Auf die möglichen Definitionen wird im Kapitel "fields"
+    # eingegangen.
+    - !include fields/title.yml
+    - !include fields/date.yml
+    - !include fields/type.yml
+
+```
+
+## imageFilter Objekt
+
+TODO
+
+
+## meta Objekt
+
+Wie bereits an anderer Stelle beschrieben, dient das meta-Objekt zur Definition von Merkmalen, die in der Admin-UI Verwendung finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
+
+Folgende Angaben sind möglich:
+
+```yaml
+# Ein Label für die Admin-UI wird mehrsprachig folgendermaßen definiert
+label:
+    de: Demo-Kolletion
+    en: Demo-Collection
+
+# Jede Kolletion kann ein eigenes Icon aus mdijs bekommen.
+muiIcon: web
+
+# Die Standardsortierung bei ersten Aufruf der Kollektion.
+defaultSort:
+    # Nach welchem Feld soll sortiert werden?
+    field: updatedTime
+    # ASC für aufsteigend oder DESC für absteigend
+    order: DESC
+
+# Ist ein Javascript Message-Object-Empfänger implementiert, der empfangene
+# Daten als Vorschau rendern kann, so ist dieser hier zu definieren.
+# Implementierungshinweise zu einem Solchen gibt es später.
+previewUrl: https://demo.testversion.online/preview
+
+# Aus den definierten "imageFilter"-Angaben kann ein Filter für die
+# Ausgabe der Thunbnails in der Admin-Ansicht ausgewählt werden.
+defaultImageFilter: s
+
+# Jede Kollektion kann über media-Querys mit mehreren Ansichten veknüpft werden.
+# Mögliche Ansichten und die dazugehörigen CSS-Queries sind hier zu defineren.
+views:
+    # Natürlich können die Angaben auch ausgelagert und mehrfach verwendet werden.
+    # Die möglichen Angaben werden im Kapitel "views" gezeigt.
+    - !include views/simpleList.yml
+    - !include views/table.yml
+
+# Wird eine Kollektion als eine Gesamtliste schnell unübersichtlich, hild die 
+# Definition von "subNavigation".
+# Die meisten Angaben sind aus obiger Beschreibung den meta-Objektes bekannt.
+# Es wird hier nur auf die zusätzlichen Angaben eingegangen.
+subNavigation:
+    - # Jede Unternavigation braucht einen eindeutigen Namen um diese später
+      # in z.B. Javascript-Code wieder erkennen zu können.
+      name: pages
+      label:
+          de: Seiten
+          en: Pages
+      muiIcon: page-layout-body
+      defaultSort:
+          field: titel
+          order: ASC
+      views:
+          - !include views/simpleList.yml
+          - !include views/table.yml
+      # Um mehr Übersicht zu bekommen können zum Einen andere "views" und "defaultSort"
+      # genutzt werden. Es kann aber auch eine Einschränkung der Daten über eine 
+      # Vorfilterung via "filter" geben. "filter" ist ein Objekt mit MongoDB-Filterangaben.
+      # siehe: https://www.mongodb.com/docs/compass/current/query/filter/
+      filter:
+          type: page
+          
+    - name: news
+      label:
+          de: Neuigkeiten
+          en: News
+      muiIcon: newspaper
+      defaultSort:
+          field: date
+          order: DESC
+      views:
+          - !include views/simpleList.yml
+          - !include views/table.yml
+      filter:
+          type: news
+
+```
+
+### views Liste
+
+#### simpleList
+
+#### table

yarn.lock

@@ -6439,9 +6439,17 @@ __metadata:
   resolution: "tibi-docs@workspace:."
   dependencies:
     docpress: ^0.8.2
+    tibi-types: "https://gitbase.de/cms/tibi-types.git"
   languageName: unknown
   linkType: soft
 
+"tibi-types@https://gitbase.de/cms/tibi-types.git":
+  version: 0.0.1
+  resolution: "tibi-types@https://gitbase.de/cms/tibi-types.git#commit=30e7eb2db8ff81a0342d11d3a20ec6f421df6727"
+  checksum: cd093643346acfaf02d30e0a9a6cd554c04755d64265e2471ffafbf9411a27350a938e5348f5cd35d5e2652586a740c9394f4a26f172b1086bfa24318c8fcca1
+  languageName: node
+  linkType: hard
+
 "timed-out@npm:^4.0.0":
   version: 4.0.1
   resolution: "timed-out@npm:4.0.1"