FSS.social
25Sep 120

Mehrsprachige Anwendungen unter XPages

am Dienstag, den 25. September 2012

Laut IBM braucht man nur die Lokalisations-Option (bei den XPage Optionen) aktivieren, angeben in welchen Sprachen die Anwendung zur Verfügung stellen soll und erhält nach einem Clean für alle XPages und Customer Controls Elemente Properties Dateien, die man dann einem Übersetzer in die Hand drücken kann.

Anbei ein Screenshot von den Optionen (hier für Englisch/Deutsch wobei Englisch die Standardsprache bzw Orginalsprache ist)

XPages Mehrsprachig-1
Zunächst eine Warnung: Deaktiviert man die Option "Enable localization" werden alle übersetzten Properties-Dateien gelöscht. Entfernt man eine der Sprachen, werden die zugehörigen Dateien der Sprache gelöscht.

In der Praxis extrahiert die Lokalisationsroutine so gut wie möglich alle Texte wie z.B. Labels, Fehlermeldungen etc. Sie wird jedoch keine Texte aus berechneten Feldern oder Texte aus Javascript-Bibliotheken extrahieren.
Hier muß der Entwickler selbst noch einmal Hand anlegen und den Code mittels Javascript aus einer eigenen Property-Datei auslesen. (Beschreibung hierzu folgt)

Als Ergebnis der Extraktion enthält man dann properties-Dateien die wie folgt aussehen können:
<font color="blue"><blockquote><htmlblock>viewColumnHeader11/@value=[de| For Person/Team ]
switchFacet2/xe\:this.facets[1]/xp\:panel[2]/text()[2]=[de| \u00A0 ]
lnkCancel/xp\:eventHandler[1]/xp\:this.action[1]/xp\:actionGroup[1]/xp\:confirm[1]/@message=[de| Cancel adding a new member? ]</htmlblock></blockquote><font color="black">
Also ein paar Dateien bei denen sich so mancher Übersetzer erst einmal verwirrt die Augen reiben dürfte.

Bei kleinen überschaubaren Anwendungen, die nur aus einer Handvoll XPages/Customer Controls besteht ist dies sicher eine mögliche Variante.
Allerdings sollte man auch hier prüfen ob wirklich alle Texte eingefangen wurden und ob bei der Übersetzung nicht versehentlich ein Leerzeichen zu viel gelöscht wurde.

Sobald die Anwendung wesentlich komplexer wird z.B. aus vielen verschachtelten Customer Controls besteht, artet das Übersetzen schnell in eine Form von Schnitzeljagd für Entwickler aus und man fragt sich in welcher der vielen Properties-Dateien das eine oder andere Label noch einmal stand.

Übersetzung hausgemacht:
Alternativ zur obigen Lokalisierungsvariante kann man auch eigene Properties-Dateien erstellen

XPages Mehrsprachig-2

und diese als Datei-Resourcen seiner Anwendung hinzufügen.

XPages Mehrsprachig-3

XPages Mehrsprachig-4
Aus diesen Datei liest man nun die Texte für Labels, Fehlermeldungen, etc

Bei einem Label könnte folgender Javascript-Code stehen: <font color="blue"><blockquote><htmlblock>var message = strings.getString('greeting');
return message</htmlblock></blockquote><font color="black">
In einer Datei steht die passende Begrüßung auf Englisch (strings_en.properties) <font color="blue"><blockquote><htmlblock>greeting=Welcome</htmlblock></blockquote><font color="black">
und in einer anderen die Begrüßung auf Deutsch (strings_de.properties) <font color="blue"><blockquote><htmlblock>greeting=Willkommen</htmlblock></blockquote><font color="black">

Will man beim Willkommen noch den Namen des aktuellen Benutzers mit ausgeben, muss man zwei Stellen anpassen.
Einmal in den properties-Dateien: <font color="blue"><blockquote><htmlblock>greeting=Welcome {0} !</htmlblock></blockquote><font color="black">
Und dann muss man noch dafür sorgen, dass im Javascriptcode das "{0}“ durch den Namen ersetzt wird.
<font color="blue"><blockquote><htmlblock>var message = strings.getString('greeting');
message = I18n.format(message, @UserName());
return message</htmlblock></blockquote><font color="black">

Das Dateisuffix "_en" oder "_de" steht für die entsprechende Browser-Länderkennung. XPages kümmert sich dann selbst darum dass die passende Properties-Datei herangezogen wird.
Die Datei ohne Suffix z.B. strings.properties ist die Datei die gezogen wird, wenn für die Länderkennung keine eigene properties-Datei existiert.

Anbei noch zwei Links zu zwei ausführlichen englischsprachigen Artikeln zum Thema Übersetzung.
Eine Beschreibung wie man über die XPage Optionen eine Übersetzung vornimmt
Eine Beschreibung wie man über Javascripts auf eigene Properties-Dateien zugreifen kann

 

3Aug 120

XPages: Datenbankzugriff mit den Rechten des Signers

am Freitag, den 3. August 2012

Wenn ein Benutzer eine XPage öffnet, so greift der Server mit den Rechten des aktuellen Benutzers auf die Daten zu.
Somit muss - wenn die XPage auf anderen Datenbanken zugreift - für aktuellen Benutzer auch die entsprechenden Rechte in den anderen Datenbanken eingerichtet sein.

Dies ist allerdings nicht immer erwünscht.

Optional kann man ab 8.5.2 mit den Rechten des Signers auf die Datenbank zugreifen.
Dies erreicht man in dem man das Datenbankobjekt mit Hilfe der Funktion
sessionAsSigner.getDatabase() erstellt.
Hier ein kleines Beispiel.


var myDB:NotesDatabase = sessionAsSigner.getDatabase("","");
myDB.openByReplicaID(database.getServer(),myReplicaID);

Mit dem Datenbankobjekt kann anschließend wie gewohnt weitergearbeitet werden.


var myView:NotesView = myDB.getView(viewName);
Nur beim Löschen von Dokumenten gibt es noch ein Problem.
(
Gemeldet in der Version 8.5.3)

3Jul 120

XPages und die Validierung

am Dienstag, den 3. Juli 2012

XPages bietet von Hause aus eine ganze Reihe von Validierungsmöglichkeiten an.

Neben den üblichen Prüfungen ob ein Feld gefüllt wurde oder ob es einer regular expression genügt, kann man auch eigene Javascript-Routinen einbinden, die sich komplexere Prüfungen annehmen.

Hierzu kann man über die Eigenschaften einen neuen Validator namens validateExpression hinzufügen.
Der (serverseitige) Javascriptcode wird bei Expression hinzugefügt.
Wenn der Javascriptcode ein "false" zurückliefert wird die Fehlermeldung zurückgegeben die man unter "message" eingetragen hat.

XPages Validierung

Man kann zudem auch eigene ("Fehler-") Mitteilungen ins <font color="blue"> Display-Errors Control <font color="black"> schmuggeln.
Dazu gibt es bei Tommy Valand ein kleinen Code-Schnippsel (Link zur Orginalseite)
<font color="blue"><blockquote><htmlblock>
function addFacesMessage( message, component ){
try {
if( typeof component === 'string' ){
component = getComponent( component );
}

var clientId = null;
if( component ){
clientId = component.getClientId( facesContext );
}

facesContext.addMessage( clientId, new javax.faces.application.FacesMessage( message ) );
} catch(e){
/*Debug.logException(e);*/
}
} }
</htmlblock></blockquote><font color="black">

Ruft man mit serverseitigem Javascript die obige Funktion wie folgt auf <font color="blue">
addFacesMessage("Die Datenbank xyz wurde nicht gefunden,","IDEinesFeldes")
<font color="black"> wird die Meldung im Display-Error Control angezeigt.

Anbei noch ein paar interessante Links rund um das Thema::
Hier findet man eine Beschreibung der Validierungsmöglichkeiten Link zu www-10.lotus.com
Hier ist noch eine Alternative von Tommy Valand zum Display Control. Link zu Tommy Valands Blog
Hier findet man eine größere Liste mit regularen Expressions Link zu regexlib.com

 

14Mai 120

Xpages: Wenn der IE 9 die XPage nicht im Dokumentmodus IE7 öffnen soll

am Montag, den 14. Mai 2012

Browser sind ab und zu für Überraschungen gut.
So öffnet der IE 9 XPages im Dokumentmodus "
Internet Explorer 7 Standard" also quasi in einem Kompatibilitätsmodus.

Soll der IE 9 überredet werden, seine aktuelle Rendering-Engine zu verwenden, so muss der jeweiligen XPage der Parameter "
X-UA-Compatible" mitgegeben werden.
Hierfür gibt es den Wert
IE=edge

Schreibt man den folgenden Code ins
BeforeRenderingResponse-Event, so lässt der IE 9 das mit dem Kompatibilitätsmode sein.

var exCon = facesContext.getExternalContext();
var response = exCon.getResponse();

response.setHeader("X-UA-Compatible", "IE=edge");

15Mrz 120

XPages: Abfragen von radiobuttons mit javascript (clientseitig)

am Donnerstag, den 15. März 2012

Nicht selten sind es die kleinen Änderungen, die plötzlich mehr Zeit verschlingen als erwartet.

Die Aufgabe:
Wenn man bei einem Radiobutton einen neuen Wert auswählt, soll über eine Dialogbox nachgefragt werden, ob man dies wirklich ändern will.
Überlegt es sich der Anwender noch einmal anders, so soll der neue Wert ignoriert werden.

Auf den ersten Blick sieht dies nach einer Aufgabe aus, die schnell erledigt ist.
Doch wie so oft liegt die Tücke im Detail.

Zunächst wartet bei den Events eine Überraschung:
Der IE (8 & 9) ignoriert unter XPages beim RadioButton das onChangeEvent()

Somit darf das onChangeEvent über das onClick Event nachgebildet werden.

Beim onClick-Event muss berücksichtigt werden, dass dieses bei der Auswahl eines neuen Wertes zweimal durchlaufen wird.
Einmal mit dem alten und einmal mit dem neuen Wert.

Den alten Wert der RadiobuttonGroup erhält man über folgenden Ausdruck:

alterwert = '#{javascript:getComponent("radioGroup1").getValue();}';

Beim Versuch den neuen Wert zu ermitteln, wartet dann die nächste Überraschung.
Einige empfehlen hier folgende Variante:


var elements = dojo.byId(id);
for(i=0;i if (elements[i].value == value) {
elements[i].checked = true;
}
}


Kleiner Schönheitsfehler: Dies klappt zwar mit dem Firefox einwandfrei aber der IE (8 & 9) hält von dieser Variante nichts. Das Element daß der IE zurückgibt enthält schlichtweg keine Elemente durch die man sich durchhangeln könnte.

Allerdings kann man sich recht elegant mit dojo.query den Wert des aktuell ausgewählten Radiobuttons holen:

elements = dojo.query('INPUT[type=radio][name=#{id:radioGroup1}]:checked');


neuerWert = elements[0].value;

Das Deaktivieren eines Radiobuttons ist mit dojo.query nicht mehr als ein Einzeiler:

dojo.query('INPUT[type=radio][name=#{id:radioGroup1}]:checked').forEach(function(n) {n.checked=false;});

Und auch das Setzen eines radiobuttons (z.B. den alten Wert) ist nicht mehr als eine Zeile

dojo.query('INPUT[type=radio][name=#{id:radioGroup1}][value='+alterwert+']').forEach(function(n) {n.checked=true;});

Die dojo.query-Varianten funktionieren mit Firefox und mit dem IE.

28Nov 110

CKEditor für die klassische Notes-Web-Entwicklung II (Infos zur Demo und Integration)

am Montag, den 28. November 2011

Auf zum zweiten und vermutlich nicht letzten Eintrag zum CKEditor.
Im letzten Eintrag hatte ich auf eine Demo-Datenbank verwiesen, wo der Rich-Text-Editor in eine Form eingebunden worden war.

Auf diese Demo will ich heute genauer eingehen.

Zur Demo: Die vier wichtigen Stellen

1. Zum einen muss das Rich-Text-Feld dem Klassennamen ckeditor-field verpasst bekommen (in der Demo-Form)

CKEditor-1
2. Dann müssen die Pfade korrekt gesetzt sein (in der Demo-Form)
Hier ein Beispiel wie die Pfade aussehen müßten, wenn man die Dojo und den CKEditor-Version auf einem 8.5.2 Server einbinden will.
Wer die Demo unter 8.5.3 laufen lassen will muss den hervorgehobenen Pfad anpassen

CKEditor-2
3. Die Javascript-Lib ckeditor_loader.js
Durch diese Routine werden alle Rich-Text Felder durch den Editor ersetzt,
Man kann die Stelle auch gut dazu nutzem um den CKEditor zu konfigurieren.
Um die Demo zum Fliegen zu bringen, muss hier nichts verändert werden.

4. Der Agent PassthuHTML
Der Agent sorgt dafür dass der eingebene Code im Rich-Text-Feld auch als HTML-Code angezeigt wird.
Hier muss für jedes Rich-Text-Feld eine Funktion aufgerufen werden.

 

Integration des CKEditors in die Notes Datenbank

Doch was ist wenn man z.B. die aktuelle Version des CKEditors einbinden will?
Oder wenn man den Editor gerne mit eigenen Plugins erweitern möchte.

Man könnte eine neue Version des CKEditor auf dem Server mit ablegen.
Schöner wäre es jedoch, wenn man die neue CKEditor-Version in die Datenbank integrieren könnte.

Den neuen CKEditor kann man relativ leicht in die Datenbank kopieren.
Hierzu wechselt man zunächst in die Java-Perspektive (Menu-Punkt: Window/Open Perspective/Java) und kopiert das ckditor-Verzeichnis in die Datenbank.

CKEditor-3
Ändert man den obigen Pfad (2) entsprechend um.

CKEditor-4

greift man nun auf den CKEditor in der Datenbank zu.

Allerdings läuft nun das komprimierte Javascript des Editors auf den folgenden Fehler:
<font color="blue"/>m.lang.contextmenu is undefined.<font color="black">

Wühlt man sich durch verschiedene Foren, stellt man fest, dass bereits mehrere Leute über diese oder ähnliche Meldungen gestolpert sind. Übrigens unabhängig von Notes.
Wirft man einen Blick ins Log des Notes-Servers, sieht man, daß der CKEditor beim Nachladen weiterer Javascript-Routinen auf die Nase fällt.
Beim Nachladen wird an den Pfad der Javascriptroutine ein Parameter angehangen (?t=xxxxx). Domino scheint aufgrund des Parameters fälschlicherweise zu glauben, daß es sich um ein Befehl für ihn handelt und läuft dabei auf einen Fehler.

Nimmt man nicht den komprimierten Code des Editors, sondern den Orginal-Source Code

CKEditor-5

stellt man verblüfft fest, dass es damit geht.
Allerdings braucht nun der Editor ungleich länger zum Laden des Javascript-Codes.

Sum summarum
Ist das System performant genug, so kann man den CKEditor bereits in eine Notes-Datenbank integrieren,
Besteht man auf den perfomanteren Weg und will den komprimierten Code des Editors einbinden, so muß entweder der CKEditor auf dem Server liegen oder man muss dem CKEditor abgewöhnen den Parameter mitzugeben. Allerdings dürfte es sehr mühselig sein im komprimierten <font color="blue">ckeditor.js<font color="black">-Code die Stelle zu finden und zu beheben.

21Nov 110

Scrollbars einer Ansicht ohne Repeater unter XPages

am Montag, den 21. November 2011

Das hier angesprochene Problem wurde bereits vor über einem Jahr thematisiert - nämlich hier. Im Wesentlichen geht es darum, die Scrollbars einer Ansicht so zu platzieren, daß die Spaltenüberschriften nicht "weggescrollt" werden. Für Firefox 8.0, Opera 11.52, Google Chrome 15.0.874.121 m und Safari 5.0.3 gibt's zumindest unter 8.5.2FP1 eine Lösung - beim IE 8 (andere hab' ich noch nicht getestet) klappt's leider nicht - undzwar indem man die display-Eigenschaft des tbody-tags auf "inline", "inline-block" oder "block" setzt, also per CSS bspw. so:

.xspdataTable tbody {

display:inline-block;

}


Blöd ist nur, daß man dann die Ansicht(en) komplett neu skalieren muss, da die Abstände und Ränder der Spalten und Überschriften meistens nicht mehr passen. Stellt sich also die Frage, ob man den Aufwand für eine Umstellung auf sich nehmen will/kann, oder eben doch andere Wege beschreitet. In jedem Fall wäre es schön, solch banale Dinge nicht mühsam ausprobieren zu müssen...


P.S.: Eigentlich wollte ich dies auch unter o. gen. Link posten, aber ich habe es leider mit meinem IBM-Account bisher nicht hinbekommen. Werde das bei Gelegenheit nachholen...

28Okt 110

Deutsche Version von Notes 8.5.3

am Freitag, den 28. Oktober 2011

Die deutsche Version von 8.5.3 hat keinen festen Ankündigungstermin. Sie wird aber voraussichtlich 4 Wochen nach der englischen Version erscheinen. Dies wäre ungefähr in der 2. Novemberwoche. So schreibt es auch Ed Brill in seinem Blog.

Die erste Gruppe (Chinesisch, Koreanisch, Japanisch, Deutsch, Italienisch, Französisch, Portugisisch und Spanisch ungefähr in der zweiten Novemberwoche. Dänisch, Niederländisch, Finnisch, Norwegisch und Schwedisch werden dann Mitte Dezember nachfolgen.

27Okt 110

CKEditor für die klassische Notes-Web-Entwicklung

am Donnerstag, den 27. Oktober 2011

Der CKEditor ist ein recht mächtiger Rich-Text-Editor, den man in seine webfähigen Anwendung einbauen kann.
Der eine oder andere mag ihn noch unter den Namen FCKEditor kennen.

Der Editor kennt eine ganze Anzahl von Aktionen/Befehle, die man auch auskonfigurieren kann.

Zusätzlich kann man den Editor um selbstgeschriebene Plugins erweitern.

Seit Notes 8.5.2 ist der CKEditor Bestandteil der Notes-Umgebung. Allerdings profitiert man nur unter XPages vom Editor.
Nun kann oder will man nicht alle Anwendungen gleich auf XPages heben um in den Genuss des Editors zu kommen.

Es gibt allerdings auch Wege den Editor bei klassischen Notes-Web-Anwendungen einzubinden.
Zum Beispiel in dem
Blog von Tommy Valand kann man eine Demo-Notes-Datenbank finden wo der CKEditor in eine Form eingebunden wurde.
Die Demo-Datenbank geht von einem 8.5.2er Server aus und greift auf die CKEditor Version des Servers zu.

Mit wenigen Anpassungen haben wir die Demo-Datenbank unter 8.5.1 zum Fliegen bekommen und haben nebenbei die neueste Version des CKEditors eingebunden.
Allerdings liegen hier die Dateien der neuen CKEditors (noch) auf dem Server.

Im nächsten Schritt werden wir die Editor-Dateien der neuen Version in die Notes-Datenbank integrieren.
Sobald es hierzu Erfolgsmeldungen gibt, werde ich mich in diesem Blog wieder zu Wort melden.

Anbei noch ein paar nützliche Infos rund zum CKEditor.
Homepage vom CKEditor
Ein
Tutorial in dem beschrieben wird wie man ein selbstgeschriebenes Plugin einbaut.

12Okt 110

Firefox und INotes verstehen sich wieder ab 8.5.2 FP3

am Mittwoch, den 12. Oktober 2011

Zwischenzeitlich hatten iNotes und der aktuelle Firefox ihre "Differenzen" (unter 8.5.2)
Jedenfalls sah man nach einem Firefox-Update eine ganze Weile keine E-Mails in seinem iNotes-Briefkasten mehr.

Wir haben festgestellt, daß seit der Version 8.5.2 FP3 sich die beiden wieder verstehen.