Rolf B: Kontrollfragen zum Verständnis und Angebot fürs Wiki

Beitrag lesen

Hallo Linuchs,

postMessage ist Kommunikation innerhalb eines einzelnen Browsers auf einer einzelnen Maschine.

Entfernen wir mal einen der Lüge für Kinder Schleier über der Sache.

postMessage kann man anwenden auf: Window, Worker und MessagePort Objekte. Was ist ein MessagePort? Wenn Du ein Fenster oder einen iframe erzeugst, wird automatisch ein MessageChannel von Dir zum neuen Fenster/iframe erzeugt. Dieser Channel besteht aus zwei gekoppelten Ports. Was Du in den einen Port hineinpostest, kommt am anderen als message-Event hinaus.

window.postMessage und worker.postMessage verwenden die Ports des Default-MessageChannel. Du kannst mit new MessageChannel aber auch einen eigenen erzeugen und einen der beiden Ports mit dem transfer-Parameter von postMessage an ein anderes Window oder einen Worker übertragen.

Das ist von Vorteil, wenn man diese Channels intensiv nutzt. Ohne private Channels müsste jegliche Kommunikation über den Default-Channel laufen und vom message-Eventhandler verteilt werden. Bei einer Mashup-Seite, die aus vielen Komponenten besteht, ist das sehr komplex. Wenn die Komponente A im Window 1 nur mit der Komponente B im Window 2 reden soll, dann ist es praktischer, wenn die beiden einen privaten Message-Channel bekommen. Auf Window-Ebene brauchst Du dann nur noch einen Mechanismus zum Anfordern und Verteilen von privaten Channels.

postMessage kann nur an ein einziges window-object senden. Richtig?

Grundsätzlich richtig. Genauer formuliert: in einen einzigen MessageChannel hineinpusten - äh - posten. Und dessen anderer Port kann nur einem einzigen globalen Kontext (=Window oder Worker) gehören.

In einer for-Schleife können nacheinander mehrere window-objects besendet werden.

Logisch

iframes können keine anderen iframes besenden, sondern nur das parent-object.

Das hast Du richtig gemeint, aber es ist unvollständig und ich möchte es genauer formulieren. Wenn man den Default-MessageChannel verwendet, kann man ohne weiteres nur an sein direktes Elternelement oder an die direkten Kindelemente senden.

Bei gleichem Origin kann ein iframe auf sein parent-Window zugreifen, und ich würde annehmen (man muss es ausprobieren), dass er dann auch an die frames Eigenschaft herankommt und an andere Child-Windows etwas posten kann.

Bei verschiedenem Origin geht das nicht, aber - auch das ist unprobiert - das Haupt-Window kann natürlich mithelfen und über postMessage eine Funktion bereitstellen, die einen MessageChannel erzeugt, davon einen Port an den Besteller zurückschickt und den anderen Port an einen anderen iframe. Daraufhin hätten die beiden iframes einen MessageChannel, über den sie sich direkt unterhalten können.

Das Konzept wäre also, dass dieses iframe the parent informiert und parent weist alle anderen iframes an, die Klappe zu halten. Richtig?

Sehe ich auch so. Wenn Du einen parent hast, der einen Chor aus iframes orchestriert, dann ist es besser, wenn das Parent das Routing übernimmt und nicht ein iframe wissen muss, wer da alles auf der Seite mitschwimmt.

Das im Wiki mit Beispiel einzubauen könnte schwierig werden. Zumindest dürfte sich das schlecht Frickln lassen...

Rolf

--
sumpsi - posui - obstruxi