Einblick in die Elementdatentechnik
Wann auch immer in Lobster Data Platform / Orchestration eine konfigurierte Maske aufgerufen wird, kommt immer die gleiche Technik zum Befüllen oder Lesen der Elementdaten zum Einsatz.
Dieses Kapitel geht dabei relativ detailliert auf die Funktionsweisen und Regeln dieser Technik ein, um bestimmte und oftmals fälschlicherweise als Fehler deklarierte Zustände der Daten zu erläutern.
Elementdaten und Datenstrukturen werden zur einfachen Visualisierung im JSON-Format dargestellt. Es ist beim Aufbau einer Maske mit frei definierbaren Datenfeldern sogar empfehlenswert, dass der Ersteller ausschließlich in solchen Strukturen "denkt".
Wie bereits einleitend erwähnt kommt die hier erläuterte Technik in allen konfigurierten Masken (Geschäftsobjekte, Portale/Dashboards, ...) zum Einsatz. Jedoch sind die Datenfelder nicht für alle Maskentypen frei definierbar. Daher werden nachfolgende Erklärungen im Kontext von Lobster Data Platform / Orchestration-Portalen untermalt.
Formulardaten, Elementdaten, Werte und Datenfelder
Zunächst müssen einige Begrifflichkeiten eingeführt werden.
Jedes Element in einem konfigurierbaren Formular (oder auch Maske) kann ein Datenfeld definieren, welches verwendet wird, um den Wert des Elements zu lesen.
Daten, welche in Form eines Objektes in das gesamte Formular geladen werden, heißen Formulardaten.
Daten, welche von einem Element als Quelle zum Lesen ihres Wertes verwendet werden, heißen Elementdaten.
Simples Beispiel für Datenfelder und Elementdaten
Zwei Textfelder mit den Datenfeldern "text1" und "text2" werden im Formular angelegt.
Mit Hilfe der Ribbon-Funktion "Struktur Export" kann die Datenstruktur des Portals angezeigt werden.
{ "text1": "abc", "text2": "def"}Das dargestellte JSON-Objekt { } entspricht dabei den Formulardaten. Die Felder "text1" und "text2" (definiert über die Datenfelder der Elemente) werden als Werte der Elemente bezeichnet ("abc" und "def").
Vereinbarung 1:
Dieses simple Beispiel zeigt bereits einen sehr wichtigen Sachverhalt auf: Elemente lesen und schreiben ihre Daten stets in die Daten ihres übergeordneten Elements (in diesem Fall die Formulardaten).
Vereinbarung 2:
Definiert ein Element kein eigenes Datenfeld, so sind seine Daten dieselben wie die seines übergeordneten Elements (keine Kopie!). Sie werden als Effekt also einfach "durch gereicht" (im Beispiel oben wäre das beim Abschnittelement der Fall). Werte eines solchen Elements können folglich auch nicht in der Datenstruktur des Portals auftauchen.
Dieser Tatsache ist ebenfalls geschuldet, dass Elemente ohne Datenfeld, welche jedoch einen Wert erwarten, keinen oder einen seltsamen Wert darstellen.
Am Beispiel eines Textfeldes ohne definiertes Datenfeld:
Das Textfeld stellt "[object Object]" dar, da es versucht, die Daten des übergeordneten Elements (in diesem Fall ein anonymes Objekt { } ) als Text zu laden. Beim Umwandeln eines Objektes in einen Text resultiert eben dieser kryptische Text "[object Object]".
Ferner würden solche Felder auch keine Standardwerte laden, da dies nur geschieht, wenn die Daten hinter dem Datenfeld leer (null) sind. Ein Objekt gilt allerdings nicht als leer (null) und somit wird kein Standardwert mehr geladen.
Arbeiten mit Datenfeldern
Wie bereits oben erwähnt gibt das Datenfeld eines Elements den "Schlüsselnamen" der Daten an, welche in das Element geladen werden sollen. Oben wurde bereits ein simples Beispiel mit "text1" und "text2" gezeigt.
Durch Verschachteln von Elementen in Containerelemente, werden die Daten des Formulars kaskadierend zusammengesetzt. Siehe nachfolgendes Beispiel:
Elementbeschriftung entspricht ihren Datenfeldern (ausgenommen Abschnitt).
Oben konfiguriertes Beispiel resultiert in nachfolgender Datenstruktur.
{ "driver": { "firstname": "Jonas", "lastname": "Abend" }}Durch die Verschachtelung der Elemente werden die Daten des Formulars kaskadierend zusammengesetzt.
Alternativ hierzu kann ein Datenfeld auch als ganzer "Schlüssel"-Pfad definiert werden. Die Pfadteile werden dabei mit Punkten "." voneinander getrennt. Siehe unten (driver.):
Elementbeschriftung entspricht ihren Datenfeldern (ausgenommen Abschnitt).
Auch diese Konfiguration resultiert in oben gezeigter Datenstruktur.
Zugriff auf Listendaten via Datenfeld
Liegen einem Element Listendaten vor, kann als Pfadteil auch der Index eines gewünschten Listenelements als Zahl angegeben werden.
Beispiel:
Ein Profil liefert eine Liste von Fahrzeugteilen zu einem bestimmten Auftrag. Die Lieferscheinnummer, welche bei sämtlichen Teilen identisch ist, soll in einem separatem Textfeld ausgegeben werden.
Das Formular besitzt ein konfiguriertes Verhalten "loadParts", welches ein Profil ruft, das eine Liste von Autoteilen und identischer Lieferscheinnummer (dn_number) liefert.
Als Aktionen wird zunächst "In die Konsole loggen" eingebunden. Dies dient zum Anzeigen der Rückgabedaten des Profils, um zu überprüfen, ob das Gewünschte Ergebnis an die Aktionen geliefert wird.
Das Öffnen der Browserkonsole (i.d.R. Taste F12) gibt dann beim Ausführen des Portals Einsicht in die geloggten Daten. Siehe unten:
Mit der Aktion "Elementdaten setzen" wird diese Liste dann in den "Teile" Container geladen (dieser hat selbst kein Datenfeld definiert).
Da das im "Teile" Container enthaltene Textfeld als Datenfeld "0.dn_number" definiert, liest es den "dn_number" Wert des ersten (0ten) Elements der Liste, wie unten gezeigt.
