WebclientWire

Die Klasse WebclientWire ist der postMessage-Transport zwischen einem Dashlet-iFrame und dem Webclient-Host. Sie ist der interne Mechanismus, den die Fassaden-Methoden wiederverwenden; sie wird exportiert, damit Verbraucher und Tests sie direkt steuern können.

1. Konstruktor

new WebclientWire(options: WebclientWireOptions): WebclientWire;
Option Bedeutung

window

Das Fenster, auf dem der Wire lauscht (strukturelles WindowLike).

expectedOrigin

Konfigurierte Origin (nie "*"). Ein verwertbarer Wert setzt den Wire in den STRENGEN Modus — beim Konstruktor verankert. Fehlend/leer setzt ihn in den LERNENDEN Modus: Der Wire startet unverankert, die erste akzeptierte Nachricht — die ein onInit sein muss — verankert die empfangene Origin-Zeichenkette wie empfangen, und die Verankerung ist danach unveränderlich. Ein konfigurierter Wert muss ein Mitglied der File-Origin-Gruppe oder eine gültige absolute URL sein; alles andere wird beim Konstruktor mit einer TypeError abgelehnt (siehe Origin-Konfiguration).

timeoutMs

Antwort-Timeout in ms für call().

onEvent

Empfängt origin-validierte Host-Events: HostEvent = { type: 'onInit' | 'onUpdate', data }.

listen

Bei true (Vorgabe) hängt start() den eigenen message-Listener des Wires an. Auf false setzen, wenn ein gemeinsamer Host-Listener Events an dispatch routet.

2. Methoden

start(): void;                 // Listener anhängen (wenn listen true ist)
dispatch(event: MessageEventLike): void;  // ein Event im gemeinsamen-Listener-Modus routen
destroy(): void;               // trennen
get pendingCount(): number;    // korrelierte Aufrufe, die auf eine Antwort warten
call<T = unknown>(method: string, params: unknown = [], msgId?: string): Promise<T>;

call postet [method, params, { msgId }] auf den Wire und korreliert die Antwort über msgId. Die Kennung ist nicht erratbar: crypto.getRandomValues liefert dmsg- + 32 Hex-Zeichen, mit dem sequenziellen dashlet-msg-N als Fallback, wenn die API fehlt. Läuft die Grenze ohne Antwort ab, lehnt der wartende Aufruf mit einer TimeoutError ab (eine verspätete Antwort wird ignoriert); eine { error }-Nutzlast des Hosts lehnt mit dem Host-Fehler ab (siehe Fehlermodell).

3. Origin-Prüfung und ausgehende Posts

Eingehend: Jede Nachricht wird gegen die konfigurierte Origin (im strengen Modus) bzw. die erlernte Verankerung (im lernenden Modus, nach dem ersten onInit) geprüft; nicht passende Nachrichten werden verworfen. Der Origin-Vergleich ist originMatches — die File-Origin-Gruppe (einschließlich der Desktop-App-Serialisierung "null") stimmt bidirektional überein.

Ausgehend: Posts zielen auf die zuletzt akzeptierte Origin, mit einer Ausnahme — ein Host, dessen Origin ein Mitglied der File-Origin-Gruppe ist, wird als "*" adressiert, das einzige Ziel-Token, das die Zustellung garantiert. Ohne jegliche vertrauenswürdige Origin posten Aufrufe nie (und werden stattdessen über den begrenzten Timeout abgelehnt).