Auswahl des zu öffnenden Portals

Für die Definition des zu öffnenden Portals gibt es zwei Methoden, die ggf. auch in Kombination genutzt werden können:

• Ist für die Aktion ein Zielelement verknüpft, das zur Laufzeit einen Textwert zurückgibt, dann wird dieser als Name des zu öffnenden Portals verwendet.

  • Der Name muss unter Beachtung der Groß-/Kleinschreibung exakt einem Portalnamen entsprechen.

  • Besteht zur Laufzeit kein Zugriff auf ein Portal mit dem angegebenen Namen, dann bricht die Aktion ab (s. ►WICHTIG◄ oben).

• Ist kein Zielelement verknüpft oder liefert das verknüpfte Zielelement zur Laufzeit keinen Wert ($null), dann wird die optionale statische Definition eines Portals in der Konfiguration der Aktion ausgewertet:
  

  • Die unbeschriftete Combobox unterhalb von Typ der Aktion bietet sämtliche Portale zur Auswahl an, für deren Konfiguration im Kontext der Sitzung Lesezugriff besteht.

  • Ob diesen Portalen Zuordnungskriterien zugewiesen sind und ob diese aktuell treffen, beeinflusst die Auswahlmöglichkeit per Dropdown nicht.

  • Zur Laufzeit muss das angegebene Portal allerdings "greifbar" sein, wenn es geöffnet werden soll, sonst bricht die Aktion ab (s. ►WICHTIG◄ oben).

►ANMERKUNG◄ Im Unterschied zu anderen Konfigurationselementen muss jeder "Portalname" systemweit eindeutig sein. Zuordnungskriterien (und deren Sichtbarkeit im Kontext einer einer Sitzung) kontrollieren daher zwar den Zugriff auf ein eindeutig adressiertes Portal. Eine Auswahlentscheidung zwischen Alternativen, wie beim Adressieren einer View über den angegebenen Kontext (s. Öffne View (Formulardesigner)), spielt dagegen keine Rolle.

Datenzuweisung an das geöffnete Portal

Per Standard werden dem geöffneten Portal die anliegenden Verhaltensdaten ($input) zugewiesen. Sofern keine spezifischeren Mechanismen erforderlich sind, ermöglicht die Verhaltensweise Element validieren zur Vorbereitung einer "Zuweisung" von (validen) Elementdaten aus dem aktuellen Formular an das geöffnete Portal.

• Die Option Mit leeren Daten sollte dringend gesetzt werden, wenn ein Portal zuverlässig ohne Datenzuweisung geöffnet werden soll. Wenn beispielsweise in einem Verhalten für einen Button der Auslöser Angeklickt mit einer Verhaltensweise Statisch kombiniert wird, um die Aktion Öffne Portal auszuführen, würde ohne diese Option der Standardwert true (als $input vom Button) dem geöffneten Portal als Formulardaten zugewiesen, was dort unerwünschte Effekte hervorrufen kann.

Parameter für das Öffnen des Portals

Abläufe beim Schließen des Portals

Der optionale Parameter Verhalten nach Schließen ausführen ermöglicht die Auswahl eines für das aufrufende Formularelement konfigurierten Verhaltens.

• Dieses Verhalten wird ausgeführt, sobald das Fenster mit dem adressierten Portal geschlossen wird.

• Abhängig von den Optionen Nur eine Instanz, Modal und Schließbar greifen die dort beschriebenen Details.

►WICHTIG◄ Daten aus dem geöffneten Portal werden an das "Verhalten nach Schließen" nur weitergegeben, wenn dort per Aktion Schließen anfordern mit entsprechenden Eingabedaten ausgeführt wird.

Aufgabenstellung

In einem einem Portal "Meeting planen" sollen die Teilnehmer des geplanten Meetings festgelegt werden, indem die Daten existierender Benutzer von Lobster Data Platform / Orchestration einem Datengrid ("Teilnehmerliste") als neue Zeilen hinzugefügt werden:

• Zur Auswahl der Teilnehmer wird beim Klick auf den Button "Suche" ein bestimmtes Suchportal modal geöffnet (s. roter Pfeil).

• Per Auswahlfeld/Combobox "Suchprofil" bietet das aufrufende Portal zwei alternative Methoden ("Benutzername" oder "Benutzername ODER Name 1-3") zur Auswahl an. Jeder Auswahl entspricht ein Suchportal, dessen Portalname als statischer Schlüsselwert hinterlegt ist.

• Das ausgewählte Suchportal bietet unter Berücksichtigung eines Suchtexts aus dem ausrufenden Portal ("... enthält ...") in einem Datengrid "passende" Benutzer zum Anklicken an (s. grüner Pfeil).

• Beim Klick auf einen der gefundenen Benutzer im Suchportal wird dieses geschlossen und der betreffende Eintrag der "Teilnehmerliste" im aufrufenden Portal hinzugefügt (s. oranger Pfeil).

• Die Suche soll auch ohne eine Auswahl beendet werden können, indem das "X" Symbol rechts oben im modalen Fenster geklickt wird.

Konfiguration

Nachfolgend wird nur die Konfiguration für Komponenten ausführlich beschrieben, die direkt mit der Öffne Portal-Aktion zu tun haben.

Verhalten zum Aufruf des Suchportals:

• Für den Button "Suche" wird ein Verhalten "userSearch" eingerichtet, das auf den Auslöser Angeklickt reagiert (roter Pfeil).

• Die Verhaltensweise Element validieren wird mit dem Spaltenlayout-Element (# 9) angewendet, das das Textfeld für das Suchkriterium mit der Beschriftung "... enthält ..." enthält (grüner Kasten, grüner Pfeil). Damit stehen die betreffenden Elementdaten im weiter unten per Aktion geöffneten Portal zur Verfügung. Hier wurde dem Textfeld das Datenfeld criterion zugewiesen, mit dem auch im Suchportal (s. u.) gearbeitet wird.

• Die Aktion Öffne Portal gibt als Zielelement das Auswahlfeld/Combobox "Suchprofil" an. Dieses liefert den Namen eines der alternativ verwendbaren Suchportale (USER_SEARCH_SIMPLE oder USER_SEARCH_ADVANCED) als Textwert auf der Basis der folgenden Service-Konfiguration:
  

  

  
  Außerdem verweist das Dropdown in der Konfiguration auf das Portal USER_SEARCH_SIMPLE als Standard, falls keine Auswahl getroffen wird.

• Die Option Mit leeren Daten ist nicht gesetzt, damit die Verhaltensdaten (mit dem Suchkriterium) an das Suchportal zugewiesen werden. Weitere Details hierzu beschreibt die Konfiguration der Suchportals (unten).

• Das Portal soll Modal und Schließbar geöffnet werden und hinsichtlich Breite und Höhe angepasst werden können (s. Größe veränderbar).

• Der Parameter Verhalten nach Schließen ausführen verweist auf ein weiteres Verhalten "addToList" das für denselben Button ("Suche") definiert sein muss und die Verarbeitung des Rückgabewerts vom Suchportal (orange Pfeile) definiert.

Konfiguration im Suchportal:

Hier wird nur das Suchportal USER_SEARCH_SIMPLE dargestellt. Das alternative Suchportal USER_SEARCH_ADVANCED ist analog aufgebaut, verwendet aber eine abweichende Bedingung für die Tupel Suche (Formulardesigner).

• Das Textfeld "Benutzername enthält" verweist auf das Datenfeld criterion (passend zum Textfeld "... enthält..." im aufrufenden Portal) und wird deshalb beim Öffnen des Portals mit demselben Text belegt.

• Für dieses Textfeld ist das rechts abgebildete Verhalten definiert, das auf den Auslöser Geändert mit allen Änderungstypen reagiert. Effektiv ist hier nur "Formulardaten geladen" als Änderungstyp relevant, da Wertänderungen innerhalb des Formulars nicht vorgesehen sind.

• Die Verhaltensweise Tupel Suche (Formulardesigner) verwendet eine Verknüpfung auf das im Bild grün markierte Spaltenlayout. Die im Textfeld "Benutzername enthält ..." übergebene Zeichenfolge steht damit innerhalb der Such-Konfiguration als Wert einer Variablen mit dem Namen criterion (Datenfeldname des Textfelds) zur Verfügung. Die Tupel Suche (Formulardesigner) soll nur Daten von Benutzern zurückgeben, deren Benutzername (username) diesen Wert enthält. Das wird z. B. durch die folgende Feld Einschränkung in der Bedingung der Tupel Suche (Formulardesigner) erreicht:
  

  

• Das Suchergebnis der Tupel Suche (Formulardesigner), Projektionen für die Felder ID (id), Benutzername (username), Name 1 (address.name1), Name 2 (address.name2) und Name 3 (address.name3), wird per Grid: Füllen-Aktion dem Datengrid "Benutzer" zugewiesen. Dessen Spaltenkonfiguration verwendet die Datenfeldbezeichner id, username, address_name1, address_name2, address_name3 für die entsprechenden Spalten. Dabei ist wichtig, dass bei den drei Name-Feldern ein Unterstrich anstelle des Punkts verwendet werden muss, da in der Tupel-Suche automatisch ein entsprechender Alias erzeugt wird.

Verhalten nach Schließen des Suchportals: