Das Forms-Addon besteht aus einem i-doit kompatiblen Addon und einer Backend-Applikation. Das Backend ist hierbei verantwortlich für die Datenhaltung und kann über eine
REST-API bedient werden. Es besteht weiterhin die Möglichkeit i-doit als Proxy zu verwenden, um mit dem Forms-Backend zu kommunizieren. Dies setzt jedoch eine valide Benutzersession in i-doit voraus. Sofern dies nicht gegeben ist kann die Forms-Backend-API auch direkt angesprochen werden. Dieses Dokument geht von einer direkten Kommunikation aus.
Es ist zu beachten, dass das Backend keinerlei logische Validierungen enthält. Diese Aufgabe übernimmt ausschließlich das Frontend. Eine unmittelbare Nutzung der API bringt daher einen kompletten Verzicht auf Kontrollstrukturen mit sich. Dies sollte bei einer derartigen Nutzung daher immer beachtet werden.
Es muss ferner berücksichtigt werden, dass für die Nutzung von i-doit Attributen zusätzlich die Forms-Addon-API vorausgesetzt wird, um auf essentielle Attributinformationen zuzugreifen.
Die Authentifizierung gegen das Forms-Backend erfolgt auf Basis von Benutzername und API Schlüssel. Bei diesen Informationen geht es um eben jene Konfigurationsparameter, die auch schon in der i-doit Konfiguration hinterlegt wurden:
1234567
POST http://localhost:3000/login
Content-Type: application/json
{
"apikey": "APIKEY",
"name": "USERNAME"
}
Bei einer erfolgreichen Authentifizierung erhält man anschließend einen JSON Web Token:
123
{
"access_token": "{JWT_TOKEN}"
}
Der Token muss fortan in jedem Request angegeben werden, sofern Endpunkte angesprochen werden, die eine Authentifizierung voraussetzen. Dies erfolgt über den Authorization
-Header. Im Folgenden ein Beispiel:
12
GET http://localhost:3000/api/form
Authorization: bearer {JWT_TOKEN}
Standardmäßig hat ein Token nach seiner Erstellung eine Gültigkeit von 60 Minuten. Nach Ablauf dieser Zeit verliert es seine Gültigkeit und es muss ein erneutes Login erfolgen.
GET http://localhost:3000/api/form/6245bf4f36f695945b3df9be
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJfaWQiOiI2MWU2YThlNmY1ZTMxYjI5NzAwOTMxOWEiLCJuYW1lIjoic2VsY3VrIiwic3ViIjoiJDJhJDEwJFJ4YlRybVpUVXlXc1NSQ2VZTFR6enVBZXJZTUF1dUlsNU5qOWt5RFN4WXlFL0NsdG1iLmY2IiwiaWF0IjoxNjU3MjkyNTAxLCJleHAiOjE2NTcyOTYxMDF9.yEZAjFAGpOCbDsJuI_vqot5J75MOE0bKPPn8osQS0Ik
Zur Erstellung neuer Formulare muss dieser Endpunkt genutzt werden. Die Definition erfolgt über JSON und muss folgende Struktur aufweisen:
1 2 3 4 5 6 7 8 910
{
// Name des Forms
"name": "My Form",
// Struktur
"shape": {
...
},
// Veröffentlichungsstatus
"published": false
}
Die Struktur des Forms wird unter shape angegeben. Generell wurde sie entworfen, um eine normalisierte und hierarchiesche Struktur abbilden zu können. Dazu enthält sie auf
der ersten Ebene alle verfügbaren Knoten-Elemente. Hierzu zählen nicht nur Überschriften, Texte, Trennlinien, i-doit Kategorie-Attribute sondern auch Seiten.
Es ist sicherzustellen, dass die Knoten-IDs (root, SEITE_1, SEITE_2,…) einzigartig sind und keine Wiederholungen aufweisen.
Im folgenden ist eine vollständige Struktur eines Forms, welches aus zwei Seiten ("SEITE_1" und "SEITE_2") besteht. Dabei beinhaltet jede Seite eine Überschrift und eine
{
"Text165729439981501359363935038671": {
"children": [],
"config": {
// Type des Knotens: Text
"type": "Text",
"props": {
// Anzuzeigender Text
"text": "Page 2 Text",
// Platzhalter: Wird angezeigt, sofern der Inhalt im Frontend geleert wird
"placeholder": "Enter your text",
// Sichtbarkeit: Soll das Element versteckt werden?
"hidden": true
}
}
}
}
Dieser Typ ist im Vergleich zu den vorherigen Typen komplexer und enthält daher eine größere Anzahl an Konfigurationsparametern. Zu dem können sich eben diese Parameter je
nach Typ des Kategorieattributes noch weiter unterscheiden.
Die grundlegende Datenstruktur wird im folgenden am Beispiel des Attributes Allgemein > Bezeichnung beschrieben:
{
"Attribute165731273460305039947937820184": {
"children": [],
"config": {
// Type des Knotens: Kategorieattribut
"type": "Attribute",
"props": {
// Attribut-ID: Zusammensetzung aus der Konstante der Kategorie und des technischen Attributidentifikators
"attribute": "C__CATG__GLOBAL.title",
// Standardmäßige Bezeichnung des Feldes im Formular, sofern "label" nicht angegeben wurde
"defaultLabel": "Bezeichnung (Allgemein)",
// Feldbezeichnung
"label": "BEZEICHNUNG",
// Handelt es sich um ein Pflichtfeld?
"required": false,
// Wird das Attribut i-doit-seitig vorausgesetzt? Nativ oder aber über die Validierungskonfiguration.
"isSystemRequired": false,
// Label der Kategorie
"categoryLabel": "Allgemein",
// Attributtyp
"type": "text",
// Ist das Feld sichtbar?
"hidden": false,
// Standardwert
"defaultValue": "Vorausgefüllter Wert"
}
}
}
}
Einige Konfiguratiosparameter werden von der Forms-Addon-API vorgegeben. Sie können sowohl aus statischen aber auch dynamischen Werten bestehen:
attribute*: statischer Wert
type* : statischer Wert, gibt den Attributtypen wieder
isSystemRequired : variabler Wert, wird auf Basis der Validierung oder nativ berechnet
Dieser Parameter überschreibt required, sofern das Attribut system-seitig vorausgesetzt wird.
defaultValue : variabler Wert, wird vorausgefüllt, sofern der Objekttyp ein Default-Template adressiert, welches ein Wert für das Attribut definiert
Eine fehlerhafte Angabe von isSystemRequired wird zwangsläufig in einen Fehler beim Submit des Formulars führen, sofern required nicht true ist. defaultValue ist nicht zwingend notwendig, sofern die Werte aus dem Default-Template nicht berücksichtigt werden sollen.
All diese Informationen können, wie bereits erwähnt, über die Forms-Addon-API ermittelt werden:
1
GET https://idoit-instance/forms/api/attribute?category=C__CATG__GLOBAL,C__CATG__ACCOUNTING&class=C__OBJTYPE__SERVER
Hierbei enthält category eine kommaseparierte Liste an Kategoriekonstanten. class hingegen enthält die Objekttypkonstante und wird benötigt, um defaultValue zu ermitteln. Die Rückgabe sieht beispielhaft wie folgt aus:
i-doit verfügt über Attribute, welche eine Abhängigkeit zu einem anderen Attribut innerhalb der Kategorie aufweist. Ein sehr einfaches Beispiel ist hierbei das Attribut Modell > Modell, welches von Modell > Hersteller abhängt.
Hierfür enthält das Forms-Addon Frontend Kontrollmechanismen, um beispielsweise die Nutzung von Modell > Modell (Child) ohne Modell > Hersteller erkennt und in diesem Fall das Parentattribut automatisch hinzufügt.
Diese Attribute lassen sich aufgrund ihrer Metadaten identifizieren. Hierbei enthält das Childattribut eine parent- und das Parentattribut eine children-Information:
GET https://idoit-instance/forms/api/attribute?category=C__CATG__MODEL&class=C__OBJTYPE__SERVER