Ein serverseitiger Redirect wird durch die XPages-Engine standardmäßig so durchgeführt, daß an den Client ein spezieller HTTP-Header gesendet wird, der via Javascript ausgewertet und dann durch CSJS geöffnet wird.
Der Hintergrund hierbei ist, daß sich dadurch die URL in der Browser-Addressleiste ändert, und so dem Nutzer die Seitenänderung aktiv angezeigt wird. Das Problem hierbei ist jedoch, daß dadurch ein zusätzlicher Request vom Server an den Client gesendet wird, der zum Einen natürlich die Last auf dem Server erhöht, zum Anderen den Vorgang unnötig verlangsamt.
Ein Clientseitiger Link…
<xp:link escape="true" text="LinkClient" id="link1"
value="/Page2.xsp" />
… ist daher besser als das gleiche Konstrukt über einen Serverseitigen Event-Handler …
<xp:link escape="true" text="LinkServer" id="link2" >
<xp:eventHandler event="onclick" submit="true"
refreshMode="complete">
<xp:this.action>
<xp:openPage name="/Page2.xsp"></xp:openPage>
</xp:this.action>
</xp:eventHandler>
</xp:link>
… auch wenn das Ergebnis im ersten Moment daraus das gleiche Ergebnis resultiert.
Das erste Beispiel öffnet den Link direkt über den Client:
[Beispiel 1 Firebugged: Direktes Öffnen von Page1.xsp via HTTP GET]
Das zweite Beispiel sort dafür, daß beim Klicken auf den Link zuerst ein HTTP POST-Request an den Server an die aktuelle Seite geschickt wird; die Antwort (versehen mit dem HTTP-StatusCode 302) löst dann einen zweiten Request mittels HTTP GET auslöst, durch den dann die “Page2.xsp” geöffnet wird.
[Beispiel 2 Firebugged: POST-Request an Page1.xsp, dann GET-Request an Page2.xsp]
Daher sollte prinzipiell darauf geachten werden, daß z.B. Links in der XPage direkt eingebettet werden, und das Serverseitige Verarbeiten mittels OpenPage besser zu unterlassen.
Doch auch dieses Verhalten läßt sich noch durch eine Einstellung im xsp.properties-File modifizieren: Durch die Einstellung xsp.redirect = false wird kein Redirect mehr für das Event-basierte Link-Beispiel ausgeführt, sondern die neue Seite wird direkt an den Client übergeben:
[Firebugged: Ergebnis mit xsp.redirect=false]
Im Browser sieht das ganze dann wie folgt aus (in den Screenshots wird ein Button verwendet), man beachte die URL im Browser:
[Page1.xsp vor dem Klick auf den Button]
[Page1.xsp nach dem Klick, jetzt mit dem Inhalt von Page2.xsp]
Sieht man von dem “unschönen” Effekt ab, daß die URL im Browser sich nicht verändert hat, hat sich die Performance auch für den Client deutlich erhöht. Als Beispiel hier noch die Zeiten, die für den Seitenaufbau benötigt werden; da der DOM-Baum nur einmal im Browser geändert wird, ist auch dies deutlich schneller.
[Zeit für Seitenaufbau mit xsp.redirect = true]
[Zeit für Seitenaufbau mit xsp.redirect = false]
Wie sich unschwer erkennen läßt, ist mit xsp.redirect=false der Seitenaufbau in etwa der Hälfte der Zeit erledigt wie im anderen Fall. Das hierbei die ULR im Browser nicht aktualisiert wird, kann im Einzelfall natürlich zu den hier geschilderten Problemen führen, aber hier muß klar der Performance-Vorteil in den Vordergrund gestellt werden.
Weiterführende allgemeine Informationen finden sich hier: Google.com: Minimize round-trip times.
Henning Schmidt hat einen Beitrag zum