Die zu öffnende View kann entweder per direkte Texteingabe oder über einen Wertauslöser adressiert werden.

Eine View wird nur geöffnet, wenn ...

1. ... die angegebene Zeichenfolge einem existierenden Menüknotennamen oder Viewnamen exakt entspricht,

2. ... für die verwendete Rolle ausreichende Berechtigungen vorliegen und ...

3. ... falls anwendbar - zur Laufzeit mindestens eine relevante Konfiguration für den betreffenden Kontext zugeordnet ist (s. Zuordnungskriterien, Firmenfreigaben).

Ob die folgenden Beispielwerte für den Parameter Zu öffnende View funktionieren, hängt teilweise zusätzlich davon ab, welche Module von Lobster Data Platform / Orchestration lizenziert sind:

• documentation ... öffnet das Orchestration per Menüknotenname

• documents ... öffnet Übersicht Dokumente per Menüknotenname (sofern Modul lizenziert)
  oder de.lobster.scm.doc::Document|listDetailsWindow ... per Viewname

• order/orderDetails ... öffnet eine Erfassungsmaske für Bestellungen per Menüknotenname
  oder de.lobster.scm.order.bto::Order|detailsWindow ... dito per Viewname

• Portal$SELECT_PORT ... öffnet ein Portal mit dem internen Namen SELECT_PORT per Viewname

• dashboard$KPI2020 ... öffnet ein Dasboard mit dem internen Namen KPI2020 per Viewname

►HINWEIS◄ Per Klick auf den grauen Pfeil links unten im Eingabefeld für den Parameter Portal XML kann vom Direkteingabemodus zur Definition eines Wertauflösers gewechselt werden:

Wenn eine View nicht geöffnet werden kann, tritt keine Exception auf. Die Ereignisbehandlung wird dann in der Regel sofort fortgesetzt, also auch ohne eine ggf. parametrierte Wartezeit Wertrückgabe (s. u.) abzuwarten.

Wie kann man den Viewnamen und den Menüknotennamen ermitteln?

Viewname und Menüknotenname einer bereits geöffneten View können per Klick auf das ?-Symbol rechts oben im Fenstertitel ermittelt werden, was am Beispiel einer Erfassungsmaske für Bestellungen folgende Meldung ergibt (Textmarkierung nachträglich hinzugefügt):

Die erste markierte Zeile definiert den Viewnamen einer Detailsicht (detailsWindow), adressiert also eine Erfassungsmaske für Bestellungen.

►WICHTIG◄ Zum Öffnen einer View darf nicht die Kurzschreibweise aus der Zeile oberhalb verwendet werden, in der anstelle des vollständigen Klassennamens das zugehörige Namespace-Präfix erscheint. Auch die Kontexteinträge mit dem Wildcard-Symbol * sind nicht geeignet, um die View zu adressieren.

Die zweite markierte Zeile definiert den Menüknotennamen (order/orderDetails) für dieselbe View, der dem Menüpfad im Hauptmenü ("Bestellungen/Bestelldetails") entspricht.

►HINWEIS◄ Der Menüknotennamen erscheint hier nicht, wenn eine View nicht über die Hauptmenüleiste geöffnet wurde, sondern z. B. per Öffne View (Aktion) oder per Klick auf eine Funktion im Ribbon ("Neu" oder "Bearbeiten") einer Übersicht. Dann besteht auch kein Zugriff auf Hilfethemen (s. Online Hilfen), die mit dem Menüknotennamen verknüpft sind.

Die Wert-Konfiguration für den Parameter Formulardaten kann auf unterschiedliche Weise genutzt werden, dynamisch ermittelte Informationen an die Zu öffnende View zu übergeben, sofern diese das überhaupt vorsieht.

Entscheidend ist dabei der Datentyp, der vom Wertauflöser zurückgegeben wird in Kombination mit dem Typ der zu öffnenden View.

Öffnen einer View vom Typ Erfassungsmaske (detailsWindow):

• Wenn ein Long-Wert oder ein kompatibler simpler Wert (z. B. ein Text wie "4711") als Formulardaten übergeben wird, lädt die geöffnete Erfassungsmaske die Daten der Entität mit der betreffenden ID, sofern diese existiert und mindestens Lesezugriff besteht.
  

  • Falls die Entität nicht existiert, erscheint die Erfassungsmaske "leer" (ohne Daten).

  • Besteht kein Lesezugriff für die "angeforderte" Entität erscheint eine Fehlermeldung (Notification vom Typ "Error") und die Erfassungsmaske wird "leer" geöffnet.
    Es tritt aber keine Exception auf, sodass die Ereignisbehandlung entweder sofort, nach Ablauf der Wartezeit oder beim Schließen der View fortgesetzt wird.
    
    

• Wird als Formulardaten ein beliebiges Datenobjekt (keine Entität des mit der Erfassungsmaske verknüpften Datentyps) übergeben, das auf Kopfebene über ein id-Feld mit einem als Long interpretierbaren Wert verfügt, wird unter den Entitäten des durch die Erfassungsmaske bestimmten Typs nach einer Instanz mit dieser id gesucht, um diese anzuzeigen. Diese Logik ist z. B. hilfreich, wenn die anzuzeigende View eine Entität anzeigen soll, die im Kontext der aufrufenden Ereignisbehandlung über eine Tupel-Suche ermittelt wurde, die u. a. eine Feldprojektion für das Feld "ID" (id) enthält. Jeder Ergebniswert aus dieser Suche ist dann ein Client-Objekt mit einem id-Feld. Wird dieses Client-Objekt als Formulardaten zugewiesen, erfolgt der Abruf der kompletten Entität beim Öffnen der Erfassungsmaske automatisch.
  
  

• Wird als Formulardaten eine komplette Entität übergeben, deren Typ dem Kontext der zu öffnenden Erfassungsmaske entspricht, dann stellt diese Entität direkt die Formulardaten für die geöffnete Erfassungsmaske. Dies ist auch dann der Fall, wenn das betreffende Datenobjekt noch nicht gespeichert wurde. Per Erzeuge Instanz kann z. B. auch das Datenobjekt für eine neue Entität bereitgestellt werden. Dabei wird das Ereignis "Neu" (s. Allgemein (Ereignisse)) allerdings nicht ausgelöst.
  
  ►WICHTIG◄ Eine Erfassungsmaske registriert nur Änderungen als "ungespeichert", die nach dem Öffnen des Formulars vorgenommen werden. Wenn eine per Öffne View (Aktion) übergebene Entität durch vorher ausgeführte Ereignisaktionen neu erstellt und/oder verändert wurde, erkennt die Maske nicht, dass diese Änderungen noch gespeichert werden sollten. Sofern nicht innerhalb des Formulars noch interaktiv oder automatisiert weitere Änderungen vorgenommen werden, entfällt die übliche Warnung ("Änderungen verwerfen?") vor einem "Abbrechen" oder "Schließen" der View und die angezeigten Daten gehen ggf. teilweise oder insgesamt verloren.

Öffnen einer View vom Typ Übersicht (listSearchView):

• Wird als Formulardaten eine Suche (ein Search-Objekt) als Datenobjekt für eine reine Übersicht (listSearchView) bereitgestellt, dann wird aus deren Definition eine Sub-Suche erzeugt, die als "Einschränkung" für die geöffnete Übersicht wirkt. Die geöffnete Übersicht listet dann nur Entitäten auf, die den Suchkriterien der übergebenen Suche entsprechen. Wird eine Eigene Übersicht (s. Eigene Übersichten) geöffnet, deren Definition bereits eine "Einschränkung" vorsieht, dann wird diese per UND-Verknüpfung (s. Such-Verknüpfung) mit der Sub-Suche kombiniert. Dieser beim Öffnen zugewiesene "Filter" kann auch nicht entfernt werden, indem per Ribbon der Befehl "Liste / Zurücksetzen" ausgeführt wird.
  
  

• Wenn als Formulardaten ein Datenobjekt übergeben wird, das eine "Sucheinschränkung" (ISearchRestriction, s. Einschränkungen) beschreibt, wird dieses entweder direkt als "Einschränkung" für die geöffnete Übersicht oder wird - im Fall einer Eigenen Übersicht - mit der ggf. vordefinierten "Einschränkung" UND-verknüpft.

►WICHTIG◄ Im Kontext einer der Suche (erster Fall oben) können Joins verwendet werden, um die Suche direkt (als INNER JOIN) oder über Bedingungen, die sich über Projektionen auf Joins beziehen, da diese in die erzeugte Sub-Suche-Einschränkung übernommen werden können. Wird stattdessen eine "Sucheinschränkung" bereitgestellt, ist die Verwendung von Joins potenziell heikel, wenn diese nicht über eine Verkettete Projektion abgebildet werden. Sofern die "Sucheinschränkung" Projektionen verwendet, die sich auf einen "Join Alias" beziehen, kann die Einschränkung zur Laufzeit nur fehlerfrei funktionieren, wenn die beim Öffnen der View über Zuordnungskriterien dynamisch zugewiesene Datengrid-Definition in jedem Fall einen "passenden" Join mit diesem "Join Alias" beinhaltet. Ist der Join nicht vorhanden, tritt beim Öffnen eine Datenbank-Fehlermeldung auf und die Übersicht wird ohne Daten geöffnet.

• Entsprechen die Formulardaten beim Öffnen einer Übersicht einem der unter "Öffnen einer View vom Typ Erfassungsmaske" aufgeführten Inhalte (Long-Wert, komplette Entität usw.), dann sind zwei Fälle zu unterscheiden:
  
  

  • Handelt es sich bei der geöffneten View um eine kombinierte Ansicht (listDetailsWindow), die ein Datengrid mit einem als Erfassungsmaske definierten Detailbereich verbindet, dann wird die per Formulardaten übergebene oder referenzierte Entität im Datengrid selektiert und die zugehörigen Details erscheinen im Detailbereich.

• • Handelt es sich bei der geöffneten View um eine reine Übersicht (listSearchWindow) wird primär eine View mit der Übersicht geöffnet. Andererseits wird die im Kontext anwendbare Erfassungsmaske (detailsWindow) in einer weiteren View geöffnet, um das per Formulardaten übergebene oder referenzierte Datenobjekt anzuzeigen.

    • Die Erfassungsmaske in zweiten geöffneten View wird dabei genau so behandelt, als wäre ein Doppelklick auf die entsprechende Entität im Datengrid der Übersicht erfolgt. Sie wird nicht-modal in einer komplett eigenständigen View anzeigt, für die die Parametrierung bzgl. Anzeigeverhalten (s. u.) in der Öffne View (Aktion) keine Relevanz hat. Außerdem ist das Warten auf eine Datenrückgabe aus der indirekt geöffneten Erfassungsmaske nicht vorgesehen.

    • Falls eine per ID referenzierte Entität nicht "gefunden" wird, weil sie nicht existiert oder kein Lesezugriff besteht, wird die Erfassungsmaske "leer" geöffnet.

Der optionale Parameter Variablenname des Rückgabeobjekts kann verwendet werden, um den Namen einer Variablen anzugeben, über die auf Rückgabedaten aus der geöffneten View zugegriffen werden kann, sofern ...

• eine Wartezeit Wertrückgabe >0 (Einheit: Sekunden) konfiguriert ist ...

• und im Portal zur Laufzeit vor Ablauf dieser Wartezeit die Aktion Schließen anfordern ausgeführt wird.

Verstreicht eine Wartezeit Wertrückgabe (>0 Sekunden) ohne dass Schließen anfordern ausgeführt wird, wird die View automatisch geschlossen und die Rückgabedaten sind leer.

Ist dagegen als Wartezeit Wertrückgabe der Wert 0 (Standard) eingestellt, wird die Ereignisverarbeitung sofort nach dem Öffnen der View und ohne Rückgabedaten abzuwarten fortgesetzt.

►HINWEIS◄ Der Parameter Wartezeit Wertrückgabe kann auch ohne Angaben für Variablenname des Rückgabeobjekts genutzt werden, um eine bestimmte View für begrenzte Zeit anzuzeigen.

ACHTUNG Wenn eine Erfassungsmaske nach Ablauf der Wartezeit Wertrückgabe geschlossen wird, gehen ungespeicherte Änderungen ohne Rückfrage verloren.

►WICHTIG◄ Die Wartezeit Wertrückgabe muss >0 sein, damit das Portal überhaupt "synchron" aufgerufen wird. Nur dann werden Rückgabedaten aus einer Schließen anfordern-Aktion im Portal abgewartet.

Wird das Portal geschlossen, ohne dass dabei die Schließen anfordern-Aktion mit den zurückzugebenden Daten als Eingabewert ($input) ausgeführt wird, bleibt die Rückgabeobjekt-Variable leer. (s. a. Option Schließbar unten).

Wenn die Option Modal nicht ausgewählt ist (Standard), soll die View als eigenständige View geöffnet werden. Dann entscheidet die Option Darf nur einmal geöffnet sein?, ob die View auch dann geöffnet wird, wenn schon (mindestens) eine Instanz der View nicht-modal - also als eigenständige View - geöffnet ist.

Ist die Option Modal ausgewählt, wird die View beim Öffnen innerhalb der aktuellen View angezeigt. Die Option Darf nur einmal geöffnet sein? wird dann nicht beachtet. In der Konfiguration erscheinen außerdem zusätzliche Optionen:

• Die Option Vollbild entscheidet, ob eine modal geöffnete View die aktuelle View als "Vollbild" ("flächendeckend") ausfüllen oder als Dialogfenster zentriert innerhalb der aktuellen View erscheinen soll.
  
  

  • Ist diese Option abgewählt (Standard), werden zusätzliche Parameter eingeblendet, die die Dimensionierung des Dialogfensters betreffen (Breite, Höhe, Min. Breite und Min. Höhe). Diesen können optional ganzzahlige Werte (Einheit: Pixel) zugewiesen werden.
    
    

  • Das Auswahlfeld für Größe veränderbar betrifft ebenfalls nur für die Darstellung als Dialogfenster (also: Vollbild abgewählt). Die gewählte Option steuert, ob die Höhe und/oder Breite des Dialogs zur Laufzeit interaktiv geändert werden kann oder nicht.
    
    

• Die Option Schließbar ist per Standard ausgewählt. Sie kann abgewählt werden, um zu verhindern, dass die Titelleiste des modalen Fensters das X-Symbol zum Schließen einer modal angezeigten View anzeigt. Dies ist empfehlenswert, wenn eine Datenrückgabe aus der View (s. o.) erwartet wird. Ein Klick auf das X-Symbol würde anderenfalls die modale View schließen, ohne dass das Verhalten mit der Aktion Schließen anfordern ausgeführt wird, das der einzige Weg zur Bereitstellung eines Rückgabeobjekts ist.
  
  

  • Die Option Zeige "Zurück Button" ist nur relevant und sichtbar, solange die Option Schließbar ausgewählt ist (Standard). Sie kann dann abweichend vom Standard ausgewählt werden, damit in der geöffneten View ein Ribbon Button Zurück (per Standard ganz links in der Hauptkategorie Allgemein) erscheint. Ein Klick auf Zurück bewirkt das Schließen der modal geöffneten View, genau wie ein Klick auf das X-Symbol rechts oben im Titel der View. In beiden Fällen endet die ggf. definierte Wartezeit Wertrückgabe ohne Rückgabewert.

►HINWEIS◄ Der Zurück Button kann als Ribbon-Makro beeinflusst werden, indem die Unterkategorie modal (nicht im Dropdown enthalten!) mit dem Makro-Namen back kombiniert wird. Per Makrobefehl ("Immer deaktiviert" bzw. "Immer ausgeblendet") kann dann auch das Schließen einer modalen View auch per Zurück gezielt verhindert werden.

Die Option Nach dem Commit öffnen ist per Standard abgewählt, sodass die Zu öffnende View beim Ausführen von Öffne View (Aktion) unverzüglich ausgeführt wird.

• Wird Nach dem Commit öffnen abgewählt, dann wird die Zu öffnende View nur zum Öffnen beim erfolgreichen Abschluss der aktuellen Transaktion bzw. Ereignisverarbeitung vorgemerkt. Die View erscheint dann nur, wenn bis dahin weder ein Fehler mit Rollback auftritt noch eine Abbrechen-Ereignisaktion ausgeführt wird.
  
  

• Eine "Datenrückgabe aus der View" (s. o.) wird nicht unterstützt, wenn die Option Nach dem Commit öffnen ausgewählt ist. Daher sind die zugehörigen Parameter (s. o.) nur sichtbar und relevant, solange die Option Nach dem Commit öffnen abgewählt ist.

►ANMERKUNG◄ Um "nach dem Commit" eine View mit Datenrückgabe zu öffnen, sollte eine Eigenes Aktionsevent auslösen (Aktion) mit der entsprechenden Option ausgeführt werden. In der Ereignisbehandlung für das ausgelöste Ereignis kann dann Öffne View (Aktion) ohne die Option Nach dem Commit öffnen aber dafür mit "Datenrückgabe" ausgeführt werden.

Im Beispiel wird der URL zum Aufrufen des Clients der Parameter myOrder mit dem Wert 4351 angehängt:

Noch bevor die eigentliche Sitzung beginnt, erscheint eine Erfassungsmaske mit Details zu der Bestellung mit der ID 4351 in einer kompakten, modal geöffneten Erfassungsmaske. Diese URL könnte z. B. durch das Scannen eines Barcodes aufgerufen werden.

►ANMERKUNG◄ Das Feld "ID" wurde im Beispiel zur Verdeutlichung sichtbar im Formularlayout eingebunden, was in der Praxis weder üblich noch erforderlich ist.

• Nach dem Auswählen einer Position über den Button "Auswahl" in der Erfassungsmaske (rechts oben) wird diese geschlossen. Stattdessen erscheint eine Bestellübersicht (rechts), die nur Bestellungen auflistet, die über mindestens eine Position mit derselben "Warenbeschreibung" verfügen wie die ausgewählte Position.

►ANMERKUNG◄ Das Auswahlkriterium (übereinstimmende "Warenbeschreibung") für die anzuzeigenden Bestellungen wurde im Beispiel zur Vereinfachung bewusst oberflächlich gewählt. In einer praktischen Anwendung wären komplexere Kriterien (z. B. eine Kombination von Zeitraum der Erstellung, Arbeitsstatus, Artikelnummer, EAN usw.) typisch.

Der Screenshot rechts zeigt die zu erstellende Ereignisbehandlung zunächst im Überblick. Anschließend werden Konfigurationsdetails abschnittweise beschrieben.

• Unter Auslösende Ereignisse wird das Ereignis Client angemeldet ausgewählt (s. Anmeldung (Ereignisse)), in dessen Kontext alle verwendeten URL-Parameter als String-Variablen verfügbar sind.

• Als Prüfende Regel dient eine Objekt-Feld-Regel, die untersucht, ob die Variable myOrder "nicht leer" ist. Das ist der Fall, wenn für den URL-Parameter myOrder ein Wert angegeben wurde.

►ANMERKUNG◄ Hier wird weder explizit geprüft, ob der übergebene String als Long-Wert interpretierbar ist, noch ob innerhalb der angemeldeten Sitzung Lesezugriff auf eine Bestellung mit einer passenden ID besteht. Entsprechende Prüfungen könnten innerhalb der Regel oder in einer Wenn Dann Sonst-Ereignisaktion ergänzt werden, wenn verhindert werden soll, dass eine leere Erfassungsmaske für Bestellungen erscheint.

• Im Bereich Aktionen bei bestandener Regel wird zunächst eine Öffne View (Aktion)-Ereignisaktion ausgeführt, die die Erfassungsmaske (detailsWindow) mit den Details der per URL-Parameter identifizierten Bestellung öffnet (Details s. unten).
  
  

• Die folgende Ausführen mit-Ereignisaktion wird erst ausgeführt, wenn die geöffnete Erfassungsmaske geschlossen wird. Erfolgt dies per Klick auf den Button "Auswahl" für eine konkrete Position, dann wird die betreffende Entität vom Typ "Bestellposition" in einer Variablen selectedLineItem gespeichert. Diese wird im Objekt Resolver der Ausführen mit-Ereignisaktion als Bezugsobjekt für den Aktionsblock definiert.
  
  

• Der Aktionsblock beinhaltet hier eine zweite Instanz von Öffne View (Aktion), die eine Bestellübersicht (listSearchWindow) mit den zur ausgewählten Position "passenden" Bestellungen öffnet.

►ANMERKUNG◄ Auf eine Kontrolle, ob in der Erfassungsmaske überhaupt eine Position ausgewählt wurde wird hier verzichtet. In der Praxis wäre eine Wenn Dann Sonst-Ereignisaktion zu empfehlen, die die Ausführen mit-Ereignisaktion nur ausführt, wenn die Variable selectedLineItem "nicht leer" ist.

Zum Öffnen der Erfassungsmaske mit den Details der per URL-Parameter bestimmten Bestellung wird die erste Öffne View (Aktion)-Ereignisaktion wie rechts abgebildet parametriert:

• Als Zu öffnende View wird der zugehörige Viewname (de.lobster.scm.order.bto.Order|detailsWindow) eingetragen.
  
  

• Im Parameter Formulardaten wird ein Variable-Wertauflöser verwendet, um den Wert des URL-Parameters myOrder zu übergeben. Sofern der enthaltene Textwert als Long-Wert (Ganzzahl) interpretiert werden kann, versucht die geöffnete Erfassungsmaske, die Details der Bestellung mit der angegebenen ID anzuzeigen.
  
  

• Als Variablenname des Rückgabeobjekts wird hier willkürlich der Name selectedLineItem zugeiwesen, auf den sich die nachfolgende Ausführen mit-Ereignisaktion bezieht. Diese Variable enthält nur dann Daten, wenn diese in der Erfassungsmaske durch eine Schließen anfordern-Aktion in einem Verhalten zugewiesen werden. Das erledigt im Beispiel der Button "Auswahl", der die Daten des Spaltenlayouts für eine einzelne Position zuweist.
  
  

• Die Wartezeit Wertrückgabe muss >0 (Sekunden) gesetzt werden, da sonst kein Rückgabewert abgewartet wird. Trifft der Benutzer innerhalb der hier parametrierten 900 Sekunden keine Entscheidung, wird die Erfassungsmaske automatisch, ohne Rückfrage bzgl. "Änderungen verwerfen" und ohne einen Rückgabewert in die Variable selectedLineItem zu schreiben geschlossen.
  
  

• Die weiteren Optionen können z. B. wie abgebildet gesetzt werden. Die Optionen Modal und Vollbild bewirkt in der Kombination mit dem auslösenden Ereignis "Client angemeldet", dass ausnahmsweise das gesamte Browserfenster für die Anzeige genutzt wird, da direkt nach der Anmeldung weder das Hauptmenü noch die View Slots angezeigt werden.

Die nachfolgende Ausführen mit-Ereignisaktion wird wie rechts abgebildet konfiguriert, um ausgehend von der als Rückgabewert in der Variablen selectedLineItem übergebenen Bestellposition ("Bestellung > Position") das Suchkriterium für die zu öffnende Bestellübersicht maßzuschneidern.

• Der Objekt Resolver greift über einen Variable-Wertauflöser auf die Variable selectedLineItem zu (im Bild zugeklappt).
  
  

• Im Aktionsblock wird direkt die zweite Öffne View (Aktion)-Instanz ausgeführt, die als Zu öffnende View den Standard-Kontext für die Bestellübersicht (de.lobster.scm.order.bto.Order|listSearchWindow) adressiert.
  
  

• Als Formulardaten wird durch eine Verkettung von Wertauflösern ein Search-Objekt (s. Suche) erzeugt, das die Bedingung für die aufzulistenden Bestellungen beinhaltet:
  
  

  • Zunächst wird in einem Text-Wertauflöser (s. Statische Werte) ein statisches XML hinterlegt, die als Platzhalter für den als Kriterium vorgesehenen Wert der "Warenbeschreibung" die Zeichenfolge @1:s@ enthält.
    
    

  • Der Platzhalter (@1:s@) wird zur Laufzeit per Text ersetzen durch den Textwert (textValue) des Textattributs "Warenbeschreibung" (GOODS_DESCRIPTION) der ausgewählten Bestellposition ersetzt.
    
    

  • Aus dem zur Laufzeit modifizierten XML-String wird anschließend durch einen Objekt aus Server XML erzeugen-Wertauflöser ein Search-Objekt erzeugt, das als Wert für den Parameter Formulardaten eine "Einschränkung" für die zu öffnende Bestellübersicht bewirkt.

►HINWEIS◄ Der statische XML-String für das search-Objekt wurde für dieses Beispiel in den folgenden Schritten mit dem Abfragekonfigurator erstellt:

1. Eine Abfrage vom Typ "Suche" für den betreffenden Entitätstyp (hier: Bestellung) konfigurieren und testen.
   
   

2. Den Reiter "XML" auswählen, in dem das XML-Abbild der konfigurierten Abfrage angesehen und bearbeitet werden kann.
   
   

3. Alle Namespace-Attribute (xmlns) aus dem core:SearchTask-Element in das core:Search-Element kopieren.
   
   

4. Das aufbereitete core:Search-Element (siehe Markierung im Screenshot unten) komplett in die Zwischenablage übernehmen und innerhalb der Ereignisbehandlung in den Wertauflöser für statischen Text einfügen.
   
   ►ANMERKUNG◄ Die Markierung ab Zeile 3 beinhaltet im Bild bereits die kopierten xmlns-Attribute (Namespaces) aus Zeile 2. Man könnte daher auch einfach die Zeilen 2 und 24 löschen, um die XML-Definition für das gewünschte Search-Objekt zu erhalten.

►HINWEIS◄ Alternativ kann ein Search-Objekt bzw. der zugehörige XML-String auch zur Laufzeit aus einer bestehenden Konfiguration (z. B. Externe Suche oder Eigene Übersichten) gelesen und danach angepasst, über ein Lobster_data-Profil (per Lobster_pro Vorlagen) generiert oder sogar per Erzeuge Instanz innerhalb der Ereignisbehandlung erzeugt und dann "passend" und Schritt für Schritt aufgebaut werden.