Posts Tagged: ‘HTTP’

Quick-n-Dirty: Hijacking TypeAhead in CSJS

9. Dezember 2011 Posted by Sven Hasselbach

Matthias Nicklisch hat eine interessante Frage im XPages Forum gestellt, nachdem er festgestellt hat, dass im Designer zwar ein OnStart- / OnComplete-Event für die TypeAhead-Funktion angeboten wird, der Code aber als Deprecated angezeigt wird – und auf der XPage auch nicht funktioniert: Wie kann ein OnStart- / OnComplete-Event trotzdem verwendet werden?

Meine Idee dazu ist, den darunter liegenden dojo.xhr-Request zu hijacken, und auf diese Weise die Events zu erhalten. Dadurch lässt sich der Code bequem auf die jeweilige XPage einbetten, ohne das eine Manipulation der original Javascript-Dateien erfolgen muss.

Der folgender Code muß in einem CSJS-Scriptblock eingebettet werden. Dann erhält man für die TypeAhead-Funktion die Events, um zum Beispiel ein kleines “Loading”-Icon einzublenden, wenn die Daten vom Domino Server geladen werden.

var typeAheadLoad;

dojo.addOnLoad( function(){
   /*** hijacking xhr request ***/
   if( !dojo._xhr )
      dojo._xhr = dojo.xhr;

   dojo.xhr = function(){
      try{
         var args = arguments[1];
         if( args['content'] ){
            var content = args['content'];
               if( content['$$ajaxmode'] ){
                  if( content['$$ajaxmode'] == "typeahead" ){
                
                     /*** hook in load function ***/
                     typeAheadLoad = args["load"];

                     /*** overwrite error function ***/
                     args["error"] = function(){
                        alert('Error raised!')
                     };
                    
                     /*** hijack load function ***/
                     args["load"] = function(arguments){
                 
                        /*** On Start ***/
                        alert("On Start!");
                    
                        /*** call original function ***/
                        typeAheadLoad(arguments);
                    
                        /*** On Complete ***/
                        alert("On Complete!")
                     };
                 }
             }
         }
      }catch(e){}
      dojo._xhr( arguments[0], arguments[1], arguments[2] );
   }
});

Der neue HTTP Header ‘X-XspRefreshId’

5. Dezember 2011 Posted by Sven Hasselbach

Mit Domino 8.5.3 ist der neue HTTP Header ‘X-XspRefreshId’ eingeführt worden, mit dem sich die refreshId eines Partial Refreshs vom Server aus verändern lässt. Dadurch ist es möglich, ein Element zu refreshen, dass Ergebnis dieser Operation jedoch auf ein anderes Element im Client anzuwenden.

Hier ein kleines Beispiel anhand einer XPage, die vor dem Partial Refresh wie folgt aussieht:

Screenshot: Vor dem Partial Refresh

Der Code der XPage ist ebenfalls simpel, ausser das bei einem Partial Refresh der XPage ein Header an den Request angefügt wird. Dazu wird das Event afterRestoreView genutzt.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">

    <xp:this.afterRestoreView><![CDATA[#{javascript:
        var exCon = facesContext.getExternalContext();
        var writer = facesContext.getResponseWriter();
        var response = exCon.getResponse();
        response.setHeader("X-XspRefreshId",  getClientId('label2') ); }]]>
    </xp:this.afterRestoreView>

    <xp:button value="Label" id="button1">
        <xp:eventHandler event="onclick" submit="true"
            refreshMode="partial" refreshId="label1">
        </xp:eventHandler>
    </xp:button>
    <xp:br></xp:br>
    <xp:br></xp:br>
    <xp:label value="Label1" id="label1"></xp:label>
    <xp:br></xp:br>
    <xp:br></xp:br>
    <xp:label value="Label2" id="label2"></xp:label>
</xp:view>

Der Button löst einen Partial Refresh auf das Label label1 aus, der dazugehörige Request, der an den Server gesendet wird liefert auch den zu erwartenden HTML-Code zurück:

<span id="view:_id1:label1" class="xspTextLabel">Label1</span>

Doch nun kommt der zusätzliche Header ins Spiel. Er bewirkt, dass nicht das label1 ersetzt wird, sondern das Element label2:

Durch den in der HTTP Header in der Antwort des Servers wurde das XSP-Objekt dazu veranlasst, den HTML-Code im DOM-Baum an einer anderen Stelle zu ersetzen.

In diesem kleinen Beispiel tritt ein kleiner Seiteneffekt auf: Das Label mit der id label2 verschwindet komplett aus dem DOM-Baum. Betätigt man den Button ein zweites Mal, funktioniert der Refresh nicht mehr, und folgende Fehlermeldung erscheint im Browser:

Abbrechen eines Partial Refresh im Client

4. Dezember 2011 Posted by Sven Hasselbach

Leider bietet das XSP-Objekt keine Möglichkeit, einen Partial Refresh via CSJS vorzeitig zu beenden. Zwar basiert der Partial Refresh-Mechanismus auf dojo.xhr-Requests, die diese Funktionalität bieten, doch das XSP-Objekt stellt keine Möglichkeit zur Verfügung, auf die darunter liegenden Dojo-Objekte zuzugreifen.

Um dennoch Zugriff auf die Requests zu erhalten, müssen die Aufrufe von dojo.xhrGet und dojo.xhrPost daher direkt abgefangen und umgebogen werden. Dadurch kann auf das  zurück gelieferte dojo.Deferred-Objekt zugegriffen werden und es lassen sich dessen Methoden verwenden.

Hier ein kleines Beispielskript, dass diese Aufgabe verrichtet. Es muss in einen CSJS-Scriptblock eingebettet werden:

var xhrCall = null;

dojo.addOnLoad( function(){
   /*** hijack dojo's xhrRequest ***/
   dojo._xhrPost = dojo.xhrPost;
   dojo._xhrGet = dojo.xhrGet;

   dojo.xhrPost = function( args ){
      xhrCall = dojo._xhrPost( args );
   }

   dojo.xhrGet = function( args ){
      xhrCall = dojo._xhrGet( args );
   }
});

Will man nun im Client einen Partial Refresh abbrechen, muss nur die cancel-Methode des dojo.Deferred-Objektes aufgerufen werden, und der Partial Refresh wird beendet*:

xhrCall.cancel();

[Die Methode cancel ist unter Dojo 1.3 dokumentiert; in höheren Versionen ist sie aber aus Kompatibilitätsgründen weiterhin vorhanden.]

Das Abbrechen eines Requestes wird allerdings als Partial Refresh-Fehler betrachtet. Um die Popup-Meldung des XSP-Objekts zu unterbinden, muss dem Partial Refresh noch ein eigener Error-Handler mitgegeben werden. Dieser darf ruhig leer sein, er sorgt nur dafür, daß die Fehlermeldung unterdrückt wird:

XSP.partialRefreshGet('id', { onError: function(){} } );

*: Der eigentliche AJAX-Request wird nicht abgebrochen, sondern die weitere Verarbeitung im CSJS unterbunden.

Performance-Tuning (5): Links und xsp.redirect

18. November 2011 Posted by Sven Hasselbach

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:

Screentshot: Firebug- Direktes Öffnen eines Links

[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.

Screenshot: Firebug - xsp.redirect=true

[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:

Screenshot: Firebug - xsp.redirect = false

[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:

Screenshot: Page1 - Before

[Page1.xsp vor dem Klick auf den Button]

Screenshot: Page1 - After

[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.

Screenshot: Zeit für Seitenaufbau mit xsp.redirect = true

[Zeit für Seitenaufbau mit xsp.redirect = true]

Screenshot: Zeit für Seitenaufbau mit xsp.redirect=false

[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.

Performance-Tuning (4): Fein-Tuning von xsp.resources.aggregate

11. November 2011 Posted by Sven Hasselbach

Mit Domino 8.5.3 wurde eine neue Option eingeführt, mit der automatisch verschiedene Ressourcen-Dateien vom Server vor der Auslieferung an den Browser zusammengefasst werden. Dadurch läßt sich die Performance einer Web-Applikation deutlich erhöhen, denn zum Einen werden dadurch weniger Anfragen vom Browser an den Server gesendet,  zum Anderen wird der Browser nicht unnötig “blockiert”, da sich die Anzahl der zu ladenden Ressourcen deutlich reduziert (siehe dazu RFC 2616)

In folgendem Artikel ist die neue Option xsp.resources.aggregate detailliert beschrieben, doch es gibt noch ein paar undokumentierte Optionen, mit denen sich das Verhalten der XPages-Engine genauer steuern läßt.

Dafür muß zu aller erst die Funktion aktiviert sein, das xsp.properties-File also folgende Zeile beinhalten:

xsp.resources.aggregate=true

Dann kann mit den folgenden Optionen das Verhalten für die einzelnen zu aggregierenden Ressourcen individuell festgelegt werden (Standardmäßig werden alle Ressourcen zusammen gefasst).

  • xsp.resources.aggregate.dojo

Wenn false, werden die Javascript-Libraries des Dojo Toolkits ausgeschlossen.

  • xsp.resources.aggregate.css

Schließt die Standard-CSS-Dateien aus, wenn false.

  • xsp.resources.aggregate.appcss

Schließt die CSS-Dateien der Applikation aus, wenn false.

  • xsp.resources.aggregate.appjs

Wenn false, werden die JavaScript-Libraries der Applikation ausgeschlossen.

Performance-Tuning (3): XSPClientLite.js

10. November 2011 Posted by Sven Hasselbach

Im xsp.properties-File gibt es einen undokumentierten Parameter, mit der sich eine abgespeckte Version der JavaScript-Routinen im Client einbinden läßt: die XSPClientLite.js. Die Library wird bei einer Standard-Installation von der IBM mitgeliefert.

Hierbei handelt es sich um eine deutlich kleinere Version der XSP Routinen, allerdings auch mit einem kleineren Funktionsumfang: Es fehlen z.B. die Routinen für Partial Refreshs, auf die aber je nach Anwendungsfall auch verzichtet werden kann. Hingegen sind z.B. die Clientseitige Validierung enthalten, oder aber die Methoden für das Auf-/Zuklappen von Sections, uvm.

Durch die kompakte Größe von nur 11 KB (rund 2/3 kleiner als die “normale” XSPClient-Library) läßt sich aber die Ladezeit verringern bzw. der Seitenaufbau der XPage beschleunigen; ob die Library die nötigen Funktionen bietet, die man auf der XPage verwenden möchte, muß aber im Einzelfall getestet werden.

Um die Library zu verwenden, muß im xsp.properties-File folgender Eintrag hinzugefügt werden:

xsp.client.script.libraries=lite

Dadurch wird die XSPClientLite.js anstelle der XSPClientDojo.js in der XPage eingebunden und vom Client verwendet.

Der Fluch des Partial Refreshs (2)

3. November 2011 Posted by Sven Hasselbach

Anscheinend liest jemand bei Google meinen Blog und reagierte auf meinen Artikel:

Heise Newsticker: Googlebot erfasst künftig mehr dynamische Seiteninhalte

Jetzt müssen nur noch die Browser-Hersteller einlenken…

Der Fluch des Partial Refreshs

30. Oktober 2011 Posted by 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.

disableXspCache: Programmatisch GZip-Komprimierung abschalten

20. Oktober 2011 Posted by 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.