Das EntwicklerCamp ist leider fast vorbei. Mein zweiter Vortrag zum Thema „Fehlerbehandlung in Formelsprache, LotusScript, Java, JavaScript und XPages“ war heute vormittag.
Das nächste EntwicklerCamp ist vom 17.03. bis zum 19.03.2014. Ich freue mich schon!
Heute durfte ich den ersten meiner zwei Vorträge auf dem diesjährigen EntwicklerCamp halten.
Im Vortrag „XPages und Java“ ging es primär darum, wie eigene Klassen für XPages in Java geschrieben werden können, was Managed Beans sind und welche Elemente aus dem JSF-Umfeld sinnvoll für eigene Anwendungen eingesetzt werden können. Den Abschluss bildete eine Betrachtung des Model-View-Controller-Patterns und wie wir es in unserem assono XPages-Framework einsetzen.
Wie bereits berichtet, sind wir beim diesjährigen EntwicklerCamp wieder dabei. Weil eine Referentin ausgefallen ist, sind wir mit einem weiteren Vortrag eingesprungen.
Track 3 - Session 8: Fehlerbehandlung in Formelsprache, LotusScript, Java, JavaScript und XPages
Mittwoch, 13.03.2013, 11:00-12:30
Die Beschreibung des Vortrages lautet:
Sie haben eine Anwendung gut entwickelt und getestet. Trotzdem passiert das Unerwartete: ein Fehler ist aufgetreten. Jetzt entscheidet sich, ob Sie wirklich ein Profi sind.
Fehlerbehandlung ist das wahrscheinlich am meisten unterschätzte Thema in der Lotus Notes Anwendungsentwicklung.
Angefangen von Formelsprache gehen wir weiter zu LotusScript, um uns dann den Hypethemen JavaScript, Java und XPages zuzuwenden. In allen Programmiersprachen zeigen wir die Möglichkeiten und diskutieren die jeweils sinnvollste Strategie.
Nicht, dass wir jemals Fehler machen würden. 
In XPages gibt es bei Radiobuttons im Zusammenhang mit einem Partial-Refresh bei einem onClick-Event einen ziemlich irreführenden Bug, wenn der Anwender auf das zugehörige Label klickt statt auf den Radiobutton selber.
Unmittelbar nach dem Anwender auf das Label geklickt hat, erscheint kurz die Änderung, um danach unmittelbar wieder den alten Stand anzuzeigen. Zur Verdeutlichung haben wir ein kleines Video vorbereitet.
Die Ursache für dieses Phänomen ist das Timing. Durch den Klick auf das Label, wird ein POST-Befehl für das Partial-Refresh ausgelöst. Zu diesem Zeitpunkt ist allerdings die Attributänderung des Radiobuttons noch nicht angekommen, so dass noch der alte Werte übertragen wird. Das ist auch der Grund warum magischer Weise über das Partial-Refresh der alte Stand wieder angezeigt wird.
Der Bug ist bei der IBM bekannt: LO71073: XPAGES RADIOBUTTON CLICK ON LABEL UNDONE BY PARTIAL REFRESH. Der aktuelle Status ist: "This APAR is closed as FIN. We have deferred the fix to a future release." Wobei FIN laut dem IBM Software Support Handbook für "der Fehler wird im nächsten Release gefixt" steht.
In der Zwischenzeit kann, wie so häufig, mit Hilfe von dojo Abhilfe geschaffen werden.
Der folgende Code sollte im Client-Side JavaScript onClick-Event hinterlegt werden.
var e = arguments[0] || window.event;
e = dojo.fixEvent(e);
if (e.target.type != "radio") {
e.preventDefault();
dojo.query("input",e.target).forEach(function(inputNode){
dojo.attr(inputNode,"checked",!(dojo.attr(inputNode,"checked")));
});
}
return true;
Das Event wird zunächst in der Variable e gespeichert. Mit dojo.fixEvent(e) wird der Unterschied im Eventhandling zwischen IE und den standardkonformen Browsern nivelliert.
Wenn auf das Label geklickt wurde (e.target.type != "radio"), dann wird zunächst das Standardverhalten des Events unterbunden (e.preventDefault()). Anschließend wird das zugehörige Input-Feld gesucht und das Attribute auf "checked" gesetzt.
Der dojo.query-Befehl funktioniert, weil die XPages Laufzeitumgebung ein Radiobutton wie folgt realisiert:
<label> <input type="radio" value="Banana" name="view:_id1:radioGroup1">Banana </label>
Das Input-Element ist also ein Kindelement des geklickten Labels. Somit kann über dojo.query("input", e.target) nach allen Input-Elementen unterhalb des Elementes gesucht werden, auf den das Event ausgelöst wurde. In unserem Fall also das Label.
Es sollte übrigens bei Radiobuttons und Checkboxes immer das onClick-Event verwendet werden, weil der IE beim onChange-Event ebenfalls ein Timing-Problem hat. Wenn im IE das onChange-Event ausgelöst wird, ist die Attributänderung auch noch nicht vollzogen.
Wie auch schon letztes Jahr sind wir dieses Jahr bei der Lotusphere Connect Konferenz mit einer Birds-of-Feather-Session vertreten.
|
BOF204 - XPages and Java: Share your experience
|
|
| Session date | Thursday, 2013-01-29 |
| Session time | 6:30 pm - 7:30 pm |
| Session location | Swan Hotel, Swan Parrot 1 |
| Speaker | Bernd Hort, assono GmbH |
This session is about sharing experiences with using Java in XPages. Over the last few years we have been building a Java-based framework for XPages applications, therefore we have a lot of experiences to share. Share your experiences with us. If you are new to writing your own Java classes for XPages applications, then bring your questions!
Beim Thema mobile Endgeräte gibt es zwei wesentliche Erkenntnisse. Die erste Erkenntnis ist, dass Smartphones und Tablets die Art und Weise wie wir leben und arbeiten in wenigen Jahren grundlegend verändert haben. Man darf gespannt sein, was die Zukunft noch alles bringt, denn bei dieser Entwicklung stehen wir erst am Anfang,
Die zweite Erkenntnis aus Sicht des Softwareentwicklers betrifft die Frage, wie mobile Anwendungen am Besten zu entwickeln sind. Die verschiedensten Ansätze gehen von einfachen Web Anwendungen bis hin zu nativen Anwendungen, die für das jeweilige Smartphone / Tablet Betriebssystem geschrieben werden. Das Spannungsfeld liegt, wie bei den meisten Entscheidungen in der Software-Entwicklung, im Dreieck zwischen Qualität, Zeit und Budget. Wobei in dem Fall Qualität sich auf die optimale Nutzung der Möglichkeiten des jeweiligen Betriebssystem bezieht.
Um es klar zu sagen: Wenn Zeit und Budget keine Rolle spielt, ist eine native Anwendung sicherlich das Optimum. Vor zwei/drei Jahren war diese Entscheidung noch einfacher. Das iPhone und damit iOS war das Maß aller Dinge. Mit dem stärker werdenden Marktanteil von Android mussten mindestens zwei Plattformen unterstützt werden. Im primär geschäftlichen Umfeld konnten Anwendungen auch für BlackBerry entwickelt werden. Eventuell schafft es Microsoft zusammen mit Nokia doch noch, Windows 8 zu einem erst zu nehmenden Player in dem Markt werden zu lassen.
Mit dem stärker werdenden Trend Bring-Your-Own-Device fällt die Entscheidung, welche Plattform unterstützt werden soll, zunehmend schwieriger. Für zwei oder drei, eventuell sogar vier, Plattformen native Anwendungen zu entwickeln und auch noch "Feature"-gleich zu halten, bedeutet erhebliche Mehraufwände. Zumal das notwendige Know-how für jede dieser Plattformen vorhanden und stets aktuell gehalten werden muss.
Eine Alternative sind Entwicklungsumgebungen wie PhoneGap. Der Anwendungscode wird Plattform-unabhängig entwickelt und anschließend werden für die jeweiligen Plattformen native Clients generiert. Es kann dementsprechend nur der kleinste gemeinsame Nenner aller Plattformen unterstützt werden, aber auch der hat schon einen beträchtlichen Umfang. Gegebenenfalls kann aber auch PhoneGap so eingesetzt werden, dass auf die besonderen Fähigkeiten der einzelnen Plattformen Rücksicht genommen wird.
Auf der anderen Seite werden Web Anwendungen für Smartphones / Tablets mit den Möglichkeiten von HTML5 und CSS3 auch immer mächtiger. Das neueste Schlagwort in diesem Bereich heißt "Responsive (Web) Design". Ziel dabei ist es, die Anwendung von vorne herein so zu entwickeln, dass sie möglichst sowohl im Desktop-Browser als auch von mobilen Browsern optimal zu bedienen ist. Dieser Ansatz verspricht deutlich geringere Kosten bei der Entwicklung.
Bleibt also die Frage, was ist die richtige mobile Entwicklungsstrategie insbesondere im Hinblick auf XPages-Anwendungen?
Die vielleicht auf den ersten Blick unbefriedigende Antwort lautet: Es hängt von den Anforderungen ab.
Themen wie Push-Notifikationen, Zugriff auf Kalender / Kontakte auf den mobilen Geräten und Verschlüsselung sprechen für einen nativen Client. Auch der Themenbereich Offline-Fähigkeit ist eventuell ein Grund eher in Richtung nativer Client zu gehen.
Ist ein nativer Client notwendig, so favorisieren wir PhoneGap. Einfach aus dem Grund heraus, dass in PhoneGap in HTML und JavaScript entwickelt wird. Wir können also das Know-how und die Erfahrung aus der XPages-Welt nutzen.
Wenn die Anforderungen aber den nativen Client nicht zwingend erforderlich machen, so ist die Web Entwicklung unsere erste Wahl. Eine Anwendung so zu entwickeln, die sowohl vom Desktop als auch von mobilen Endgeräten bedient werden kann, ist allein vom Zeit- und Kostenaspekt her absolut sinnvoll.
Was bedeutet diese Unsicherheit bezüglich der Architektur nun für unser XPages-Framework?
Das in meinem letzten Blogeintrag "assono XPages-Framework - Trennung von Business Logik und Darstellung" beschriebene Prinzip des Model View Controller–Pattern kann seine Vorteile voll ausspielen.
Das Model View Controller–Pattern ist so aufgebaut, dass die Business–Logik sich komplett im so genannten Model befindet. Die Oberfläche wird in der View realisiert. Die gesamte Interaktion zwischen dem Model und der View wird über den Controller gesteuert. Das Model View Controller–Pattern auf XPages angewendet hat folgenden Aufbau.
Betrachten wir einmal die verschiedenen Szenarien für mobile Anwendungen.
Sollte sich die Anforderungen an das Projekt so umsetzen lassen, dass sich die Anwendung mit der gleichen Weboberfläche gut sowohl im Desktop-Browser als auch im mobilen Browser bedienen lässt, so benötigen wir lediglich ein Model, einen Controller und die XPage.
Bisweilen greift der Ansatz des "Responsive (Web) Design" zu kurz und separate Webseiten für mobile Browser sind unumgänglich. In einem solchen Fall können die gleichen Klassen für das Model verwendet werden. Jeglicher Code, die Business-Logik betreffend, ist also nur einmal vorhanden. Es müsste lediglich ein weiterer Controller für die Interaktion geschrieben werden und die XPages für den mobilen Browser.
Für die Datenanbindung für native Anwendungen bieten sich REST-Services an. Selbstverständlich müssen für Daten, die über eine native Anwendung in das System gelangen, die gleichen Regeln gelten wie für Daten vom Desktop-Browser. Über einen separaten Controller wird wiederum der gleiche Code im Model angesprochen, so dass Business-Logik immer die gleiche ist.
Zusammenfassend liegt der große Vorteil in unserem XPages-Framework darin, dass unabhängig von der Zugriffsart immer der gleiche Code im Model angesprochen wird. Jede Anpassung auf der Ebene muss nur einmal vorgenommen werden. Dieses Prinzip spart Entwicklungszeit und sorgt für eine bessere Wartbarkeit der Anwendung.
Als wir anfingen uns mit XPages zu beschäftigen, waren wir sehr schnell begeistert von den neuen Möglichkeiten, moderne Web-Anwendungen auf Basis von IBM Lotus Notes und Domino zu entwickeln. Insbesondere hat uns gut gefallen, dass die Stärken von Lotus Notes und Domino, wie Sicherheit, Volltextsuche, Mail-Integration und viele mehr, kombiniert wurden mit einer auf JavaServer Faces basierenden Entwicklungsumgebung.
Relativ schnell wurde uns klar, was uns bei XPages fehlte: die Trennung zwischen der Business-Logik und der Oberfläche der Anwendung. Dieses Prinzip der Anwendungsentwicklung gewährleistet ein höhere Codequalität und eine bessere Wartbarkeit.
Unsere bisherigen auf LotusScript basierenden Notes-Client-Anwendungen waren schon nach diesem Paradigma entwickelt worden. Bei XPages die Business-Logik in einzelnen Feldern und Aktionen zu hinterlegen, kam uns wie ein Rückschritt vor.
Aus diesem Grund hatten wir uns entschieden, ein XPages-Framework nach dem Model View Controller-Pattern mit einer sauberen Trennung zwischen der Business-Logik und der Oberfläche zu entwickeln.
Das Model View Controller-Pattern ist so aufgebaut, dass die Business-Logik sich komplett im so genannten Model befindet. Die Oberfläche wird in der View realisiert. Die gesamte Interaktion zwischen dem Model und der View wird über den Controller gesteuert.
Der große Vorteil bei dieser Aufteilung besteht darin, dass das Model selber nichts von seiner Darstellung weiß. Wenn nun Änderungen an der Oberfläche vorgenommen werden, so muss an dem Code für die Business-Logik keine Anpassung vorgenommen werden. Somit wird die Gefahr verringert, dass unbeabsichtigt bereits funktionierender Code fehlerhaft wird. Weil die View mittels des Controllers nur über wohl definierte Schnittstellen auf das Model zugreifen kann, wird im Umkehrschluss das Risiko von Seiteneffekten minimiert, wenn es Anpassungen an der Business-Logik gibt.
Dieses Prinzip des Anwendungsaufbaus setzen wir bereits seit 2006 erfolgreich bei unseren klassischen Notes-Anwendungen ein. Wer einmal einen genaueren Blick darauf werfen möchte, kann bei OpenNTF fündig werden, Unser Framework steht dort unter der Apache-Lizenz als assono Framework 2 als Open Source zur Verfügung.
Das Model View Controller-Pattern auf XPages angewendet hat folgenden Aufbau.
Bei der Implementierung unseres XPages-Frameworks haben wir uns entschieden, Java den Verzug gegenüber Server Side JavaScript zu geben. Die Model- und die Controller-Klassen sind somit komplett objektorientiert in Java geschrieben.
Welche Vorteile ergeben sich aus diesem Aufbau? Aus unserer Sicht sind es eine ganze Menge!
Die Business-Logik in den Model-Klassen kann unabhängig von der eigentlichen XPage entwickelt und getestet werden. Somit können für die Model-Klassen automatisierte Tests, z.B. für JUnit, geschrieben werden. Außerdem kann parallel von mehreren Entwicklern sowohl an der Business-Logik als auch an der Oberfläche geschrieben werden. Neben dem Zeitvorteil ist dabei auch entscheidend, dass Entwickler mit unterschiedlichen Erfahrungen und Wissensständen in HTML, CSS, JavaScript und Java eingesetzt werden können. So kann ein Entwickler mit mehr Erfahrungen in der Web-Programmierung die eigentliche XPage entwickeln, während ein anderer Entwickler mit LotusScript-Hintergrund sich leichter in der Java-Welt zurechtfindet.
Auch das ist ein Vorteil des Framework-Ansatzes: Das Framework kümmert sich um die Interaktion zwischen Model-Klasse und der XPage. Der Entwickler definiert lediglich, welche Felder Pflichtfelder sind und der Controller sucht automatisch die zugehörigen Eingabeelemente heraus. Zusätzlich dazu werden auch automatisch alle korrespondierenden Label mit einer definierten CSS-Klasse versehen, so dass der Anwender alle Pflichtfelder als solche erkennen kann.
Ein weiterer Vorteil kommt mit der Zeit immer stärker zum Tragen, wenn an schon länger produktiven XPages-Anwendungen Anpassungen vorgenommen werden sollen: In unserem Framework befindet sich jeder Code, der Business-relevant ist, zentral in den Model-Klassen. Unabhängig davon wer ursprünglich die XPages-Anwendung entwickelt hat, der jetzt mit der Maintenance beauftragte Entwickler findet den entscheidenden Code an einer zentralen Stelle.
In folgenden Blog-Artikeln werden wir auf weitere Aspekte unseres XPages-Frameworks eingehen.
Wie ich heute schmerzlich erfahren musste, sind die JVMs (Java Virtuell Maschine) auf den unterschiedlichen Lotus Domino Serverplattformen bei gleicher Versionsnummer nicht identisch und verhalten sich leider auch nicht identisch.
Entwickelt und getestet hatte ich die XPage-Anwendung auf einem Linux-System mit den folgenden Werten.
Der Kunde betreibt seinen Server auf SunOS.
Normallerweise dürfte es keinen Unterschied machen. In meinem Fall hat sich die Implementierung von java.util.TreeSet. aber doch erheblich im Verhalten unterschieden.
Konkret ging es darum, ein bestehendes TreeSet umzusortieren. Der allgemein verwendete Weg besteht darin, ein neues TreeSet mit einem anderen Comparator zu erstellen und mit Hilfe der Methode TreeSet.addAll(Collection c) die Einträge aus dem alten TreeSet zu übernehmen.
Ich kenne keine Konferenz im deutschsprachigen Raum bei der soviel geballtes Notes-Know how vorhanden ist. Es macht wirklich jedes Jahr viel Spaß. Auch wenn dieses Jahr der Schwerpunkt eindeutig XPages war, gab es auch viele spannende Vorträge zu anderen Entwicklungsthemen.
Das nächste EntwicklerCamp ist vom 11.03. bis zum 13.03.2013. Wir werden sicherlich wieder mit dabei sein!
Noch ein Hinweis zum Thema "Java unter Lotus Domino". Es gibt ein sehr gutes Buch von
Thomas Ekert: "Java unter Lotus Domino" vom Springer Verlag, ISBN 978-3540221760, 804 S.
Das Buch ist auf Deutsch und wird zur Zeit zu einem genialem Preis von 9,95 € verkauft.
|
BOF124 - XPages and
Java: Share your experience
| |
| Session date | Monday, 2012-01-16 |
| Session time | 6:15 pm – 7:15 pm |
| Session location | Swan Hotel, Swan Macaw 1 |
| Speaker | Bernd Hort |
![EntwicklerCamp/](\"http://www.assono.de/blog/Images/D21A73CAB1980C76C125783F004C42DD/EntryRichMime/M2?OpenElement\")
![\"A](\"http://www.assono.de/blog/Images/D21A73CAB1980C76C125783F004C42DD/EntryRichMime/M3?OpenElement\")
![\"A](\"http://www.assono.de/blog/Images/D21A73CAB1980C76C125783F004C42DD/EntryRichMime/M4?OpenElement\")
![](\"http://www.assono.de/blog/Attachment/zip.gif\")
![](\"http://www.assono.de/blog/Attachment/pdf.gif\")