fields

api/collections/democol.yml

@@ -202,3 +202,11 @@ fields:
     - !include fields/title.yml
     - !include fields/date.yml
     - !include fields/type.yml
+
+# Neben der Definition der Indexe innerhalbd des Feld-Objektes selbst,
+# ist die Index-Definition global für die Kollektion auch hier möglich.
+# Diese Definition ist z.B. für zusammengesetzte Index-Typen notwendig.
+# Außerdem sind hier feinere Einstellungen für den Index möglich.
+# Mehr dazu im "indexes" Kapitel
+indexes: 
+    - !include democol/textindex.yml

api/collections/fields/date.yml

@@ -0,0 +1,57 @@
+# Der Name des Feldes wird in der Datenbank zum Objekt ebenso
+# wie in der Ein- und Ausgabe über die API verwendet.
+name: date
+
+# Über "type" wird der Datentyp in der Datenbank festgelegt.
+# Mögliche Typen sind weiter unten aufgelistet.
+type: date
+
+# Direkt am Feld kann eine Index-Definition erfolgen.
+# Folgende mögliche Werte können ihn die Liste aufgenommen werden:
+# "single" - Standard-Index für diese Feld
+# "unique" - Das Feld muss einen eindeutigen Wert haben
+# "text"   - Alle "text"-Indexanganben aller Felder werden zu einem
+#            gemeinsamen Volltext-Index kombiniert
+#
+# Die Angabe des Volltextindex ist besser unter "collections.X.indexes"
+# vorzunehmen.
+index:
+    - single
+
+# Jede Datenübertragung an des Server wird validiert, d.h. es werden
+# keine Datentypen angenommen, die nicht zu "type" passen.
+# Darüber hinaus kann via "validator" eine zusätzliche Validierung
+# vorgenommen werden.
+# Dazu gibt es ein extra Kapitel.
+validator:
+    required: true
+    eval: new Date($this) > new Date()
+
+# Und natürlich gibt es auch hier ein "meta" Objekt zur Steuerung
+# der Admin-UI.
+meta:
+    # Das "label" des Feldes wird als Label vor dem Widget verwendet.
+    label:
+        de: Titel
+        en: title
+
+    # Abgelkeitet vom "type" gibt es Standard-Widgets. für spezielle
+    # Aufgaben stehen aber eine Hand voll Widgets bereit, die später
+    # beschrieben werden.
+    widget: text
+
+    # Standardwerte für neue Enträge können entweder direkt angegeben
+    # werden oder via Javascript client-seitig generiert werden.
+    # In den Kontext injizierte Variablen werden später beschrieben.
+    defaultValue:
+        # Das Ergebnis von "eval" wird hier als Standardwert verwendet.
+        # (hier das aktuelle Datum)
+        eval: new Date()
+
+    # Sollen Felder abhängig von bestimmten Bedingungen ein- oder
+    # ausgeblendet werden, geschieht das über Anweisungen in "dependsOn".
+    dependsOn:
+        # Das Feld wird nur eingeblendet wenn der Wert von "type"
+        # (auf gleicher Ebene wie das Feld "date" selbst)
+        #  gleich "news" ist.
+        eval: $parent.type == "news"

docs/projektkonfig/collections.md

@@ -212,6 +212,13 @@ fields:
     - !include fields/date.yml
     - !include fields/type.yml
 
+# Neben der Definition der Indexe innerhalbd des Feld-Objektes selbst,
+# ist die Index-Definition global für die Kollektion auch hier möglich.
+# Diese Definition ist z.B. für zusammengesetzte Index-Typen notwendig.
+# Außerdem sind hier feinere Einstellungen für den Index möglich.
+# Mehr dazu im "indexes" Kapitel
+indexes: 
+    - !include democol/textindex.yml
 ```
 
 ## imageFilter Objekt
@@ -272,6 +279,9 @@ Folgende Attribute können Filter-Eintrage haben, wobei "fit" und "fill" exklusi
 | quality | number | Ausgabequalität 0..100 |
 
 
+## indexes Liste
+
+TODO
 
 ## meta Objekt
 

docs/projektkonfig/fields.md

@@ -1 +1,151 @@
 # fields
+
+Felder im tibi-server müssen einen bestimmten Datentyp haben. Über die Admin-UI können die Felder über Widgets in unterschiedlichen Ausprägungen dargestellt werden (view-Widgets), bzw. dem Benutzer eine Eingabe abverlangen (input-Widgets).
+
+Es gibt grundlegende Angaben, die jedes Feld haben muss um vom tibi-server akzeptiert zu werden. Darüber hinaus kann auch jedes Feld ein "meta" Objekt haben, was der Admin-UI mitteilt, wie es dieses Feld für Ausgabe und Eingabe behandel soll.
+
+Zunächst folgt der grundlegende Aufbau des Feld-Objektes:
+
+```yaml
+# Der Name des Feldes wird in der Datenbank zum Objekt ebenso
+# wie in der Ein- und Ausgabe über die API verwendet.
+name: date
+
+# Über "type" wird der Datentyp in der Datenbank festgelegt.
+# Mögliche Typen sind weiter unten aufgelistet.
+type: date
+
+# Direkt am Feld kann eine Index-Definition erfolgen.
+# Folgende mögliche Werte können ihn die Liste aufgenommen werden:
+# "single" - Standard-Index für diese Feld
+# "unique" - Das Feld muss einen eindeutigen Wert haben
+# "text"   - Alle "text"-Indexanganben aller Felder werden zu einem
+#            gemeinsamen Volltext-Index kombiniert
+#
+# Die Angabe des Volltextindex ist besser unter "collections.X.indexes"
+# vorzunehmen.
+index:
+    - single
+
+# Jede Datenübertragung an des Server wird validiert, d.h. es werden
+# keine Datentypen angenommen, die nicht zu "type" passen.
+# Darüber hinaus kann via "validator" eine zusätzliche Validierung
+# vorgenommen werden.
+# Dazu gibt es ein extra Kapitel.
+validator:
+    required: true
+    eval: new Date($this) > new Date()
+
+# Und natürlich gibt es auch hier ein "meta" Objekt zur Steuerung
+# der Admin-UI.
+meta:
+    # Das "label" des Feldes wird als Label vor dem Widget verwendet.
+    label:
+        de: Titel
+        en: title
+
+    # Abgelkeitet vom "type" gibt es Standard-Widgets. für spezielle
+    # Aufgaben stehen aber eine Hand voll Widgets bereit, die später
+    # beschrieben werden.
+    widget: text
+
+    # Standardwerte für neue Enträge können entweder direkt angegeben
+    # werden oder via Javascript client-seitig generiert werden.
+    # In den Kontext injizierte Variablen werden später beschrieben.
+    defaultValue:
+        # Das Ergebnis von "eval" wird hier als Standardwert verwendet.
+        # (hier das aktuelle Datum)
+        eval: new Date()
+
+    # Sollen Felder abhängig von bestimmten Bedingungen ein- oder
+    # ausgeblendet werden, geschieht das über Anweisungen in "dependsOn".
+    dependsOn:
+        # Das Feld wird nur eingeblendet wenn der Wert von "type"
+        # (auf gleicher Ebene wie das Feld "date" selbst)
+        #  gleich "news" ist.
+        eval: $parent.type == "news"
+
+```
+
+## validator Objekt
+
+TODO
+
+## dependsOn und defaultValue Kontext
+
+TODO
+
+## Datentypen
+
+Via "type" wird der Datentyp des Feldes definiert. Folgende Datentypen sind möglich:
+
+### string
+
+String wird für Zeichenketten verwendet. Das Standardwidget ohne weitere Angabe ist bei der Ausgabe die direkte Textausgabe und bei der Eingabe ein input-Element vom type="text".
+
+### number
+
+Number wird sowohl für ganze Zahlen, wie auch für Gleitkommawerte definiert. Auch hier ist das Standard-Widget für die Eingabe ein input-Element, allerdings vom type="number".
+
+### boolean
+
+Ein boolcher Wert, also true/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.
+
+## Admin-UI Widgets
+
+TODO
+
+### text
+
+### number
+
+### checkbox
+
+### select
+
+### date
+
+### datetime
+
+### file
+
+### image
+
+### selectArray
+
+### checkboxArray
+
+### chipArray
+
+### object
+
+### objectArray
+