Posts Tagged: ‘XSP’

LotusScript in XPages (2): LotusScript-Wrapper

8. April 2012 Posted by Sven Hasselbach

LotusScript in XPages

Dies ist der zweite Teil des Artikels “LotusScript in XPages”. Der erste Teil befindet sich hier.

 

Der LotusScript-Wrapper

Um dynamischen LotusScript-Code auszuführen, bietet sich die Execute()-Funktion an: Mit der Funktion lässt sich fast der gesamte Umfang der LotusScript-eigenen Backendfunktionalität nutzen, also auch Scriptlibraries einbinden uvm.

Leider steht diese Methode jedoch nicht  in Java direkt zur Verfügung (im Gegensatz zur Session.evaluate()-Methode für @Formelsprache), so dass nur der Umweg bleibt, die Funktion durch Aufruf eines LotusScript-Agenten zu verwenden, und das Ergebnis an die XPage zurück zu liefern. Dabei wird der auszuführende LotusScript-Code und das Ergebnis der Operation über ein temporäres NotesDokument via DocumentContext hin- und hergereicht.

Hier die Klasse “LSExceutor”, die die nötigen Hilfsfunktionen bereitstellt:

package ch.hasselba.xpages.jsf.el;

import javax.faces.context.FacesContext;
import java.util.Vector;
import lotus.domino.Agent;
import lotus.domino.Database;
import lotus.domino.Document;

public class LSExecutor {
    private final static String agentName  = "(LSExecutor)";
    private final static String fieldLSResult = "LSResult";
    private final static String fieldLSCode = "LSCode";

    public static Vector execLotusScriptCode( final String lscode ){
        try{
            Database curDB =  (Database) getVariableValue("database");
            Document doc = curDB.createDocument();
            String hlp = lscode.replace( "\n", "\t" );
            doc.appendItemValue( fieldLSCode, hlp );
            Agent agent = curDB.getAgent(  agentName );
            agent.runWithDocumentContext( doc );
            return doc.getItemValue( fieldLSResult );

        }catch(Exception e){
            e.printStackTrace();
        }
        return null;
    }

     public static Object getVariableValue(String varName) {
         FacesContext context = FacesContext.getCurrentInstance();
         return context.getApplication().getVariableResolver().
          resolveVariable(context, varName);
     }
}

Die statische Methode execLotusScriptCode() wird in den Bindings verwendet, die in Teil 1 beschrieben wurden. Durch den Umstand, dass die runWithDocumentContext()-Methode auf das Ende der Agentenausführung wartet, ist eine sequentielle Verarbeitung gewährleistet.

Der Agent ist ebenfalls recht einfach aufgebaut:

%REM
    Agent LSExecutor
    Created Apr 6, 2012 by Sven Hasselbach/Sven Hasselbach
    Description: LSExecutor agent is a mapper for executing
                 LotusScript code from XPages
%END REM
Option Public
Option Declare

Const fieldLSCode = "LSCode"
Const fieldLSResult = "LSResult"

Dim returnValue
Sub Initialize
    Dim session As New NotesSession
    Dim doc As NotesDocument
    Dim lsCode, tmp , ret

    Set doc = session.Documentcontext
    lsCode = doc.Getitemvalue( fieldLSCode )
    tmp = Evaluate( | @ReplaceSubstring( "| & _
        lsCode(0) & |"; @Char(9) ; @Char(10) ) | )

    ret = Execute( tmp(0) )
    doc.Replaceitemvalue fieldLSResult , returnValue

End Sub

Um auf das Ergebnis der Berechnung zurückgreifen zu können, muss eine globale Variable verwendet werden, da die Execute()-Funktion selbst keine Rückgabemöglichkeit bietet (siehe Domino Designer Hilfe). In diesem Fall ist es “returnValue”, dessen Wert in das via DocumentContext übergebene Dokument geschrieben wird. Entsprechend muss der LotusScript-Code angepasst sein, siehe dazu auch die Beispiele am Anfang des 1. Teils des Artikels. Hier zeigt sich eine Schwachstelle: Es können keine Objekte zwischen Java und LotusScript übergeben werden; ein Zugriff auf z.B. den FacesContext ist in LotusScript nicht möglich. Soll eine DocumentCollection zurück geliefert werden, muss dieses als Array von DocumentUniversalIds geschehen usw.

Der Agent muss im Namen des Benutzers laufen, daher muss der “Run as Web user”-Haken gesetzt sein:

Im dritten Teil wird eine Quick-n-Dirty-Variante gezeigt, die BindingFactory bekannt zu machen.

 

Anmerkung:

An dieser Stelle sei nocheinmal ausdrücklich darauf hingewiesen, das der hier gezeigte Code sich maximal im “Alpha”-Status befindet.

LotusScript in XPages (1): Basics

7. April 2012 Posted by Sven Hasselbach

LotusScript in XPages

Wäre es nicht schön, wenn man in XPages direkt mit Lotus Script arbeiten könnte? Wenn es einen Weg gäbe, mit der sich Lotus Script-Code direkt in der XPage einbetten liesse, und wie folgt zu verwenden wäre?

Prinzipiell ist das möglich, aber der hier dargestellte Weg ist eher als Workaround anzusehen und wird das Alpha-Stadium wohl eher nicht verlassen. Aber es lässt sich anhand dieser Anleitung zeigen, wie man XPages flexibel erweitern und weitere Interpreter-Sprachen der XPages-Engine hinzufügen kann.

Was mit der hier vorgestellten Lösung jedoch möglich ist, kann man in dieser kleinen Beispiel-XPage sehen:

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

   <xp:label id="label1">
      <xp:this.value>
         <![CDATA[#{lotusscript:returnValue=-1 }]]>
      </xp:this.value>
   </xp:label>
   <xp:br/>
   <xp:br/>
   <xp:label id="label2">
      <xp:this.value><![CDATA[${lotusscript:
         Dim session as New NotesSession
         Dim db as NotesDatabase
         Set db = session.CurrentDatabase

         returnValue = db.AllDocuments.getFirstDocument.UniversalID
      }]]></xp:this.value>
   </xp:label>
</xp:view>

In der XPage kann der neue Tag “lotusscript:” verwendet und beliebiger LotusScript-Code direkt in die XPage eingebettet werden. Das Ergebnis im Browser sieht dann wie folgt aus:

Soviel vorab, nun zu erst einmal zu den Basics…

Grundlagen: Method-Bindings & Value-Bindings

Um einen neuen Tag für XPages bereitzustellen, müssen zu aller erst Bindings für Methoden- und für Werte-Zuweisungen erstellt werden. Die beiden Binding-Arten unterscheiden sich – grob formuliert* – wie folgt: Value-Bindings werden überall dort verwendet, wo ein Wert einer Komponente zugewiesen wird und (wie der Name erahnen lässt) eine value-Eigenschaft exitsiert. Dies ist bei praktisch allen UIKomponenten der Fall. Method-Bindings hingegen kommen bei der Zuweisung bei samtlichen Events ins Spiel: Der SSJS-Code eines BeforePageLoad-Events wird mit einem Method-Binding gesetzt, oder der Code bei Button-Events usw.

Die Value-Binding-Klasse, die für die hier geschilderten Zwecke benötigt wird, sieht wie folgt aus:

package ch.hasselba.xpages.jsf.el;

import com.ibm.xsp.binding.ValueBindingEx;
import javax.faces.context.FacesContext;
import javax.faces.el.EvaluationException;
import javax.faces.el.PropertyNotFoundException;

public class LSValueBinding extends ValueBindingEx {
    private String data;

    public LSValueBinding(String content) {
        this.data = data;
    }

    @Override
    public Object getValue(FacesContext context)
        throws EvaluationException, PropertyNotFoundException {
            return LSExecutor.execLotusScriptCode( data );
    }

    @Override
    public void setValue(FacesContext context, Object obj)
       throws EvaluationException, PropertyNotFoundException {}

    @Override
    public boolean isReadOnly(FacesContext context)
        throws EvaluationException, PropertyNotFoundException {
            return true;
    }

    @SuppressWarnings("unchecked")
    @Override
    public Class getType(FacesContext context)
        throws EvaluationException, PropertyNotFoundException {
            return Object.class;
    }
}

Das Value-Binding erweitert die Klasse com.ibm.xsp.binding.ValueBindingEx und überschreibt deren Eigenschaften, wo es nötig ist. Im Konstruktor der Klasse findet die Wertezuweisung statt; es wird hier der Teil, der in der XPage nach dem “lotusscript:” folgt, übergeben. Auch mehrzeiliger Code in der XPage wird als einfacher String durchgereich, getrennt durch Zeilenumbrüche.

Um an den Wert des Bindings zu gelangen, wird während der Verarbeitung durch das JSF Framework die Methode getValue() aufgerufen; dies ist die Stelle, an der die Daten des Value-Bindings verarbeitet werden, und wie man hier sehen kann, findet der Aufruf des LotusScript-Codes genau an dieser Stelle statt.

Das notwendige Method-Binding ist so ähnlich aufgebaut:

package ch.hasselba.xpages.jsf.el;

import com.ibm.xsp.binding.MethodBindingEx;
import javax.faces.context.FacesContext;
import javax.faces.el.EvaluationException;
import javax.faces.el.MethodNotFoundException;

public class LSMethodBinding extends MethodBindingEx {
    private String data;

    public LSMethodBinding () {
        super();
    }

    public LSMethodBinding (String expr) {
        super();
        this.data = expr;
    }

    @Override
    public Object invoke(FacesContext context, Object[] obj)
        throws EvaluationException, MethodNotFoundException {
            return LSExecutor.execLotusScriptCode( content );
    }
    @SuppressWarnings("unchecked")
    @Override
    public Class getType(FacesContext context)
        throws MethodNotFoundException {
            return null;
    }
}

Hier wird wie Klasse com.ibm.xsp.binding.MethodBindingEx erweitert und wenn nötig überschrieben. Anders als bei Value-Binding erfolgt der “Abruf” der Daten eines Method-Bindings durch das JSF Framework nicht durch getValue(), sondern durch die Methode invoke(). Hierbei können theoretisch noch Parameter übergeben werden, die für die Verarbeitung relevant sein könnten. In diesem Fall kann dies aber getrost ignoriert werden.

Zu guter Letzt müssen die beiden Bindings in eine BindingFactory-Klasse zusammen geführt und mit dem “lotusscript“-Tag verbunden werden:

package ch.hasselba.xpages.jsf.el;

import com.ibm.xsp.util.ValueBindingUtil;
import com.ibm.xsp.binding.BindingFactory;
import javax.faces.application.Application;
import javax.faces.el.MethodBinding;
import javax.faces.el.ValueBinding;

public class LSBindingFactory implements BindingFactory {

    public String getPrefix() {
        return "lotusscript";
    }

    @SuppressWarnings("unchecked")
    public MethodBinding createMethodBinding(
         Application app, String expr, Class[] obj) {
        String script = ValueBindingUtil.parseSimpleExpression(expr);
        return new LSMethodBinding(script);
    }

    public ValueBinding createValueBinding(Application app, String expr) {
        String script = ValueBindingUtil.parseSimpleExpression( expr );
        return new LSValueBinding(script);
    }
}

Die Klasse erweitert com.ibm.xsp.binding.BindingFactory und ist die “Weiterleitung” innerhalb des JSF-Frameworks: Die Methode getPrefix() liefert den String zurück, für den diese BindingFactory zuständig ist; es ist praktisch jeder Bezeichner verwendbar, nur id und javascript sind bereits verwendet.

Während der Verarbeitung der Bindings such das JSF-Framework zur Laufzeit nach der passenden Factory. Dabei werden alle bekannten Factories nach dem passenden Prefix durchsucht, weshalb die BindingFactory dem Framework noch bekannt gemacht werden muss, um verwendet werden zu können.

Im zweiten Teil wird eine Quick-n-Dirty-Variante gezeigt, die BindingFactory bekannt zu machen und der LotusScript-Wrapper wird vorgestellt.

*: Anmerkung:

Aus Sicht der JSF-Spezifikation ist der Unterschied zwischen Value-Binding und Method-Binding etwas komplexer, als hier dargestellt.

“Compute Dynamically” Vs. “Compute on Page Load”

11. Februar 2012 Posted by Sven Hasselbach

Der Artikel von Mark Roden über den Mix von ${} und #{} zur gleichen Zeit brachte mich dazu, mich noch einmal ausführlich mit dem Thema “Compute Dynamically” und “Compute on Page Load” zu befassen, denn der hervorragende Artikel von Paul Withers erläutert zwar die grundsätzlichen Unterschiede zwischen den beiden Berechnungsvarianten, allerdings gibt es noch ein paar Ungereimtheiten.

Um einen Überblick über die Unterschiede bei der Verwendung aufzuzeigen, sind hier zehn Varianten aufgeführt, die in einigen Fällen interessante Ergebnisse liefern.

Zur Erläuterung:

  • XSP-Code ist der Code in der XPage
  • Java Code ist ein Screenshot des generierten Java Codes
  • Page Load ist ein Screenshot, wenn die Test-XPage geöffnet wird
  • Partial Refresh ist ein Screenshot nach eine Refresh des Computed Fields
  • Ergebnis stellt die Bewertung der Variante dar. Ob der Code wirklich mehrfach ausgeführt wurde, ist nicht geprüft worden, sondern nur das “sichtbare” Ergebnis im Browser

 

Variante 1: Compute Dynamically

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[#{javascript:java.lang.System.currentTimeMillis()}]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Wird jedesmal neu berechnet.

 

Variante 2: Compute on Page Load

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[${javascript:java.lang.System.currentTimeMillis()}]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung nur bei Page Load.

 

Variante 3: Compute Dynamically inside Compute on Page Load

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[${javascript:#{javascript:java.lang.System.currentTimeMillis()}}]]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung nur bei Page Load.

 

Variante 4: Compute on Page load inside Compute Dynamically

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[#{javascript:${javascript:java.lang.System.currentTimeMillis()}}]]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung nur bei Page Load.

 

Variante 5: Compute Dynamically inside Compute on Page Load (Hochkomma)

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[${javascript:'#{javascript:java.lang.System.currentTimeMillis()}']]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Wird jedesmal neu berechnet.

 

Variante 6: Compute on Page Load inside Compute Dynamically (Hochkomma)

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[#{javascript:'${javascript:java.lang.System.currentTimeMillis()}']]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung des “inneren” Codes findet nicht mehr statt.

 

Variante 7: Compute on Page Load inside inside Compute on Page Load (Hochkomma)

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[${javascript:'${javascript:java.lang.System.currentTimeMillis()}']]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung des “inneren” Codes findet nicht statt.

 

Variante 8: Compute Dynamically inside Compute Dynamically (Hochkomma)

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[#{javascript:'#{javascript:java.lang.System.currentTimeMillis()}']]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung des “inneren” Codes findet nicht statt.

 

Variante 9: Compute Dynamically inside Compute Dynamically (Hochkomma + Leerzeichen)

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[#{javascript:' #{javascript:java.lang.System.currentTimeMillis()} ']]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung des “inneren” Codes findet nicht statt.

 

Variante 10: Compute on Page Load inside Compute on Page Load (Hochkomma)

XSP Code

<xp:text id="computedField1">
   <xp:this.value>
      <![CDATA[${javascript:' ${javascript:java.lang.System.currentTimeMillis()} ']]>
   </xp:this.value>
</xp:text>

Java Code

Page Load

Partial Refresh

Ergebnis

Berechnung des “inneren” Codes findet immer statt.

Security: Domino Server Backdoor (2)

19. Januar 2012 Posted by Sven Hasselbach

Aus einer XPages-Applikation lässt sich der XSP Command Manager (das zugrundeliegende OSGi Framework) fernsteuern. Das Kommando entspricht dem Befehl

tell http xsp <BEFEHL>

auf der Domino Serverkonsole, nur dass hierfür kein Serverkonsolenzugriff benötigt wird.

Mit Hilfe der folgenden XPage lassen sich beliebige OSGi-Kommandos absetzen, also z.B. Prozesse starten, Bundles installieren (egal von welcher Quelle, auch aus dem Internet) und vieles mehr.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
   <xp:button value="Send XSP Command" id="button2">
      <xp:eventHandler
         event="onclick"
         submit="true"
         refreshMode="complete">
         <xp:this.action><![CDATA[#{javascript:
            var cmd = getComponent("inputTextXSPCmd").value;
            if( cmd == null || cmd == "")
               return;
            var xcm = com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.getInstance();
            xcm.tell( cmd );}]]>
         </xp:this.action>
      </xp:eventHandler>
   </xp:button>
   <xp:inputText id="inputTextXSPCmd" />
</xp:view>

Die Seite sieht wie folgt aus:

Beim Klicken auf “Send XSP Command” kann man das Ergebnis auf der Serverkonsole sehen:

Hier ein kleiner Auszug über mögliche Kommandos:

  • exec <PROGNAME> startet ein beliebiges Programm
  • fork <PROGNAME> startet ein beliebiges Programm in einem eigenen Thread
  • install http://example.com/osgi-bundle.jar start installiert ein OSGi-Bundle von der angegebenen Adresse
  • init stoppt das gesamte Framework
  • ss listet alle Bundles auf
  • help zeigt alle möglichen Befehle an.

Auch Heap-, System, und Java-Dumps lassen sich hierdurch erstellen.

Security: Domino Server Backdoor

7. Januar 2012 Posted by Sven Hasselbach

Mit XPages lässt sich ein Domino Server auf einfachste Weise lahm legen, da man über die Java Runtime beliebige Threads starten kann.

Ein kleiner Button startet z.B. Notepad auf einem Windows Domino Server:

<xp:button value="Start NotePad!" id="buttonStartNotePad">
   <xp:eventHandler event="onclick" submit="true"
      refreshMode="norefresh">
      <xp:this.action>
         <![CDATA[#{javascript:
            java.lang.Runtime.getRuntime().exec("notepad");}]]>
      </xp:this.action>
   </xp:eventHandler>
</xp:button>

 

Bei jedem Klick wird auf dem Domino Server einmal Notepad gestartet. Eine kleine Schleife, und auch ein großzügig dimensionierter Server geht in die Knie.

Richtig übel wird es allerdings, wenn dieser Button geklickt wird:

ACHTUNG! NICHT AUF PRODUKTIVEN SYSTEMEN AUSFÜHREN!

<xp:button value="KILL NOTES!" id="buttonKillNotes">
   <xp:eventHandler event="onclick" submit="true"
      refreshMode="norefresh">
      <xp:this.action>
         <![CDATA[#{javascript:
            java.lang.Runtime.getRuntime().exec("nsd -kill");}]]>
         </xp:this.action>
      </xp:eventHandler>
</xp:button>

Dann ist der Domino Server weg!

Bei dem “zerlegten” Server handelt es sich um eine Standard-Installation. Die java.policy wurde nicht geändert.

Quick-n-Dirty: Locale setzen

5. Januar 2012 Posted by Sven Hasselbach

Um die Locale-Einstellung einer XPage programmatisch zu beeinflussen, kann die Methode setLocaleString bzw. setLocale des context-Objektes verwendet werden.  Damit die Änderungen übernommen wird, muss die Einstellung im BeforePageLoad gesetzt werden.

So ändert ein…

context.setLocaleString("zh-tw")

… bzw. ein …

context.setLocale(java.util.Locale.TAIWAN)

…die Spracheinstellungen der generierten XPage. Sowohl das lang-Attribute der HTML-Seite als die Dojo-Konfiguration wird dabei gesetzt:

<!DOCTYPE html>
<html lang="zh-tw">
<script type="text/javascript"
src="/xsp/.ibmxspres/dojoroot-1.6.1/dojo/dojo.js"
djConfig="locale: 'zh-tw', parseOnLoad: true"></script>

Durch diese Änderung wird z.B. der Datepicker-Dialog des DojoToolkit auf Taiwanisch gerendert.

Eine Liste der möglichen Einstellungen findet sich in der Beschreibung des java.util.Locale-Objektes.

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] );
   }
});

Performance-Tuning (6): Parallele Partial Refreshs

7. Dezember 2011 Posted by Sven Hasselbach

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 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 parallenen 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 sequentiellen 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 sequentielles Aufrufen erforderlich machen. Doch wo es möglich ist, sollte aus Performancegründen der Einsatz von parallel ausgeführten Partial Refreshs erfolgen.

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.

OpenNTF XSnippets Beta gestartet

22. November 2011 Posted by Sven Hasselbach

XSnippets – The next generation code bin, ist als Beta gestartet.

Das neue OpenNTF Projekt dient als Sammlung für kleine Code-Schnippsel, die von der Community für die Community zur Verfügung gestellt werden. Hier sind die ersten Schnippsel zu finden.

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.

Application-Properties mittels SSJS auslesen

13. November 2011 Posted by Sven Hasselbach

Um Serverseitig zu ermitteln, welche Dojo-Version verwendet wird, kann folgender Code verwendet werden:

<xp:label id="lblJSVersion">
   <xp:this.value><![CDATA[#{javascript:var reqParam =
      new com.ibm.xsp.context.RequestParameters ( facesContext );
      reqParam.getLibraryVersion()}]]>
   </xp:this.value>
</xp:label>

[Code liefert unter 8.5.3 in der Standard-Einstellung "1.6.1" zurück]

Um zu ermitteln, ob die Clientseitige Validierung aktiviert bzw. deaktiviert ist, liefert die Methode isClientSideValidation() das gewünschte Ergebnis:

<xp:label id="lblIsCSValidation">
   <xp:this.value><![CDATA[#{javascript: var reqParam =
      new com.ibm.xsp.context.RequestParameters ( facesContext );
      reqParam.isClientSideValidation()}]]>
   </xp:this.value>
</xp:label>

[Liefer true bzw. false zurück, je nach Einstellung der Datenbank]

Welche Komprimierungseinstellung verwendet wird, kann so ermittelt werden:

<xp:label id="lblCompressMode">
   <xp:this.value><![CDATA[#{javascript:var reqParam =
      new com.ibm.xsp.context.RequestParameters ( facesContext );
      reqParam.getCompressMode()}]]>
   </xp:this.value>
</xp:label>

[Liefert z.B. "gzip-nolength" zurück, je nach Einstellung der Datenbank]

Ob überhaupt Dojo Verwendung findet, bzw. die XSPDojoLite.js-Version, liefert folgender Code:

<xp:label id="lblJsLibrary">
   <xp:this.value><![CDATA[#{javascript:var reqParam =
      new com.ibm.xsp.context.RequestParameters ( facesContext );
      var jsLib = reqParam.getJsLibrary();

      switch(jsLib){
      case 1:
         return "dojo";
      break;
      case 2:
         return "lite";
      break;
      default:
         return "none";
      break;
      }}]]>
   </xp:this.value>
</xp:label>

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.