Multiple Partial Refreshs sind eine schöne Sache, um mehrere Elemente einer XPage zu aktualisieren. Doch da die AJAX-Requests generell asynchron verarbeitet werden, stellt sich die Frage, in wieweit es erforderlich ist, sie sequentiell seriell wie in dem verlinkten Beispiel abzuarbeiten: Denn je länger die Kette der Partial Refreshs ist, desto mehr Performance gewinnt man, wenn man stattdessen mit parallelen Aufrufen arbeitet.
Das verlinkte Beispiel sieht in der parallelen Variante wie folgt aus:
XSP.partialRefreshGet(id1); XSP.allowSubmit(); XSP.partialRefreshGet(id2); XSP.allowSubmit(); XSP.partialRefreshGet(id3);
Das Ergebnis unterscheidet sich nicht von von der seriellen Variante, ausser der Tatsache, das die Performance im Client deutlich höher ist. Zwischen den einzelnen Partial Refreshs muss nur die Funktion XSP.allowSubmit() aufgerufen werden, um die interne „Refresh-Sperre“ zurück zu setzen (Eine kurze Erläuterung hierzu findet sich in Matthias Blog).
Die Events der Parial Refreshs (OnComplete, OnError, OnStart) können natürlich wie sonst auch verwendet werden.
Wichtig ist nur, dass man eine „Feinabstimmung“ vornimmt, denn es läßt sich aufgrund der Asynchronität nicht voraussagen, in welcher Reihenfolge die Partial Refreshs verarbeitet werden: Sind z.B. die Elemente im DOM-Baum voneinander abhängig und ein Element wird durch ein Partial Refresh ausgeblendet, kann das natürlich zu ungewollten Fehlern führen – und ein serielles Aufrufen erforderlich machen. Doch wo es möglich ist, sollte aus Performancegründen der Einsatz von parallel ausgeführten Partial Refreshs erfolgen.
To get this to work in 8.5.3 you need to do this
XSP.partialRefreshGet (id1,{});
XSP.allowSubmit ();
XSP.partialRefreshGet (id2,{});
XSP.allowSubmit ();
XSP.partialRefreshGet (id3,{});
Thanks Fredrik! Seems to be a change in the XSP-Object for 8.5.3.