Das Konzept der Daten-Layer:

Nicht alle zu einem Objekt abrufbaren Daten müssen direkt beim Objekt abgespeichert sein. Ist ein abgefragter Parameter nicht beim Objekt gespeichert, wird bei den zum Objekt gesetzten Vorlage-Objekten nach dem Wert gesucht (falls nichts anderes vorgegeben wurde).

Daneben gibt es noch eine zweite Art der "Schichtung" von Parameterwerten in der WIM-aPP: Über die von einem Server geholten Parameterwerte können noch nutzerdefinierte Werte gelegt werden, für die spezifiziert werden muss, wie sie sich gegenüber den "überlagerten" Werten aus der Server-Datenbasis verhalten.

Darüber gibt es noch die Parameterwerte der "Sitzungsebene". Also solche Werte, die auch ohne Login verfügbar sind. Diese Werte verhalten sich gegenüber den Daten der Nutzerschicht wie die Daten der Nutzerschicht gegenüber denen der Datenbasis-Schicht.

Aktualisierung der Parameterwerte:

Werden Daten auf der Sitzungs- der Nutzerebene geändert, stehen die aktuellen Daten direkt zur Darstellung bereit. Werden Daten auf dem Server verändert, muss dieses in Richtung wim-aPP weitergemeldet werden.

Vom Backend-Server wird allen abgefragten Daten zu einem Objekt ungefragt entweder der Wert des OUTDATED-Parameters oder bei Nichtvorhandensein der Wert des STORED-Parameters mitgegeben. Letzterer stellt eine Art Versionsnummer der Objektdaten dar.

Ebenso wird von den Frontend-Servern den abfragenden wim-aPPS der Wert des OUTDATED- bzw. STORED-Parameters stets beigefügt.

Der Wert des OUTDATED-Parameters wird vom Source-Server bzw. beim Speichern in der "alten" Datenbasis gesetzt. Werden aktuelle Daten (vom Frontend-Server oder WIM-App) empfangen, wird der OUTDATED-Parameterwert gelöscht.

tbd: ((( UPTODATE -Parameter zur Beschaffung aktueller Daten(versionen) )))

tbd: ((( Zu erläutern: "Vorlagen" vs."Alternativen". => Erst wird eine spezifizierte Vorlage über alle Ebenen abgearbeitet, bevor eine alternative Angabe berücksichtigt wird. )))