Typprüfung

<Typauswahl>
(erforderlich)

Das übergebene Objekt entspricht dem Typ <Typauswahl>. Die Auswahl eines Typs ist dabei erforderlich.

<Typauswahl>
(optional)

Das übergebene Objekt ist eine Liste, die kein Objekt enthält, das nicht dem ausgewählten Typ entspricht. Die Auswahl eines Typs ist dabei optional. Ohne eine Auswahl werden Einträge beliebiger Typen akzeptiert.

►HINWEIS◄ Die Prüfbedingung klingt etwas umständlich, wurde aber mit Blick auf die folgenden Sonderfälle gezielt so formuliert:

• Eine Liste mit Objekten unterschiedlicher Typen besteht eine Typprüfung nur ohne <Typauswahl> oder wenn ein weniger spezifischer (übergeordneter) Typ ausgewählt wird, z. B. "Benutzer > Schnittstelle" für eine Liste, die Benutzer und Gastbenutzer enthält.

• Eine Liste ohne Einträge besteht jede Typprüfung mit der Option Ist Liste von unabhängig von einer <Typauswahl>.

<Typauswahl>
(erforderlich)

Das übergebene Objekt entspricht dem Typ <Typauswahl>
ODER es wurde kein Objekt übergeben ABER der Kontext (z. B. eine Übersicht) bezieht sich auf den Objekttyp.

Als Typhinweis wird die Variable entityClass ausgewertet, die abhängig vom Kontext automatisch mit einer "Klasse" (s. Statische Werte) befüllt wird.

Beispiel im Kontext einer Übersicht für Benutzer:

<core:Storage xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:base="SCM.BASE" xmlns:core="CORESYSTEM">
   <data>
      <entry>
         <key xsi:type="xsd:string">entityClass</key>
         <value type="base:User" xsi:type="ClassValue"/>
      </entry>
   </data>
</core:Storage>

►HINWEIS◄ Wird ein Eigenes Aktionsevent per Ereignisaktion ausgelöst (Eigenes Aktionsevent auslösen (Aktion)), dann wird die Variable entityClass im Unterschied zu anderen Variablen nicht in den zugehörigen Ausführungskontext übergeben, sondern ausgehend vom übergebenen Objekt spezifisch für diesen Kontext ermittelt. Bezieht sich der Wertauflöser für das Datenobjekt in der Konfiguration der Ereignisaktion auf eine Variable, für die zur Laufzeit kein Wert vorliegt, bestimmt die Parametrierung dieses Wertauflösers den "Typhinweis" (über die Variable entityClass).

Beispiel:

• Im Kontext einer Ereignisbehandlung, die auf das ausgehend von dieser Konfiguration ausgelöste Eigene Aktionsevent reagiert, verweist der "Typhinweis" (via Variable entityClass) auch dann auf den Typ "Benutzer" (User), falls die Variable "newUser" keinen Wert ($null) enthält.

<Typauswahl>
(optional)

Das übergebene Objekt ist eine Liste, die kein Objekt enthält, das nicht dem Typ <Typauswahl> entspricht
ODER es wurde kein Objekt übergeben ABER der Kontext liefert Anhaltspunkte für die Übergabe einer Liste.

►HINWEIS◄ Die Prüfung für den "Typhinweis bei leerem Wert" bezieht sich ausdrücklich nicht auf die <Typauswahl>. Ohne ein konkretes Objekt kann also nur unspezifisch festgestellt werden, ob die Variable entityClass einen Typ ausweist, der als Liste gilt.

Beispiel:

• Diese Typprüfung gilt als bestanden, wenn als Eingangsobjekt eine Liste übergeben wird, die ausschließlich Benutzer enthält.

• Eine Liste ohne Einträge besteht die Prüfung, auch wenn es nicht um den Typ "Benutzer" (User) geht (s. a. Hinweise zum zweiten Fall oben). Die Option Typhinweis bei leerem Wert prüfen hat darauf keinen Einfluss, weil eine Liste ohne Einträge als Eingabewert übergeben wird und nicht "Kein Wert" ($null).

• Die Option Typhinweis bei leerem Wert prüfen ist allerdings relevant, wenn keine Liste übergeben wird, aber der Kontext auf eine Liste hindeutet.
  Das ist z. B. der Fall, wenn das Datenobjekt für ein Eigenes Aktionsevent durch einen Regel-Listen Resolver mit der Option Alle Werte als Liste definiert wird, der zur Laufzeit keine Treffer als Ergebnis zurückgibt:
  
  

   
  

  • 
    

    • Im Beispiel bündelt ein Erzeuge Liste-Wertauflöser Benutzer als Einträge einer Liste, die über je eine Variable (creator , modifier) bereitgestellt werden.

      • Über das ausgelöste Eigenes Aktionsevent "Send Email" (SEND_EMAIL) sollen alle aufgelisteten Personen benachrichtigt werden, sofern es sich nicht um den angemeldeten Benutzer handelt.

        • Der verkettete Regel-Listen Resolver in der Wert-Konfiguration für das Datenobjekt unterdrückt" Listeneinträge, die sich per "ID" (id) auf den Benutzer der Session beziehen.

          • Falls sich beide Variablen (creator und lastModifier) auf den Benutzer der Session beziehen, gibt der Regel-Listen Resolver nicht etwa eine leere Liste ([]) zurück, sondern "Kein Wert" ($null).

          • Für eine Ereignisbehandlung, die durch das "Send Email" auusgelöst wird und deren Typprüfung wie oben konfiguriert ist (Typ "Benutzer", Typhinweis bei leerem Wert prüfen ausgewählt, Ist Liste von ausgewählt), bedeutet das:

            • Der Rückgabewert "Kein Wert" ($null) entspricht zwar nicht dem Typ ("Benutzer"), aber er gilt als "leerer Wert". Da die Option Typhinweis bei leerem Wert prüfen ausgewählt ist, gibt der Typhinweis den Ausschlag.

            • Als Typhinweis (s. a. Wert der Variable entityClass im Kontext der ausgelösten Ereignisses) gilt "Liste" (List), weil im Regel-Listen Resolver die Option Alle Werte als Liste ausgewählt ist.

            • Die Typprüfung gilt als bestanden, weil der Eingabewert leer ist und der Typhinweis geprüft werden soll und dieser Typhinweis "Liste" (List) lautet, was zur ausgewählten Option Ist Liste von passt.

              • Die Auswahl für den Typ innerhalb der Typprüfung ("Benutzer") spielt keine Rolle, wenn nur der Typhinweis geprüft wird, weil kein Wert vorliegt.