Der Fluch des Partial Refreshs

Publiziert am 30. Oktober 2011 von Sven Hasselbach

Bei der Architektur von Web 2.0-Applikationen gibt es ein paar Besonderheiten zu beachten, die es im „alten“ Web nicht gegeben hat, denn der konzeptionelle Ansatz, durch die AJAX-gestützten Abfragen nur einzelne Segmente einer Webseite zu laden (und diese Abfragen im Hintergrund durchzuführen), kann sich zu einem grundlegenden Problem entwickeln: Zum Einen leidet die Benutzbarkeit einer Applikation, denn das Verlinken der Inhalte ist nicht möglich, zum Anderen können Suchmaschinen die Seiten nicht oder nur noch teilweise indizieren.

Zum Erläuterung des Problems hier eine kleine Denksportaufgabe: Wie verlinke ich eine bestimmte Seite, z.B. die zweite Seite des XPages-Developer-Forums? Das Verlinken eines Beitrages stellt kein Problem dar, aber die zweite Seite zu verlinken ist nicht möglich.

Im „guten alten Web“, bei dem die Webseiten immer komplett geladen und die Optionen zum Großteil über URL-Parameter gesteuert werden, existiert als Nebeneffekt automatisch eine Möglichkeit, ein Bookmark zu setzen, wie z.B. hier: Domino 8.5 Forum, Seite 2, Kategorisierung eingeklappt.

Auch ist es für die Bots der Suchmaschinen viel einfacher, allen Verlinkungen innerhalb einer Webseite zu folgen, denn hinter dem Link verbirgt sich eine (neue) Seite, die es ebenfalls zu indizieren gilt.

Im Falle von XPages-Applikationen gibt es diese Möglichkeiten nicht Out-Of-The-Box. Man kann hier getrost vom „Fluch des Partial Refreshes“ sprechen kann, denn so muß die Google-Spezifikation für durchsuchbare AJAX-Applikationen in die XPages händisch eingebaut werden. Und das für jeden Pager, jede Aktion, jeden Serverseitigen Link…

Um die Funktionalität der Bookmarks wieder herzustellen, kann der URL Hash „angezapft“ werden; dieser muß jedoch via Javascript gesetzt bzw. ausgewertet werden. Eine Hilfe hierfür bietet der Dojo Toolkit mittels dojo.hash. Die Variante der URL Manipulation OHNE ein Neuladen der Webseite ist auch mit älteren Browsern möglich; mit HTML 5 ist die Möglichkeit geschaffen worden, die URL wirklich manipulieren zu können. Eine nette Implementierung findet sich auch unter https://github.com/balupton/history.js. Die HTML 5 – Variant e ist Serverseitig auswertbar, da sich die URL-Parameter ohne Reload der Seite setzen lassen (und im HTTP Request übertragen werden). Aber leider ist diese Funktionalität nicht in älteren Browser verfügbar.

Will man kompatibel bleiben, bleibt also nur der Weg über den URL-Hash. Im Falle eines Seitenaufrufs über ein Bookmark muß der Hash-Part der URL im Client ausgewertet werden, denn der Hash wird NICHT via HTTP Request übertragen (und damit auch nicht Serverseitig auswertbar). Erst nach dieser Auswertung können diese Informationen z.B. mit einen Partial Refresh übertragen werden.

Eine Beispiel-Implementation ist in Arbeit und wird bei Gelegenheit veröffentlicht.

Veröffentlicht unter Dojo Toolkit, HTML, Java Script, JSF, Server, ServerSide JavaScript, Web, XPages | Verschlagwortet mit , , , , , , , , | 2 Kommentare

disableXspCache: Programmatisch GZip-Komprimierung abschalten

Publiziert am 20. Oktober 2011 von Sven Hasselbach

Mit einem kleinen Trick kann die GZip-Komprimierung einer XPage programmatisch abgeschaltet werden: Schaltet man im beforeRenderResponse-Event einer XPage den XspCache des Servlets aus, kann man hierbei ebenfalls die GZip-Komprimierung deaktivieren. Hierfür bietet die XspHttpServletResponse die Methode disableXspCache; wird diese mit dem Parameter false aufgerufen, wird die GZip-Komprimierung abgeschaltet.

Hier ein kleines Beispiel:

<xp:this.beforeRenderResponse>
    <![CDATA[#{javascript:
        var response:com.ibm.xsp.webapp.XspHttpServletResponse;
        response = facesContext.getExternalContext().getResponse();
        response.disableXspCache(false);
    }]]>
</xp:this.beforeRenderResponse>

Mit der Methode isDisableXspCache() kann abgefragt werden, ob der XspCache deaktiviert ist, oder nicht.

Veröffentlicht unter Java, Performance, Server, Web, XPages | Verschlagwortet mit , , , , , , | Schreib einen Kommentar

Bug: java.io.File & die Methode „delete()“

Publiziert am 29. September 2011 von Sven Hasselbach

Die Methode „delete()“ für ein java.io.File-Objekt ist im Domino Designer leider nicht verwendbar, denn hier gibt es einen groben Bug (unter 8.5.2FP2 und 8.5.1).

Man erhält eine Syntax-Fehler, der nicht behebbar ist; das Highlighting versagt hier völlig (die Methode wird rot hervorgehoben, wie sonst nur spezielle Schlüsselwörter).

Alternativ läßt sich nur die „deleteOnExit()„-Methode verwenden, oder die Datei muß per Agent gelöscht werden.

<xp:this.beforeRenderResponse>
<![CDATA[#{javascript:
   var file:java.io.File = new java.ioFile();
   file.deleteOnExit()}]]>
</xp:this.beforeRenderResponse>
Veröffentlicht unter Java Script, ServerSide JavaScript, XPages | Verschlagwortet mit , , , , , | 2 Kommentare

HTTP Daten debuggen

Publiziert am 2. September 2011 von Sven Hasselbach

Manchmal ist sehr nützlich, sich die HTTP Daten so anzuschauen, wie sie auf dem Dominoserver auch ankommen. Dafür ist dieser kleine Agent gedacht, den man in einer beliebeigen Datenbank ablegen kann und dann mittels

http://server/pfad/zur/db.nsf/HTTPDebug?OpenAgent

aufrufen kann.

Hier der Code:

REM
        Agent HTTPDebug
        Created Sep 2, 2011 by Sven Hasselbach
%END REM
Option Public
Option Declare

Sub Initialize
        Dim session As New NotesSession
        Dim doc As NotesDocument
        Dim item As NotesItem

        Set doc = session.Documentcontext

        Print |<html><head><title>HTTPDebug</title></head>|
        Print |<body><table border="1" width="100%">|
        ForAll it In doc.Items

                Set item = it
                Print |<tr><td><b>| & item.Name & |</b></td>|
                Print |<td>| & item.Text & |</td></tr>|

        End ForAll

        Print |</table></body></html>|
End Sub
Veröffentlicht unter Agenten, Errorhandling, HTML, Lotus Script, Server, Web | Verschlagwortet mit , , , , , , , | Schreib einen Kommentar