Umgebungen und Erkennung

Derselbe Dashlet-Code läuft in allen drei Umgebungen. Diese Seite erklärt, wie die Bibliothek entscheidet, in welcher Umgebung sie läuft, und warum Host-Events nicht verpasst werden können — selbst wenn sie vor der Konfiguration eintreffen.

1. Die drei Umgebungen

Umgebung Wo Wire

Umgebung	Wo	Wire
`webclient`	Dashlet in einem sandboxed iframe im enaio Webclient	`window.postMessage`: `onInit`- und `onUpdate`-Events treffen als JSON ein; Methodenaufrufe werden als `[method, params, { msgId }]` gesendet und über die `msgId` in der Host-Antwort `{ type: "response", … }` korreliert
`richClient`	Dashlet in der eingebetteten WebView2 des Windows Rich Clients	injiziertes `window.osClient` (synchroner `osjx*`-Bridge) plus der vom Host aufgerufene Globale `osDashletInit(data)`; es gibt kein initiales Event, daher initialisiert sich die Bibliothek selbst aus der Bridge
`standalone`	Einfacher Tab, Dev-Server oder jede Nicht-enaio-Einbettung	Kein Bridge, keine Events; der begrenzte Degradationszustand (Fallback, nie ein Hang)

webclient

Dashlet in einem sandboxed iframe im enaio Webclient

window.postMessage: onInit- und onUpdate-Events treffen als JSON ein; Methodenaufrufe werden als [method, params, { msgId }] gesendet und über die msgId in der Host-Antwort { type: "response", … } korreliert

richClient

Dashlet in der eingebetteten WebView2 des Windows Rich Clients

injiziertes window.osClient (synchroner osjx*-Bridge) plus der vom Host aufgerufene Globale osDashletInit(data); es gibt kein initiales Event, daher initialisiert sich die Bibliothek selbst aus der Bridge

standalone

Einfacher Tab, Dev-Server oder jede Nicht-enaio-Einbettung

Kein Bridge, keine Events; der begrenzte Degradationszustand (Fallback, nie ein Hang)

In jeder Umgebung löst sich das init-Promise in denselben normalisierten InitContext auf — die Umgebung ändert nur, welcher Wire aktiv ist.

2. Wie die Bibliothek entscheidet: die Erkennungs-Zustandsmaschine

start -> detecting
           |  bridge found (immediate probe or poll tick)
           +-----> rich client self-init (bridge read) -> initialized
           |  webclient onInit accepted (origin OK, first event)
           +-----> webclient init -> initialized
           |  detection cap elapsed (no bridge, no event)
           +-----> standalone (observable degradation, not an error)

Auflösungsregeln:

Die Zustandsmaschine löst sich genau einmal auf; init löst sich genau einmal auf und wird niemals abgelehnt — der Standalone-Zweig ist ein beobachtbarer Fallback, kein Fehler.
Rich Client: Die Bridge kann verzögert injiziert werden, daher pollt die Erkennung window.osClient (pollIntervalMs, Standard 50 ms), bis er erscheint oder die Erkennungs-Obergrenze (detectionTimeoutMs, Standard 5000 ms) abläuft. Bridge-Fähigkeits-Proben sind throw-safe: je nach Client-Version wirft das Lesen eines unbekannten Members eine Ausnahme oder liefert undefined — beides bedeutet "nicht vorhanden". Die Bridge selbst kann aufrufbar sein: Der WebView2-Rich-Client (gemessen auf 12.0.713) injiziert einen Host-Objekt-Proxy um eine Funktion, daher ist typeof window.osClient gleich 'function'; die Proben akzeptieren eine Objekt-Bridge und eine aufrufbare Bridge gleichermaßen. Gelingt der Bridge-Lesevorgang, läuft die Rich-Client-Initialisierung mit null Host-Aufrufen ab.
Webclient: Das erste onInit, das die Origin-Validierung akzeptiert, löst den Zustand auf (siehe Origin-Konfiguration). Nach dem ersten Webclient-Event ist der vom Host deklarierte Client-Typ maßgeblich — ein Client-Typ rich_client leitet die Auflösung auf den Rich-Client-Pfad um.
Standalone: kein Bridge und kein akzeptiertes Event innerhalb der Obergrenze — der Fallback-Zustand, dokumentiert in Standalone-Betrieb.

3. Selbst-Registrierung zum Import-Zeitpunkt: kein Host-Event wird verpasst

Die Registrierung der Host-Schnittstelle hängt nicht an Ihrem Framework oder daran, dass Sie installDashletGlobal "früh genug" aufrufen. Das Importieren des Pakets erledigt bereits Folgendes synchron zum Modul-Auswertungszeitpunkt:

installiert window.osDashletInit sofort — der Rich Client feuert seinen ersten Aufruf, ohne auf load zu warten;
hängt den einzigen puffernden message-Listener an — der einzige message-Listener, den ein Dashlet-Window je braucht.

Host-Aufrufe und postMessage-Events, die vor der Ausführung von installDashletGlobal eintreffen, werden gepuffert — begrenzt, in Ankunftsreihenfolge — und bei der Konfiguration des Dashlets entleert; sie werden niemals verworfen. Die Registrierung ist idempotent: der installierte Globale ist ein stabiler Dispatcher pro Fenster, und die Neu-Registrierung fügt oder entfernt Handler atomar, ohne einen zwischenzeitlichen Aufruf zu verlieren.

Zusätzlich wird ein onInit-Listener, der nach dem bereits aufgelösten Init registriert wird (zum Beispiel von einem Framework nach dem Mount), sofort mit dem aufgelösten Kontext nachgeliefert — eine späte Registrierung verpasst das Init niemals.

4. Das v10.10-Warm-up-Verhalten

Bei der Client-Version 10.10 liefert osjxGetEnvironment(n) leere Werte, bis der Client sein Warm-up abgeschlossen hat. Liefert der Selbst-Init-Bridge-Lesevorgang gar keine Umgebungs-Werte, führt die Bibliothek ein begrenztes Warm-up (das Poll-Intervall, begrenzt durch detectionTimeoutMs plus eine interne 10-s-Obergrenze) aus und gibt den befüllten Kontext über den Update-Slot erneut aus, sobald die Werte erscheinen — nie ein Hang, und nie ein stilles Überschreiben bereits gelesener Werte.