Entwurf und Implementierung eines XForms

Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Software Engineering
Entwurf und Implementierung eines
XForms-Interpreters für Java Swing
Bachelorarbeit
im Studiengang Informatik
von
Lukas Klejnowski
Prüfer: Prof. Dr. Kurt Schneider
Zweitprüfer: Prof. Dr. Nicola Henze
Betreuer: Dipl.-Wirt.-Inform. Daniel Lübke
Hannover, 20. Februar 2006
Zusammenfassung
Die Arbeit mit Web Services erfreut sich heutzutage einer immer größeren
Beliebtheit. Diese sind für die Verwendung innerhalb von Anwendungen vorgesehen,
verfügen jedoch über keine eigene Schnittstelle um mit einem menschlichen
Benutzer zu kommunizieren.
XForms ist eine relativ neue XML basierte Sprache und dient vor allem
der
Beschreibung von XML Formularen, kann jedoch auch den Zugriff auf Web
Services erleichtern.
In dieser Arbeit wird eine Java Bibliothek entwickelt und vorgestellt, die es
ermöglicht XForms-Oberflächen durch Interpretation in einer Java Anwendung zu
integrieren. Dabei wird neben der Analyse der Anforderungen an eine solche
Bibliothek, ihre Architektur und Verwendbarkeit diskutiert.
Inhaltsverzeichnis
1.Einleitung......................................................................................................................................... 1
1.1 Motivation.................................................................................................................................. 1
1.2 Problemstellung.......................................................................................................................... 1
1.3 Struktur der Arbeit......................................................................................................................2
2.Anforderungen der Aufgabestellung............................................................................................. 3
2.1 Einführung................................................................................................................................. 3
2.2 Interpretation............................................................................................................................. 3
2.3 Zugriff auf Webservices............................................................................................................ 4
2.4 Architekturform Bibliothek....................................................................................................... 4
3.XForms............................................................................................................................................. 5
3.1 Einführung.................................................................................................................................. 5
3.2 Einleitung....................................................................................................................................5
3.3 Struktur....................................................................................................................................... 5
3.4 In XForms verwendete Technologien....................................................................................... 8
3.4.1 XML.................................................................................................................................... 8
3.4.2 XML Schema.......................................................................................................................9
3.4.3 XPath................................................................................................................................. 10
3.4.4 Weitere Technologien....................................................................................................... 10
3.5 Detailsicht auf XForms-Konzepte........................................................................................... 10
4.Realisierungskonzept.................................................................................................................... 14
4.1 Einführung................................................................................................................................ 14
4.2 Realisierungsaspekte................................................................................................................ 14
4.3 Vergleich von Java Swing- und XForms-User Interfaces........................................................ 16
5.Realisierung....................................................................................................................................20
5.1 Einführung................................................................................................................................ 20
5.2 Anforderungen..........................................................................................................................20
5.3 Grobentwurf..............................................................................................................................21
5.3.1 Komponenten.................................................................................................................... 22
5.3.2 Verwendete Bibliotheken.................................................................................................. 25
5.3.3 Packages............................................................................................................................ 26
5.3.4 Rationale für Grobentwurf................................................................................................ 27
5.4 Feinentwurf...............................................................................................................................30
5.4.1 Einführung......................................................................................................................... 30
5.4.2 Architektur.........................................................................................................................31
5.4.3 Rationale für Feinentwurf..................................................................................................38
5.4.4 Ablaufplan der Initialisierung............................................................................................40
5.5 Umsetzung in Java....................................................................................................................42
5.5.1 Processing Cycle............................................................................................................... 42
5.5.2 Events................................................................................................................................ 47
5.5.3 Actions ..............................................................................................................................49
5.5.4 Submission........................................................................................................................ 49
6.Betriebsinformationen.................................................................................................................. 51
6.1 Versionen..................................................................................................................................51
6.2 Lizenzen....................................................................................................................................51
6.3 Verwendung der Bibliothek in Anwendungen......................................................................... 51
6.4 Einschränkungen der Implementierung....................................................................................52
6.4.1 Einleitung.......................................................................................................................... 52
6.4.2 Funktionelle Einschränkungen.......................................................................................... 52
6.4.3 Syntaktische Einschränkungen ......................................................................................... 53
6.5 Erweiterbarkeit......................................................................................................................... 56
6.5.1 Einführung......................................................................................................................... 56
6.5.2 Implementierungskonzept................................................................................................. 56
6.5.3 Auswahl der wichtigsten Elemente................................................................................... 57
6.5.4 Erweiterung um Grundelemente........................................................................................57
6.5.5 Erweiterung um neue Elemente.........................................................................................58
6.5.6 Änderung der Komponenten............................................................................................. 58
7.Zusammenfassung und Ausblick................................................................................................. 60
8.Literaturverzeichnis...................................................................................................................... 61
A. Anhang.........................................................................................................................................62
A.1. Beispiele für die Intepretation und Anwendung...................................................................62
A.2. Erklärung.............................................................................................................................. 68
1. Einleitung
1.1 Motivation
Web Services sind seit ihrer Einführung vor einigen Jahren immer beliebter geworden.
Obwohl eine einheitliche Definition für Web Services nicht existiert, lässt sich die Idee, die
hinter diesem Konzept steckt folgendermaßen zusammenfassen: Service Provider bieten
(gegen Gebühr oder auf kostenloser Basis) Dienste an, die selbstbeschreibend sind und über
spezielle Protokolle gesucht und von Client-Software in Anspruch genommen werden
können.
Dies können einfache Dienste wie eine maschinenerzeugte und -verarbeitbare Google-Suche
[4] sein, aber auch komplexe Dienste wie die Berechnungen von optimalen Lieferketten.
Dabei dienen Web Services vor allem dem Einsatz in Business-to-Business Anwendungen mit
Service orientierten Architekturen (SOA), die modular aus mehreren Web Services
zusammengebaut werden. Das Ziel ist, neben der Nutzung der Dienste, die Interoperabilität
zwischen Applikationen, die Daten austauschen müssen, herzustellen.
Die technische Grundlage für Web Services bildet eine Reihe von XML-Technologien. Diese
dienen dem Verfügbarmachen, Finden und Nutzen von Web Services, bieten jedoch keine
User Interfaces für die Interaktion mit einem menschlichen Benutzer. Hier genau liegt die
Stärke von XForms [1]: Es ist ein XML-Dialekt für die Beschreibung von graphischen
Benutzeroberflächen, verwendet also XML-Daten als Grundlage und bietet die Funktionalität
von komplexen User Interfaces. Um zwischen dem Endanwender und dem Web Service zu
kommunizieren, stellt XForms das Bindeglied zwischen diesen beiden Sichten dar, bietet also
die endanwenderorientierte Sicht auf Web Services.
Hätte man eine XForms-Implementierung für Java, so wäre es möglich XForms-basierte
Oberflächen in Java Swing-basierten Anwendungen zu integrieren. Mit einer solchen
Bibliothek als Baustein könnten Applikationen erstellt werden, die es dem Nutzer erlauben,
komfortabel auf Web Services zuzugreifen, ohne dass die Entwickler sich mit der XFormsTechnologie ausführlich beschäftigen müssen. Zudem könnten diese dann in einer
einheitlichen Art bearbeitet werden und über die Anwendung Informationen miteinander
teilen.
1.2 Problemstellung
Das Ziel dieser Arbeit ist es, einen XForms-Interpreter für Java Swing zu entwickeln und zu
implementieren. Bei der hierbei zu erstellenden Bibliothek soll besonderer Wert auf die
Wartbarkeit sowie einfache Verwendbarkeit gelegt werden. Sie soll zudem so aufgebaut sein,
dass fehlende Funktionalität leicht nachgerüstet werden kann.
Die Bibliothek soll sich gut ins Web Service Umfeld einfügen und eine Basis für dynamisch
generierte Oberflächen sein. Hierzu sind die Basisfunktionalitäten von XForms-User
Interfaces zu ermitteln und zu implementieren.
-1-
1.3 Struktur der Arbeit
Die Arbeit beginnt mit der Erläuterung der Anforderungen die sich aus Aufgabenstellung
ergeben. Darauf folgend wird die Sprache XForms vor dem Hintergrund der Intepretation
vorgestellt. In Kapitel 4 wird das Konzept erläutert nach dem die Realisierung einer XFormsInterpreter-Bibliothek für Java durchgeführt wurde. In Kapitel 5 wird der Realisierung dieses
Konzeptes nachgegangen. Das nächste Kapitel hat die Implementierung der Bibliothek sowie
ihre Benutzung und Einschränkungen zum Inhalt. In Kapitel 7 schließlich sind die Ergebnisse
der Arbeit zusammengefasst.
-2-
2. Anforderungen der Aufgabestellung
2.1 Einführung
Eine Interpretation im Sinne der Informatik ist die Analyse und Ausführung des Quellcodes
eines Programmes ohne eine direkte Umwandlung in Maschinensprache (vgl. Kompilieren).
Ein Interpreter ist in diesem Sinne ein Programm, dass einen Code liest, untersucht und
schließlich zur Ausführung bringt. Die vorliegende Arbeit beschäftigt sich also mit der
Aufgabe, XForms-Programmcodes zu lesen, zu analysieren und in Java Swing auszuführen
Dies soll im Kontext des Zugriffs auf Webservices und in Form einer Bibliothek realisiert
werden. Aus diesen Vorgaben ergeben sich unterschiedliche Anforderungen, die festgestellt
und umgesetzt werden müssen.
2.2 Interpretation
Die Interpretation des XForms-Programmcodes bedarf zunächst seiner Analyse. Dabei ist zu
beachten, dass die reine Quellcode-Anaylse nur die Syntax des vorliegenden Dokumentes
erfassen kann. Diese kann nur vor einem semantischen Hintergrund wie intendiert behandelt
werden.
Der Programmcode eines XForms-Dokumentes ist so geschrieben, dass eine Implementierung
des W3C XForms-Standards, z.B ein XForms-fähiger Browser, nach dessen Beschreibung
eine XForms-Benutzeroberfläche darstellt und benutzbar macht. Die Informationen, die der
Browser dazu braucht, liegen dabei allerdings nicht nur im Code, sondern sind in der
Implementierung definierte Regeln, nach denen das Auftreten bestimmter lokaler Konstrukte
in einem globalen Zusammenhang gedeutet wird.
Diese Regeln, deren Gesamtheit als Semantik bezeichnet werden kann, sind in dem W3C
Standard für XForms definiert. Konkret bedeutet dies, dass der Interpreter, als ein Programm,
das eine XForms-Benutzeroberfläche darstellen will, diese Regeln bei der Codeanalyse
anwenden muss.
Die sich daraus ergebende Anforderung ist, dass zunächst ein Verständnis für die GUIBeschreibungssprache XForms entstehen muss, das die zugrundeliegenden Möglichkeiten,
Konzepte und semantische Regeln enthält. Weiterhin muss die Umgebung, in der der Code
ausgeführt werden soll, in diesem Fall Java Swing, darauf untersucht werden, welche
Abbildungsverhältnisse zwischen diesen beiden Formaten bestehen. Dazu gehört eine
Analyse der in XForms verwendbaren GUI-Elemente und der Möglichkeit ihrer Darstellung
in Java Swing. Zudem ist es erforderlich, zu prüfen, durch welche Strukturen und Abläufe in
Java Swing, die Konzepte der Verarbeitung in XForms abgebildet werden können.
Kapitel 3 beschäftigt sich in diesem Sinne mit der Beschreibung der XForms-Sprache. Die
darauf folgenden Kapitel schließlich beschreiben, ausgehend von der Verwendung von
Hilfstechnologien, die Architektur und Arbeitsweise des Interpreters, die erforderlich sind, um
die gewünschte Funktionalität in Bezug auf XForms zu bieten.
-3-
2.3 Zugriff auf Webservices
Der Kontext vor dem der Entwurf des Interpreters steht, ist der, dass er als Werkzeug
verwendet werden soll, um die Arbeit mit denjenigen Webservices zu erleichtern, die
XForms-GUIs als Zugriffsmethode verwenden. Dazu soll er als Komponente in
Anwendungen benutzbar sein. Es gilt also diesen Kontext auf seine Beschränkung und
Erweiterung in Bezug auf eine Architektur, die die reine Interpretation der XForms-GUIs
durchführt, zu prüfen. Die konkreten Anforderungen, die sich aus diesem Szenario ergeben,
sind architektonischer Art und im Entwurfsteil dokumentiert.
2.4 Architekturform Bibliothek
Die Vorgabe, den Interpreter als Bibliothek zu realisieren, hat direkte Auswirkungen auf die
Architektur. Es gibt grundsätzliche Unterschiede zwischen der Konzeption eines Programmes
als Anwendung und als Bibliothek. Die Anforderungen, die sich aus dieser Vorgabe ergeben,
sind im Entwurf, siehe Kapitel 5, beschrieben.
-4-
3. XForms
3.1 Einführung
Dieses Kapitel dient dazu, die zu interpretierende Quellsprache, also XForms vorzustellen.
Dabei werden im Sinne einer Analyse die Struktur und die Eigenschaften dieser Sprache kurz
erläutert. Diese Erläuterung ist keine komplette Einführung in XForms, insbesondere nicht in
die verwendete Syntax, sondern vielmehr eine Einordnung der im folgenden Verlauf der
Arbeit verwendeten Begriffe und Konzepte.
3.2 Einleitung
Die W3C-Technologie XForms [1] kann als Nachfolger der HTML Forms von 1993
betrachtet werden. Zu der Zeit waren diese eine sehr bedeutende Entwicklung und führten zu
vielen neuen Anwendungen, vor allem im Bereich des E-Commerce. Heutzutage sind EShops wie beispielsweise Amazon.com aus dem Internet nicht wegzudenken, dies alles
verdanken sie der Möglichkeit, über Formulare Daten des Benutzers entgegenzunehmen [2].
Jedoch sind seit der Einführung der HTML Forms viele Jahre vergangen und der Anspruch
der Benutzer sowie die technischen Anforderungen sind höher geworden. Da die HTML
Forms in ihrer Funktionalität sehr eingeschränkt sind, entstehen sehr komplexe Strukturen,
um die Lücken zu schließen. So ist es üblich, viel mit Skripten und Duplizierungen zu
arbeiten, was jedoch die Wartbarkeit der Dokumente maßgeblich verringert. Es lässt sich
feststellen, dass HTML Forms heute an ihre Grenzen stoßen und XForms entwickelt worden
ist, um sie zu ersetzen.
XForms ist aktuell in der Version XForms 1.0 (Second Edition) eine W3C Proposed Edited
Recommendation. Das Veröffentlichungsdatum ist der 6. Oktober 2005.
Seit seiner Einführung gab es reges Interesse an dieser Technologie, was zu einer großen
Anzahl von Implementierungen führte, die häufig jedoch noch im Betastadium sind.
XForms wurde so entworfen, dass es durch zeitgemäße Technologien und Konzepte Autoren
ermöglicht, die häufigsten Aufgaben auf möglichst einfache und wiederverwertbare Weise zu
erledigen. Die technologische Basis bildet dabei XML, dass heutzutage kritisch für viele
Anwendungen ist, und eine Reihe von weiteren W3C-Technologien (siehe Kapitel 2.7).
3.3 Struktur
XForms-Dokumente werden nicht in einem eigenen Dateiformat gespeichert, sondern
eingebettet. Die Einbettung kann z.B. in einer XHTML- oder SVG-Datei (Scalable Vector
Graphics) erfolgen. In dieser Arbeit wird dabei in Anlehnung an [2] stets das XHTML-Format
verwendet. Da XForms ein XML-Vokabular mit eigenem Namespace ist, müssen Tags, die zu
XForms gehören, mit einem frei definierbaren Prefix, üblicherweise xf, versehen werden.
Dies muss zunächst in der Namespace-Definition der Dateien vorgenommen werden. Weitere
Schritte zur Einbettung sind nicht nötig. Tags der Trägerformate werden in XForms je nach
-5-
Implementierung und Kontext entweder ignoriert oder berücksichtigt. Es bietet sich z.B. an,
HTML-Tags zur Formatierung, wie <br />, bei der Darstellung der Oberfläche zu
berücksichtigen.
Die Struktur des reinen XForms-Dokumentes, also ohne Beachtung der Informationen aus
dem Trägerformat, ist so beschaffen, dass Daten- und GUI-Elemente (In XForms-Controls
genannt) in zwei getrennten Blöcken deklariert werden. Der erste Block besteht aus einem
oder mehreren Model genannten Datenblöcken und wird üblicherweise im Head-Teil des
Trägerformats abgelegt. Dieser Block ist in sich geschlossen, d.h. innerhalb der einzelnen
Modelkonstrukte werden keine Fremd-Tags verarbeitet. Der zweite hingegen kann mit Tags
aus dem Trägerformat vermischt werden. Er wird üblicherweise im Body-Teil des
Trägerdokumentes gespeichert.
Komposition eines XForms-Models
In XForms werden Daten und Präsentation strikt getrennt. Die Daten werden im Model
verwaltet. Ein XForms-Dokument kann dabei mehrere Models haben. Ein Model besteht
hauptsächlich aus einer oder mehreren sogenannten Instanzen. Dies sind die eigentlichen
Träger der Daten. Sie umschließen ein gültiges XML-Dokument, also die Daten, mit denen
die GUI schließlich arbeitet. Alternativ kann eine Instanz statt eines Inhaltes auch einen
Verweis auf ein solches XML-Dokument über eine URL enthalten. Die Implementierung
muss dann dieses Dokument erst von der angegeben Quelle laden.
Neben den eigentlichen Daten kann ein Model noch sogenannte Bindings enthalten. Diese
beziehen sich auf die Instanzdaten und belegen diese zusätzlich mit Einschränkungen,
ausgedrückt durch die sogenannten Model Item Properties.
Diese Informationen schränken die Daten ein und bestimmen so letztendlich die Darstellung,
da sich die XForms-Controls auf solche Bindings beziehen können, um an Instanzdaten
gebunden zu werden.
Zudem kann ein Model noch Submission-Elemente definieren. Diese legen fest, welche
Daten, wie und wo übertragen werden sollen, wenn die Arbeit mit der Benutzeroberfläche
beendet ist.
Als letzte Art von Information kann innerhalb der Modelelemente auf eine externe XMLSchema-Datei verwiesen werden.
Der Code für den Datenteil einer rudimentären XForms-GUI könnte damit folgendermaßen
aussehen:
-6-
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms">
<head>
<xf:model>
<xf:instance xmlns="">
<person>
<fname/>
<lname/>
<age>18</age>
</person>
</xf:instance>
<xf:submission action="http://www.example.com" method="put" id="s0"/>
<xf:bind id=“mybind“ ref=“/person/lname“ required=“true()“ />
</xf:model>
</head>
<body>
.
.
.
</body>
</html>
Komposition der XForms-Control Definitionen
Im zweiten Block dürfen neben Elementen des Trägerformates in beliebiger Reihenfolge
XForms-Controls beschrieben werden. Neben diesen reinen GUI-Elementen können
zusätzlich vordefinierte Strukturen, wie eine Elementgruppe, ausgezeichnet werden.
Eine Control wird über einen XML-Knoten mit XForms-Namespace und Namen eingeleitet
und kann über zusätzliche Attribute und Kindelemente verfügen. Die wichtigsten Attribute
sind die, die das GUI-Element an Daten aus den Instanzen binden. Mit wenigen Ausnahmen
muss jedes Element über diese Datenbindung verfügen. Es gibt Attribute, die die Bindung
über einen XPath-Ausdruck (siehe Kapitel 3.4.3) erstellen, und solche, die Daten anhand ihrer
ID identifizieren. Diese ID stammt aus den oben erwähnten Bindings. Zusätzlich kann ein
Element noch über Attribute verfügen, die es in Bezug auf seine Navigation, sein Aussehen
oder sein Verhalten weiter beschreiben.
Weiterhin können in einem Element auch Kindelemente vorhanden sein. Diese Kindelemente
können Metainformationen (Beschriftung, Tooltip etc.) über das Element enthalten, sein
Verhalten spezifizieren (Events und Actionhandler) oder controlspezifische Eigenschaften
definieren (z.B. Trennlinien innerhalb von Drop-down-Listen).
Folgendes Beispiel bezieht sich auf den oben angegebenen Datenteil und zeigt die Definition
einiger XForms-Control Elemente:
-7-
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms">
<head>
<xf:model>
.
.
.
</xf:model>
</head>
<body>
<xf:input ref="/person/fname">
<xf:label>First Name</xf:label>
</xf:input>
<xf:input ref="/person/lname">
<xf:label ref="/person/label"/>
</xf:input>
<xf:submit submission="s0">
<xf:label>Submit</xf:label>
</xf:submit>
</body>
</html>
3.4 In XForms verwendete Technologien
XForms ist ein vom W3C standardisierter XML-Dialekt zur Beschreibung und Speicherung
von Formularen und graphischen Benutzeroberflächen. Neben XML baut XForms auf
weiteren W3C Technologien auf. Da zu diesen einzelnen Technologien teilweise sehr
umfangreiche Literatur erhältlich ist, wird an dieser Stelle kein Anspruch auf Vollständigkeit
erhoben. Vielmehr dient dieses Kapitel der kurzen Erläuterung einiger der wichtigsten
verwendeten Technologien und ihrer funktionellen Einordnung in Bezug auf XForms.
3.4.1 XML
XML weist in der Informatikwelt eine ungwöhnliche Erfolgsgeschichte auf. Seit der
Einführung der eXtensible Markup Language (erweiterbare Auszeichnungssprache) wurde ihr
sehr viel Beachtung geschenkt. Ein Grund für diesen Siegeszug war sicherlich, dass XML
offene Standards bietet und so viele Open Source Projekte entstanden sind, die zur
Verbreitung beigetragen haben [11]. Heutzutage, rund 8 Jahre nach der Standardisierung
durch das W3C im Februar 1998, ist XML aufgrund seines allgegenwärtigen Einsatzes kaum
mehr wegzudenken.
-8-
XML ist eine sogenannte Metasprache, d.h. eine Sprache, um andere Sprachen zu definieren.
Dabei können beliebige Informationen hierarchisch dargestellt und definiert werden.
In XML werden Daten von Metadaten, also Informationen über die Daten ebenso getrennt
wie Inhalt und Darstellung. Hierbei lassen sich zwei Teile unterscheiden: Der Header eines
XML-Dokumentes enthält Informationen zur Behandlung des Dokumentes durch einen
Prozessor/Parser, sowie verwendete Versionen, Namensräume etc. Der Inhalt enthält die
eigentlichen XML Daten in einer Baumstruktur. XML-Dokumente sind aufgrund ihrer
textbasierten Struktur einfach portierbar und maschinenlesbar, dadurch vereinfacht XML die
Interoperabilität von Anwendungen. XML ist heutzutage eine ganze Familie von
Technologien, wie XHTML, XLink, XPointer, XPath, XForms und vielen mehr. Die aktuelle
Version ist XML 1.0.
XForms sind ein XML-Vokabular. Für die Integration bedeutet dies, dass in XFormsDokument Strukturen mit XML codiert werden. Weiterhin wird XML in XForms verwendet,
um Daten zu sammeln, zu modellieren sowie zu übertragen. XForms bieten dabei
gewissermaßen die Möglichkeit über ein Browser-Interface XML-Daten zu editieren.
Die offizielle XML Spezifikation sowie weitere Informationen finden sich unter [3]
3.4.2 XML Schema
Um XML-Dokumenten eine Struktur zu geben, versieht man sie mit Beschränkungen. Dabei
kann z.B. festgelegt werden, welche Datentypen enthalten sein dürfen oder von welcher
Kardinalität Elemente sind. Mit diesen zusätzlichen Informationen können XML-Dokumente
von Parsern validiert, also auf die Einhaltung der Beschränkungen überprüft, werden. Es gibt
zwei unterschiedliche Verfahren zur Strukturierung: Erstens die Document Type Definition
(DTD), die mit dem XML Standard eingeführt wurde, und zweitens die XML Schema
Definition Language (XML Schema), die im Mai 2001 vom W3C standardisiert wurde. XML
Schema wurde als Nachfolger der DTDs konzipiert und erweitert diese, um fehlende
Funktionalitäten wie z.B. Namespace support. DTDs haben gegenüber XML Schema viele
Nachteile. Die vorliegende Arbeit beschränkt sich deshalb auf die Validierung durch letzteres.
XML Schemata definieren die Struktur eines XML-Dokumentes. Dabei kann auf ein Set von
Standard-Datentypen zurückgegriffen oder es können eigene Datentypen benutzt werden.
XML Schemata sind selbst in XML definiert, was z.B. kontextsensitive Editierung erlaubt.
Sie können entweder im Arbeitspeicher einer Applikation abgelegt sein oder in separaten
Dateien mit der Endung xsd (XML Schema Definition) gespeichert werden.
In XForms können XML Schemata verwendet werden, um während des Parsens das
Datenmodel zu validieren. Dies kann eine serverseitige Validierung ersparen. Schemata
können für jedes Model-Element einzeln angegeben werden.
Das normative Dokument für den Einsatz von XML Schema ist unter [8] zu finden.
-9-
3.4.3 XPath
XPath ist eine sogenannte Path Language, eine Sprache, die das Navigieren in geparsten
XML-Dokumenten (DOM-Dokumente) erlaubt. Dazu verwendet es Pfadausdrücke, um in
dessen Hierarchien einzelne oder auch mehrere Knoten auszuwählen. Zusätzlich ist XPath
eine leichtgewichtige Skriptsprache, die mit Hilfe von bereitgestellten Datentypen und
Funktionen Operationen auf die so ausgewählten Knoten erlaubt. Beispielsweise kann ein
XPath-Ausdruck die Inhalte zweier Knoten addieren. XPath ist dabei um Funktionen und
Datentypen erweiterbar.
In XForms wird XPath sehr häufig verwendet. Zum einen basiert der gesamte
Datenbindungsmechanismus, also die Bindung von GUI-Elementen an Daten, auf XPath
Referenzen. Weiterhin können XPath-Standardfunktionen und andere in der XFormsSpezifikation definierte XPath Funktionen verwendet werden, um beispielsweise den Zustand
eines Elementes zu berechnen. Besondere Bedeutung liegt dabei auf der durch XForms
definierten Zusatzfunktion „instance“, die die Dateninstanz addressiert. Absolute Pfade sind
damit in XForms abhängig von der Instanz zu deuten und beziehen sich nicht wie üblich auf
das gesamte Dokument.
Die aktuelle Version von XPath ist Version 1.0, die vom 16. November 1999 stammt. Weitere
Informationen sind unter [9] zu finden.
3.4.4 Weitere Technologien
Zusätzlich zu den oben genannte Kerntechnologien, gibt es noch eine Reihe weiterer
Technologien, die zusammen mit XForms benutzt werden können. So bietet XForms, obwohl
es den Bedarf an eigenen Skripten durch Einführung der Actionhandler gesenkt hat, die
Möglichkeit, einen Code in Skriptsprachen wie Javascript zu integrieren.
Zudem wird es ermöglicht XForms-GUIs mit Hilfe der CSS (Cascading Style Sheets)
Technologie, die vor allem für Layouts von HTML Seiten genutzt wird, zu formatieren.
3.5 Detailsicht auf XForms-Konzepte
Die XForms-Technologie zeichnet sich durch einige besondere Merkmale und Konzepte aus,
die hier kurz dargestellt werden sollen. Dabei wird keine detallierten Funktionsübersicht
geboten, sondern vielmehr eine kurze Einführung in die Begriffe durchgeführt. Auf die
Funktionen wird dann in weiteren Kapiteln genauer eingegangen.
Ablauf und Submission
XForms-Benutzeroberflächen sind für den Einsatz als Formulare konzipiert. Daraus
resultierend ergibt sich ein Ablauf, der mit dem Aufbau der GUI durch den XForms-Prozessor
- 10 -
beginnt, anschließend eine Arbeitsphase des Benutzers mit der GUI vorsieht, diese dann
durch Übertragen der eingebenenen Daten, der Submission beendet und schließlich die
Auswirkungen der Submission auf die GUI behandelt. Die Art der Submission wird vom
Autor des XForms-Dokumentes spezifiziert. Dabei ist es möglich, sich der HTTP Standard
Protokolle wie PUT und GET zu bedienen. Nach einer Submission muss die Arbeit mit der
GUI nicht zwangsläufig beendet sein. Es ist vielmehr möglich, Zwischenergebnisse zu
übertragen und diese vom Web Server auswerten zu lassen. Der Web Server kann die so
verarbeiteten Daten zurücksenden. Diese können dann die weitere Arbeit mit der GUI
beeinflussen, indem sie beispielsweise Teile der bestehenden Daten ersetzen und damit
Zustände von Controls ändern. Zudem besitzt XForms durch diesen Mechanismus eine
Suspend und Resume Unterstützung. Das bedeutet, dass einmal eingegebene und per Submit
übertragene Daten nach einer Unterbrechung der Arbeit mit der GUI wieder verfügbar sind,
der Benutzer muss diese nicht erneut eingeben. Diese Funktion ist eine der größten
Verbesserungen gegenüber den HTML Forms.
Trennung von Funktion und Aussehen
XForms ist so konzipiert, dass Daten und das Aussehen voneinander entkoppelt sind. Nicht
nur sind die Daten, wie oben beschrieben, innerhalb des XForms-Dokumentes von der
Beschreibung der GUI getrennt, sondern auch die Definition von Controls von ihrem
tatsächlichen Erscheinungsbild. Es geht daher nicht darum zu definieren, wie ein GUIElement genau aussieht, sondern welche Funktionalität es erfüllt. Die XFormsImplementierungen müssen also eine eigene Darstellungsweise für die Elemente umsetzen.
XForms liefert dabei eine Reihe von Standardelementen, die ohne weiteren Aufwand benutzt
werden können. Diese werden in Kapitel 4.3 näher beschrieben.
Die funktionsorientierte Sichtweise bezieht sich auf die Beschaffenheit einzelner Elemente.
Grundsätzlich ist aber auch ihre Anordnung auf der Benutzeroberfläche vom jeweiligen
XForms-Prozessor abhängig.
Beides kann jedoch durch den Einsatz der CSS-Technologie beeinflusst werden.
Datenbindung
Da Daten, Aussehen und Logik voneinander getrennt sind, muss es einen Mechanismus
geben, diese miteinander in Verbindung zu bringen. Dazu gibt es in XForms zwei
Möglichkeiten, entweder die Verwendung von IDREFs, also Referenzen auf IDs von BindElementen in den Models, und absoluten oder relativen XPath Pfaden. Die Verwendung von
IDREFs soll dabei favorisiert werden, da sie im Bezug auf die Wartbarkeit eines XFormsDokumentes Vorteile bietet [5]. Bindings verknüpfen Daten mit Einschränkungen, die Model
Item Properties genannt werden. Den einzelnen Knoten darf jeweils nur ein Binding
zugeordnet werden. Die übrigen werden ignoriert.
Model Item Properties dienen dazu, einzelne Datenknoten der Models zu verfeinern. So kann
z.B. mit der Eigenschaft „required“ festgelegt werden, dass die Eingabe einer bestimmten
Information für die Gültigkeit einer XForm notwendig ist. Felder, die mit „required“ markiert
sind, müssen dann ausgefüllt werden, da sonst das Abschicken der Ergebnisdaten nicht
erfolgen kann und stattdessen mit einer Fehlermeldung reagiert werden muss. Im Folgenden
werden die dynamischen und statischen Model Item Properties in den Tabellen 1 und 2
vorgestellt:
- 11 -
Dynamische Model Item Property
Kurze Beschreibung
readonly
Klassifizierung als veränderbare /nicht
veränderbare Daten
required
Klassizifierung als optionale / für die
Weiterverarbeitung notwendige Daten
relevant
Klassizifierung als für die Darstellung
relevante / nicht relevante Daten
calculate
Berechnung der Daten durch Angabe von
Umformungsvorschiften auf Eingabedaten
constraint
Einschränkung der Daten durch zusätzliche
Bedingungen
Tabelle 1: Dynamische Model Item Properties
Statische Model Item Property
Kurze Beschreibung
type
Einschränkung der Daten durch Angabe eines
Datentyps
p3ptype
Datenformat für personenbezogene, also
sicherheitsrelevante Informationen
Tabelle 2: Statische Model Item Properties
Processing Cycle
Die Verarbeitung von eingegebenen Daten hat in XForms zwei Auslöser. Einerseits kann der
Benutzer explizit deutlich machen, dass er die Eingabe übernehmen will, indem er eine Taste
drückt. Andererseits wird die Navigation zum nächsten GUI-Element implizit als solch ein
Wunsch gewertet.
Tritt eines dieser Ereignisse ein, wird die Verarbeitung gestartet. Dabei muss der XFormsProzessor vier Phasen durchlaufen, die in ihrer Gesamtheit den Processing Cycle bilden.
Diese Phasen haben zur Aufgabe die Änderung und die damit verbundenen Konsequenzen auf
die Daten zu übertragen, also die Knoten des betreffenden Instanzdokumentes zu
aktualisieren. Die einzelnen Phasen des Processing Cycles sind im Detail in Kapitel 5.5.1
beschrieben.
Events und Eventhandler
Einer der Hauptgründe für den Bedarf nach einem Nachfolger der HTML Forms war, dass der
Scriptingbedarf zu groß geworden ist. Dies schränkte die Wartbarkeit und Übertragbarkeit
von so konstruierten Formularen sehr ein. Bei XForms hat man sich daher zum Ziel gesetzt,
diejenigen Funktionen, die in der Praxis am häufigsten durch Skripte implementiert wurden,
zu standardisieren und dem XForms-Autor zur Verfügung zu stellen. Diese Funktionen sind
in einem Event-Modell verankert und stellen die Eventhandler oder XForms-Actions dar.
- 12 -
Die Spezifikation sieht vor, dass sowohl die Models als auch die einzelnen Controls auf das
Eintreten von Events warten und diese durch eine oder mehere Actions behandelt können. Es
existieren verschiedene Arten von Events, die unterschiedliche Auslöser haben. Diese können
vom XForms-Prozessor selbst (z.B. Benachrichtigung über die Fertigstellung der
Modelinitialisierung), von Controls (z.B. Benachrichtigung darüber, dass ein GUI-Element
ausgewählt wurde) oder vom Autor durch Definition an bestimmten Stellen ausgelöst werden.
Hierbei ist besonders wichtig, dass ein XForms-Prozessor die Aufgabe hat, einige Events
unabhängig vom darzustellenden Dokument zu behandeln. So wird beispielsweise der
Processing Cycle automatisch durchlaufen, wenn entsprechende Events aufttreten. Die
Eventhandler die der Autor verwendet, sind also nur zusätzliche Informationen zur Arbeit mit
der GUI und stellen nicht die komplette Logik dar.
Geräteunabhängigkeit
XForms ist so konzipiert, dass ein XForms-Dokument ohne Anpassungen auf einer Vielzahl
von Geräten dargestellt werden kann. Dazu gehören neben dem PC, Handhelds und
Mobiltelefone. Die Darstellung wird dabei der jeweiligen XForms Implementierung
überlassen. So kann z.B. auf kleinen Geräten ein GUI-Element kompakter dargestellt werden
als auf einem PC. Die Art der gewünschten Darstellung lässt sich jedoch zusätzlich über
einige Attribute innerhalb der Control-Deklarationen beeinflussen.
Clientseitige Validierung
Einer der großen Vorteile von XForms gegenüber seinem Vorgänger HTML Forms ist die
Möglichkeit der clientseitigen Validierung. Dies bedeutet, dass ein XForms Client die
eingegebenen Daten selbst auf definierte Datentypen und Integritätsbedingungen überprüfen
kann. Dadurch entfallen die sogenannten Server Roundtrips, also das Senden der Daten an
den Server zur Validierung, das Warten auf eine Antwort und das erneute Senden von neuen
Daten, solange bis die Arbeit mit der GUI beendet ist.
Datentypen können auf zwei verschiedene Weisen vom Autor festgelegt werden. Neben der
weiter oben beschriebenen Model Item Property type innerhalb von Bindings, kann auch ein
XML Schema diese Informationen enthalten. Diese statische Definition von Datentypen und
Integritätsbedingungen mittels XML Schema wird üblicherweise in einer externen Datei
deklariert. Die Validierung ist als eigene Phase, Teil des oben beschriebenen Processing
Cycle. Sie wird also nach jeder Datenänderung durchgeführt.
- 13 -
4. Realisierungskonzept
4.1 Einführung
Die Realisierung der Interpreter-Bibliothek muss sich an den im vergangenen Kapitel
erwähnten Eigenschaften von XForms orientieren. Dabei ist abzuwägen, welche
Funktionalität im Rahmen des Zugriffs auf Web Services benötigt wird. Das Ziel ist also
nicht, eine vollständige XForms-Implementierung im Sinne der W3C Recommandation zu
machen. Dies ist im Rahmen einer Bachelorarbeit aufgrund des Umfangs nicht möglich.
Vielmehr muss ein Konzept erarbeitet werden, dass die Grundfunktionalität der bearbeiteten
XForms-GUIs nach dem Interpretieren garantiert und zudem auf die Eigenschaften der
Zielsprache Java Swing eingeht. Das folgende Kapitel beschäftigt sich mit einem solchen
Konzept.
4.2 Realisierungsaspekte
Die Aufgabe in der vorliegenden Arbeit beschränkt sich nicht darauf eine Repräsentation der
im XForms-Dokument definierten Benutzeroberfläche in Java Swing zu erstellen, sondern
soll auch die zugrundeliegende Arbeit eines XForms-Prozessors simulieren. Konkret bedeutet
dies, dass die erstellte GUI, wie in XForms, als ein Formular behandelt werden muss, das
Daten sammelt und nach der Bearbeitung abschickt. Ohne dieses Konzept wäre eine
Kommunikation mit dem Web Service nicht möglich. Hierbei ist der Vorgang der Submission
von Bedeutung.
Für den Vorgang der Interpretation bedeutet dies, dass die Arbeit des Interpreters aus zwei
Hauptphasen besteht, einerseits der Transformation des XForms-Dokumentes in eine JavaGUI und andererseits die Arbeit mit der GUI. Die erste Phase sollte aus dem Parsing, der
Analyse und der Synthese des XForms-Codes bestehen. Die zweite aus der Arbeit mit der
GUI und der Submisson.
Weiterhin muss das Eventing in XForms implementiert werden, da viele Möglichkeiten auf
dem Einsatz von Events basieren. Dabei ist es vorteilhaft, dass auch in Java Swing das
Konzept von Events vorhanden ist und so nicht alle Arten von Events modelliert werden
müssen. Gleichzeitig lassen sich nicht alle exakt durch die gegebenen Java Swing Events
abbilden, so dass es eines weiteren Mechanismus bedarf, der sich nicht direkt auf die
vorhandenen Java Strukturen stützt. Zudem ist das Konzept der Eventhandler, der XFormsActions, nachzubilden.
Die Geräteunabhängigkeit der XForms-Dokumente braucht hingegen nicht beachtet zu
werden, da der Einsatz auf einem PC fest vorgegeben ist. Insbesondere können deshalb
Attribute, die sich auf den Einsatz auf anderen Geräten beziehen, ignoriert werden. Vielmehr
gilt es, jeder XForms-Control ein festes Äquivalent in Java Swing zuzuweisen.
Der Processing Cycle ist ein mächtiges Konzept, um Datenänderungen zu verfolgen und ihre
Auswirkungen zu erfassen. Innerhalb der Abarbeitung wird zudem die Validierung
vorgenommen, eine Funktionalität, die XForms deutlich von seinem Vorgänger unterscheidet.
Dieser Mechanismus muss wegen seiner Wichtigkeit in die Implementierung eingehen. Dabei
- 14 -
ist es von Vorteil, ihn möglichst nah an die vorgesehene Art anzugleichen, da ein XFormsDokument sich direkt auf diese Art der Verarbeitung beziehen kann.
Aufgrund des Umfangs der Funktionen, Elemente und Attribute der XForms-Sprache muss
bei der Implementierung die Priorität auf Basisfunktionen und -elemente gelegt werden.
Definitionen in XForms-Dokumenten, die sich auf den Komfort der Benutzung der
Benutzeroberfläche beziehen (beispielsweise das Attribut navindex, welches die Reihenfolge
der Navigation festlegt), werden dabei als unwesentlich klassifiziert, da sie keinen Einfluss
auf die Funktionalität nehmen. Die Usability einer Benutzeroberfläche hat jedoch großen
Einfluss auf die Qualität der Arbeit mit ihr und darf deshalb nicht komplett vernachlässigt
werden. Vielmehr sollte der Entwurf den Einsatz dieser Funktionen vorsehen und ein
Grundgerüst für deren Verarbeitung bieten. Der Fokus ist dabei auf eine einfache Erweiterung
der Implementierung zu legen.
Bei der Interpretation einer Sprache spielen Fehlererkennung und -korrektur eine große Rolle.
Es ist abzuwägen welche Arten der Kontrolle nötig sind.
Die zu interpretierenden XForms-Dokumente kommen von Web Services, die sie für die
Kommunikation verwenden. Es ist also für die Implementierung anzunehmen, dass sie, was
die Syntax anbetrifft, fehlerfrei sind. Dies hat große Auswirkungen auf die Art der
Fehlererkennung innerhalb der Bibliothek. Sind trotz des Szenarios Fehler im Dokument
enthalten, führen sie zu einem Fehlverhalten oder Abbruch der Bearbeitung. Diese Fehler
können nicht von der Applikation aufgefangen werden. Ein möglicher Fehler dieser Kategorie
ist ein falscher XPath-Ausdruck bei der Datenbindung, aus dem eine Java Exception
resultiert. Es wird dabei insbesondere keine dafür vorgesehene XForms-Meldung gemacht
(xforms-binding-exception), da diese lediglich den Prozessor über den Abbruch informieren
soll.
Hingegen sollten Fehler, die aus der Verarbeitung durch den Interpreter resultieren können,
eindeutige Erkennung bieten. So gilt es also eigene Exceptions zu definieren, die
beispielsweise das Vorkommen von nicht erkannten Elementen anzeigen und von der
Applikation behandelt werden können.
Die Trennung der Funktionsweise von XForms-Controls von ihrem Aussehen hat zur Folge,
dass die Anordnung der GUI-Elemente der Implementierung überlassen werden. Es ist jedoch
möglich innerhalb des XForms-Dokumentes dieses Aussehen durch den Einsatz von CSS zu
definieren. Die Anordnung der Elemente auf einer Benutzeroberfläche hat Einfluss auf die
Usability und sollte daher berücksichtigt werden. Die Verwendung von CSS ist jedoch eine
Hürde für die Implementierung dieser graphischen Eigenschaften, da der Umgang von CSS in
Java nicht natürlich unterstützt wird. Eine Möglichkeit wäre, einen CSS-Parser zu verwenden.
Dabei bliebe jedoch nichtsdestotrotz die Aufgabe, die analysierten Eigenschaften auf eine
Java Swing GUI zu übertragen. Im Rahmen dieser Arbeit ist daher der Ansatz gewählt
worden, CSS nicht zu unterstützen, jedoch einen Rahmen zu schaffen, der es ermöglicht, die
Bibliothek um diese Funktionalität nachträglich zu erweitern. Der Mechanismus der
Anordnung von Elementen auf der GUI muss dann allerdings so beschaffen sein, dass
Änderungen leicht implementiert werden können.
Die Verwendung von Elementen des Host-Formats in XForms-Dokumenten erhöht die
Komplexität des Codes, da es sich um Sprachen mit unterschiedlichen Rahmenbedingungen
handelt. Die Unterstützung von solchen Formaten kann im vorgegeben Rahmen nicht
- 15 -
vorgesehen werden, sollte jedoch so im Entwurf verankert sein, dass sie nachimplementiert
werden kann.
4.3 Vergleich von Java Swing- und XForms-User Interfaces
Die in dieser Arbeit entwickelte Bibliothek konvertiert gewissermaßen eine Art von
Benutzeroberflächen in eine andere. Dabei stellt sich natürlich die Frage, inwiefern die
einzelnen Benutzeroberflächen aufeinander abbildbar sind.
XForms, als Nachfolger der HTML Forms, kommen aus der Domäne des Internets und sind
auf diese abgestimmt. Vorrangig dienen sie dazu, Formulare darzustellen. Die Auswahl an
verschiedenen GUI-Elementen ist also auf dieses Einsatzfeld beschränkt. Nichtsdestotrotz
sind auch einige Standardelemente enthalten, die es ermöglichen, Benutzeroberflächen für
andere Zwecke zu konstruieren. Zusätzlich besteht die Möglichkeit, XForms-GUIs mit
HTML-Tags zu formatieren, da sie in solchen Dateien eingebunden sein können. Das für die
vorliegende Arbeit interessante Anwendungsgebiet von XForms ist die Benutzeroberfläche
als Schnittstelle für die menschliche Interaktion mit einem Web Service.
Java Swing hingegen ist eine Java API für die allgemeine Erstellung von Benutzeroberflächen
jedweder Art - es gibt hinsichtlich der Elemente keine Beschränkungen, da neben sehr vielen
vorhandenen Elementen auch eigene GUI-Elemente definiert werden können. Java Swing ist
daher ein sehr mächtiges Konzept, das bei der Darstellung weit über die Möglichkeiten von
XForms hinausgeht. Die in XForms definierte Menge an Elementen ist somit eine Teilmenge
der Elemente in Java Swing. Da jedoch XForms einige spezifische Mechanismen aufweist,
lässt sich nicht jedes Element einer XForms-GUI einfach auf ein Java Swing Element
abbilden. So werden beispielsweise Container für Elemente in XForms automatisch
vorgegeben, in Java Swing müssen diese durch den Programmierer explizit angegeben
werden. Ein weiteres Beispiel ist die funktionsorientierte Sicht von XForms auf die GUI: Die
Angabe von GUI-Elementen dient dem Zweck, eine bestimmte Funktion auf die darauf
gebundenen Daten auszuführen und nicht der Darstellung des GUI-Elementes. Dies wird dem
XForms-Prozessor überlassen, so dass je nach Implementierung beispielsweise eine Selektion
standardmäßig als Drop-Down-Liste oder aber als Gruppe von Radio-Buttons gerendert wird.
Die Art des Renderings kann zudem über Attribute beeinflusst werden. Dieses Konzept ist für
XForms sehr wichtig, da die Portierbarkeit darauf beruht, dass verschiedene
Implementierungen für verschiedene Geräte (PDA, Handy, PC etc.) eine angepasste Sicht
erzeugen, ohne dass an der Beschreibung der GUI etwas verändert werden muss.
Um nun eine XForms-GUI in diesem Kontext in eine Java Swing GUI umzuwandeln, muss
neben dem einfachen Mapping der Elemente an einigen Stellen das Konzept angepasst bzw.
abgeschwächt werden. Es geht also nicht darum, die mit XForms erstellten
Benutzeroberflächen in ihrer vollen Funktionalität zu replizieren, sondern sie für die
Anforderungen der verwendenden Applikation aufzubereiten.
Die folgenden Tabellen 3, 4 und 5 listen alle in XForms verwendeten GUI-Elemente mit
ihrem Java Swing Äquivalent auf und erläutern die Konvertierung an Stellen, wo das Konzept
der XForms nicht direkt übernommen werden kann.
- 16 -
Element
XForms-tag
PasswortEingabefeld
Textfeld
Ausgabefeld
Schieberegler
Knopf
Multiple
Auswahl
<secret>
Java SwingKlasse1
JPasswordField
<textarea>
<output>
<range>
<trigger>
<select>
JTextarea
JLabel
JSlider
JButton
JList
Anmerkungen
Es muss
MULTIPLE_INTERVAL_SELECTION als
Wert gesetzt sein (Default)
Tabelle 3: XForms und Java Swing Elemente: Eindeutiges Mapping
-1-
Alle hier genannten Klassen befinden sich im Java Paket: javax.swing
- 17 -
Element
Einzelne Auswahl
XForms-tag
<select1>
Java Swing-Klasse1
Anmerkungen
[12] und [13] rendern
JList oder
dieses Element als dropJRadioButton
Eingabefeld
<input>
JTextField bzw.
Nicht-Standard
Implementierung
Datei-Upload
<upload>
JFileChooser
Submit
<submit>
JButton
Verzweigungen
<switch>..<case>
JPanel
Gruppierungen
<group>
JPanel zur
Gruppierung
Wiederholungen
<repeat>
JPanel
Tabelle 4: XForms und Java Swing Elemente:Komplexes Mapping
- 18 -
down-Liste, darauf
Bezug nehmend wird es
als JList implementiert.
Dabei muss
SINGLE_SELECTION
als Wert gesetzt sein.
Ein Eingabefeld wird
meist als solches
gerendert, kann jedoch in
einigen
Implementierungen vom
Typ der daran
gebundenen Daten
abhängen. (siehe 6.4.2)
Über das angegebene
Element kann eine Datei
ausgewählt werden. Den
tatsächlichen Upload
muss jedoch die
Applikation vornehmen
Dem Submit Button wird
eine besondere
Bedeutung beigemessen,
die reine Darstellung ist
jedoch vom Typ JButton
Darstellung als einzelne
JPanel, die jeweils nur
für einen Case angezeigt
werden.
Darstellung mit JPanel
als Container für mehrere
Elemente
Darstellung der
einzelnen Elemente ist in
einem JPanel
gespeichert. Das
Besondere ist eher die
wechselnde
Datenbindung der
Elemente.
Zusätzlich existieren noch folgende Markups, die innerhalb von Elementen zwecks deren
näherer Beschreibung eingesetzt werden.
Element
Beschriftung
XForms-tag
<label>
Tooltip, Quickinfo
<hint>
Warnung
<alert>
Eingabehilfe
<help>
Tabelle 5: XForms-Markups und Java Swing Elemente:Mapping
- 19 -
Anmerkung
Durch ein JLabel in Swing
darstellbar
In Swing wird ein tooltip
durch das Attribut
toolTipText der
Elementklassen repräsentiert
In XForms ermöglicht dieses
Element, Warnungen
auszugeben, wenn die
Validierung ergeben hat, dass
ein Datensatz nicht gültig ist.
Dies kann durch einen Dialog
angezeigt werden.
Durch Drücken eines helpButtons (falls vorhanden)
bzw. beim Drücken der
Standard-Hilfe-Taste „F1“
erscheint bei XForms ein
Fenster, das dazu dient dem
Benutzer, Informationen über
die erwarteten Eingaben eines
Elementes anzuzeigen. Dies
kann durch die Benutzung
von ActionMap und
InputMap in Java
nachgebildet werden
5. Realisierung
5.1 Einführung
Das folgenden Kapitel behandelt die Realisierung des vorgestellten Konzeptes. Dazu werden
der Grob- und Feinentwurf erläutert. Dabei ist zu beachten, dass die Arbeit kein reines
Entwurfsdokument ist und nicht alle dafür üblichen Bestandteile in Gänze ausgeführt sind.
Statt der Begründung jeder einzelnen Designentscheidung sollen an dieser Stelle vielmehr die
Kernzusammenhänge und Bezüge zur XForms-Technologie erklärt werden.
Zunächst werden die Anforderungen an den Entwurf aufgeführt.
Der darauf folgende Grobentwurf stellt den Grundaufbau der Interpreter-Bibliothek vor. Die
einzelnen Komponenten entsprechen dabei logischen Einheiten und sind teils durch Klassen,
teils durch eine Gruppe von miteinander arbeitenden Klassen realisiert. Neben der
Erläuterung der einzelnen Komponenten findet sich das Rationale, eine Begründung der
getroffenen Architekturenscheidungen.
Die Details des Enwurfes werden anschließend im Feinentwurf vorgestellt. Dieser behandelt
die Klassen, die nötig sind, um die Komponenten und die wichtigsten Abläufe zu realisieren.
Der Feinentwurf wird wiederum mit einem Rationale abgeschlossen. Zuletzt wird im Detail
auf die Realisierung der einzelnen XForms-Konzepte eingegangen.
5.2 Anforderungen
Die Anforderung. den Interpreter als Bibliothek zu realisieren, hat natürlich Einfluss auf den
Entwurf. So muss der Interpreter keinen eigenen Mechanismus zur Anzeige der GUI
bereitstellen. Ebenso kann er Aufgaben an die ihn verwendende Applikation delegieren, muss
dafür jedoch Informationen über diese besitzen.
Auf der anderen Seite muss die Bibliothek so beschaffen sein, dass sie leicht zu verwenden
ist. Dafür müssen entsprechende Strukturen in der Architektur sorgen.
Da die Bibliothek für den Einsatz im Web Service Kontext verwendet werden soll, ergeben
sich weiterhin einige Besonderheiten.
Die Steuerung von Web Services aus einer Anwendung heraus impliziert die Benutzung über
einen PC. Damit wird es unnötig XForms-Features zu interpretieren, die sich auf die
Geräteunabhängigkeit beziehen. Dazu gehören beispielsweise Attribute zum bedingungsgesteuerten Layout von Controls.
Aufgrund des potentiellen Einsatzes in Service orientierten Architekturen (SOAs) ist es
notwendig die Bibliothek so zu konzipieren, dass ein Betreiben von mehreren InterpreterInstanzen problemlos funktioniert. Andernfalls wäre es nicht möglich, die einzelnen Module
einer solchen Architektur zu repräsentieren. Dem muss im Entwurf entsprochen werden.
- 20 -
5.3 Grobentwurf
Abbildung 1: Komponentenentwurf
- 21 -
5.3.1 Komponenten
Die in Abbildung 1 gezeigte Grafik stellt den Grobentwurf der Bibliothek dar. Die
verwendete Notation gruppiert logische Teile des Entwurfs.
Die hellrot markierten Komponenten symbolisieren Fremdkomponenten, die der Bibliothek
zur Verfügung gestellt werden. Die blauen hingegen stellen die Kernfunktionalität dar
(durchgezogene Linien), während die grünen Komponenten die Benutzeroberfläche darstellen
und entweder komplett von den blauen erzeugt oder aber bearbeitet werden (gestrichelte
Linien).
Der Interpreter besteht aus mehreren, nach Funktionen getrennten Einheiten. Die
Gesamtfunktionalität des Interpretierens entsteht durch ein Zusammenspiel dieser
Komponenten. Sie sind dabei voneinander gekapselt und so implementiert, dass sie durch
andere Implementierungen ausgetauscht werden können. Das folgende Kapitel beschreibt die
Aufgaben der einzelnen Komponenten im Detail.
Application
Die Application-Komponente bezeichnet die Anwendung, die die XForms-InterpreterBibliothek verwendet. Diese muss einige Funktionalität bieten, die durch eine Schnittstelle
definiert wird. Diese Funktionalität sichert die Kommunikation mit dem Director.
Director
Der Director ist die Komponente, die die gesamte Verwendung des Interpreters koordiniert.
Dazu muss er verschiedene Aufgaben erfüllen. Zum einen bietet er der Anwendung einen
Zugang (Input), um XForms-Dokumente zu verarbeiten. Weiterhin legt er fest, welche
Implementierungen die Komponenten verwenden, indem er ihnen entsprechende Instanzen
zuweist. Dabei handelt es sich sowohl um die verwendete Parsing Bilbliothek als auch um die
benötigten anderen Komponenten. Zudem leitet er die Anforderungen nach extern
gespeicherten Informationen an die Applikation weiter. Schließlich ist er dafür
verantwortlich, den Vorgang der Intepretation als Ganzes durchführen zu lassen und das
Ergebnis, also die graphische Benutzeroberfläche, der Anwendung zu übergeben.
Der Directorklasse ist die einzige Klasse, die die Instanzierung der anderen Komponenten
vornimmt und die einzige Klasse, die die Anwendung kennt. Sie verfügt über keinen eigenen
Verbindungsmechanismus, kann also keine Dokumente selbstständig über ein Netzwerk
beschaffen, sondern delegiert Anforderungen an diese Funktionalität an die Anwendung.
Separator
Das Separator-Modul hat die Aufgabe, den Prozess des Interpretierens, also der Analyse und
anschließenden Synthese, zu koordinieren.
Nachdem der Separator vom Director ein zu verarbeitendes XForms-Dokument empfangen
hat, muss er es zunächst in ein DOM-Dokument parsen. Anschließend trennt es das
Dokument nach seinen logischen Bestandteilen auf und erzeugt für jeden Teil ein neues
- 22 -
Doukument. Dabei wird das ursprüngliche Dokument als Backup beibehalten, um den
Anfangszustand wiederherstellen zu können. Im Standardfall von XHTML als Hostformat
werden Dokumente nach den mit head und body bezeichneten Teilen getrennt.
Die Hauptaufgabe besteht nun darin, die erhaltenen Teile sequentiell zur Weiterverarbeitung
an die entsprechenden Module zu geben. Im Falle des head-Dokumentes ist dies die Model
Processing-Komponente, im Falle des body-Dokumentes die Analyse-Komponente. Dabei
iteriert der Separator durch die einzelnen Elemente der Dokumente und gibt sie zur Analyse
frei. Nach der Analyse verwendet der Separator die Ergebnisse, um sie wieder sequentiell zur
Verarbeitung der Synthese-Komponente zu übergeben.
Zudem hat der Separator die Aufgabe, zusätzliche globale Dokumentinformationen (Titel
etc.), die vom Hostformat kommen, zu erkennen und Methoden zur Verarbeitung oder
Delegation bereitzustellen.
Die Separatorkomponente ist so gekapselt, dass sie weder die Implementierungsdetails der
einzelnen Komponenten noch des Parsers kennt. Alle Komponente werden ihr vom Director
zugewiesen. Der Separator ist lediglich für die Koordination der Komponenten zuständig.
Model Processing
Die Model Processing-Komponente hat die Aufgabe, das Datengerüst des XFormsDokumentes zu analysieren und in eine Form zu bringen, die sich besser für die
Weiterverarbeitung eignet.
Die Model Processing-Komponente arbeitet auf einzelnen Model-DOM-Knoten, die sie vom
Separator zugewiesen bekommt. Diese Knoten werden nach ihren logischen Bestandteilen
analysiert. Ein Model in XForms besteht, wie in Kapitel 2.2 beschrieben, aus Dateninstanzen,
Bindinginformationen, Actionhandlern und Submission-Elemente. Für diese verschiedenen
Arten von Informationen stellt die Model Processing-Komponente jeweils spezialisierte
Methoden zur Verfügung, die die Daten analysieren, in Verbindung zueinander bringen und
in besonderen Klassen speichern. Die so enstandenen einzelnen Modelinstanzen bilden das
Gesamtdatenmodell, welches der weiter unten beschriebene Model-Komponente entspricht.
Die Model Processing-Komponente ist so gekapselt, dass sie auf DOM-Dokumenten arbeitet,
jedoch die Implementierungsdetails nicht kennt, sondern die benötigten Klassen, indirekt über
den Separator, vom Director zugewiesen bekommt.
Analysis
Die Analysis-Komponente hat die Aufgabe, in XForms kodierte GUI-Elemente zu analysieren
und die Informationen in Containern abzulegen, die alle Informationen über diese Elemente
speichern. Diese dienen dann als Grundlage für die Erzeugung der View- und ControllerKomponenten durch die Synthese-Komponente.
Die Analyse bekommt vom Separator jeweils einzelne DOM-Knoten übergeben, die einem
GUI-Element, einer GUI-Struktur (siehe Kapitel 4.3) oder einem Element des Host-Formats
entsprechen. Sie nimmt zunächst eine Klassifizierung des Elementes vor und analysiert dann
das Element über eine passende Methode.
- 23 -
Im Verlauf der Analyse werden Informationen über die einzelnen GUI-Elemente in
Containern zusammengetragen. Die Kernaufgabe der Analyse besteht dabei darin, die GUIElemente mit den durch das Model-Processing entstandenen Daten zu binden und getrennt
definierte Eigenschaften in jeweils einer Klasse zu bündeln.
Die so enstandenen Container sind eine abstrakte Repräsentation der in XForms definierten
Elemente und dienen neben der Weiterverarbeitung durch die Syntese-Komponente auch der
Zustandsmodellierung während des Betriebes der Benutzeroberfläche.
Die Analyse speichert die erzeugten Container in einer Datenstruktur, die am Ende der
Gesamtanalyse vom Separator abgerufen und sequentiell zur Synthese freigegeben wird.
Die Analyse-Komponente arbeitet mit den in DOM-Struktur vorliegenden Daten und wandelt
sie in ein leichter zu verarbeitendes Format um. Alle folgenden Komponenten benutzen statt
der DOM-Repräsentation das Container-Format. Damit ist die Analyse eine wichtige
Verbindung zwischen den zwei Abstraktionsebenen XForms/XML und Java.
Synthesis
Die Synthesis-Komponente dient der Erzeugung von Java GUI-Elementen, die den durch die
Analyse erzeugten Containern entsprechen. Zudem nimmt sie ihre Registrierung bei den
verbliebenen Bestandteilen der GUI, der View und dem Controller, vor.
Die Synthese wird sequentiell mit den Ergebnissen der vorangegangenen Analyse aufgerufen,
behandelt also jeweils einen Container. Zunächst wird das abstrakte GUI-Element klassifiziert
und die zugehörige Methode aufgerufen. Die Methoden haben die Aufgabe, die benötigten
Java-Elemente zu erzeugen. Diese werden dem Container zugeordnet und anschließend der
View zur Darstellung übergeben. Die weitere Behandlung geht auf das spezifierte Verhalten
der Container ein, also die Logik, die in der Benutzeroberfläche erforderlich ist. Dazu wird
der Container auf entsprechende Weise bei dem Controller registriert.
Die Synthese ist so aufgebaut, dass sie Assoziationen zur View und dem Controller besitzt.
Dabei handelt es sich wiederum um Interfaces, so dass die Synthese selbst die genaue
Implementierung der benötigten Bestandteile nicht kennt. Stattdesssen werden ihr die
konkreten Klassen über den Separator vom Director zugewiesen.
Models
Die Komponente Models besteht aus den einzelnen Modelinstanzen, die durch die Model
Processing-Komponente erzeugt werden. Sie ist Teil der interpretierten Benutzeroberfläche.
Die Model-Komponente ist die Datenbasis der GUI. Änderungen, die der Benutzer durch
seine Aktionen auslöst, schlagen sich hier nieder. Dabei implementieren die einzelnen Models
die Funktionaliät, die vom Controller und der View benötigt werden. Da die Models alle
eingegeben Daten verwalten spielen sie eine zentrale Rolle bei der Submission. Sie
repräsentieren dabei die Ergebnisse der Arbeit mit der erzeugten Benutzeroberfläche.
- 24 -
Der Komponente Models ist keine eigene Klasse zugeordnet, vielmehr besteht sie aus einer
Datenstruktur mit mehreren Modelinstanzen, die von den einzelnen Komponenten verwendet
wird.
View
Die View-Komponente enthält die sichtbaren Bestandteile der erzeugten Benutzeroberfläche.
Sie bietet zudem Methoden, um neue Komponenten einzufügen und visuell zu spezifizieren.
Dazu setzt sie zuvor analysierte Layout-Eigenschaften um und erzeugt die Benutzeroberfläche, die dann in der Anwendung integriert werden kann.
Controller
Der Controller ist die zentrale Komponente bei der Ereignisverarbeitung. Er übernimmt zwei
Aufgaben:
Die erste Aufgabe besteht darin, Events die XFControls betreffen, zu registrieren (Rolle des
Observers) und für jedes Element die entsprechende Aktion auszulösen.
Hierbei ist zu erwähnen, dass es sich um eine abstrakte Event-Verarbeitung handelt, die sich
auf das Behandeln von Events in XForms bezieht und sich von der reinen Listener-Tätigkeit
im Model-View-Controller Paradigma abgrenzt. Auf diese Aufgabe wird in Kapitel 5.5.2
eingegangen.
Die zweite Aufgabe ist es, diese Funktion des Controllers auszuführen, wenn auch in einem
sehr begrenzten Kontext. Dies lässt sich am besten als verzögerte Benachrichtigung
beschreiben und ergibt sich wie folgt:
Die Änderung des Zustandes einer XForms-Control erfordert eine Reihe von Aktionen, die in
ihrer Gesamtheit als Processing Cycle bezeichnet werden. Diese Aktionen ermitteln die
Auswirkungen der Änderungen auf Daten, auf andere Elemente und auf den Zustand der GUI
und setzen sie um. Dieses zweite Aufgabe des Controllers wird in Kapitel 5.5.1 detailliert
beschrieben.
5.3.2 Verwendete Bibliotheken
Xerces
Bei Xerces [10] handelt es sich um eine XML Parsing Bibliothek, die Teil des Apache
Projektes ist. Die hier verwendete Version ist: Xerces2 Java Parser 2.7.1.
Xerces zeichnet sich dadurch aus, dass es ein Open Source Projekt ist und eine große Fülle
von Standards implementiert. So bietet er die für den Interpreter zwingend benötigte
Unterstützung für das Document Object Model (DOM) inklusive der Traversal
Implementierung und der XML Schema Validierung. Weiterhin bietet er die Unterstützung
von Namespaces und die Fähigkeit der Serialisierung.
- 25 -
Die Bibliothek wird nur innerhalb der Director-Komponente importiert. Der Director hat also
als einzige Klasse den Zugriff auf die konkreten Klassen des Parsers. Alle anderen Klassen
benutzen intern nur die im Java Package „org.w3c.dom“ definierten Interfaces, denen durch
den Director die benötigten Parser-Klassen zugeordnet werden.
Jaxen
Jaxen [15] ist eine Bibliothek, die eine XPath Engine zur Verfügung stellt und unter anderem
auf dem hier verwendeten DOM arbeitet. Jaxen steht dabei wie Xerces unter Open Source
Lizenz. Da in XForms beispielsweise das gesamte Binding der GUI-Elemente zu den Daten
über Xpath-Binding-Expressions realisiert ist, ist der Einsatz einer solchen Bibliothek
dringend angeraten.
Im Gegensatz zu der Xerces Bibliothek ist der Einsatz von Jaxen in jeder Komponente direkt
gegeben. Jede Komponente die Zugriff auf XPath-Funktionalitäten benötigt, verwendet die
Implementierung der Bibliothek selbst.
5.3.3 Packages
Die verschiedenen Komponenten und ihre zugehörigen Klassen sind in mehrere Packages
aufgeteilt. Packages kapseln Klassen mit gleichem Kontext. Der in der vorliegenden Arbeit
entwickelte XForms-Interpreter ist dabei in folgende Packages aufgeteilt:
xfInterpreter.core:
Die Interfaces der Komponenten Separator, Model Processing, Analysis und Synthesis und
ihre jeweiligen Standardimplementierungen. Außerdem noch die Director-Komponente und
das Interface der Application.
xfInterpreter.behaviour.actions:
Container für XForms-Actions
xfInterpreter.behaviour.events:
Container für XForms-Events
xfInterpreter.controls:
Container für die GUI-Elemente
xfInterpreter.gui:
Die GUI-Komponenten Model, View und Controller
xfInterpreter.util:
Verschiedene Klassen, die häufig verwendet werden. Dazu zählen unter anderem die DatenContainer, aber auch die Exception-Klassen.
- 26 -
5.3.4 Rationale für Grobentwurf
Der Grobentwurf in seiner jetzigen Form ist ein Resultat aus der Abwägung einzelner
Designentscheidungen zur Erreichung der verlangten Merkmale. Beim Softwareentwurf ist es
oftmals so, dass es keinen idealen Weg gibt, etwas zu realisieren. Die Betonung eines
Qualtätsaspektes kann negative Auswirkungen auf die Erreichung eines anderen haben. An
dieser Stelle werden die Kernentscheidungen, die schließlich zu dem oben dargestellten
Entwurf geführt haben, mit ihren Vor- und Nachteilen diskutiert.
Wahl der zusätzlichen Bibliotheken
Die Tatsache, dass XForms ein XML-Dialekt ist, der viele XML-Techniken verwendet, legt
nahe, ein XForms-Dokument durch einen XML-Parser [7] verarbeiten zu lassen. Dies hat den
großen Vorteil, dass sowohl die lexikale Analsye (Erkennung einzelner Token) als auch die
syntaktische Analyse, die man auch als Parsing bezeichnet (Überprüfung der Syntax der
aufgetretenen Token), automatisch durchgeführt wird. Durch den Einsatz einer solchen
Komponente entfällt sehr viel Arbeit. Zudem treten beim Parsing von XForms durch einen
XML-Parser keine unerwarteten Ergebnisse auf, da es ein gültiges XML Vokabular ist.
Die Benutzung der zweiten Fremd-Komponente, der XPath-Bibliothek Jaxen, hat das gleiche
Ziel, nämlich eine Funktionalität auszuführen, die bereits durch etablierte Projekte
implementiert ist und keinen großen Aufwand erzeugt. Da in XForms sehr viel mit XPath
Ausdrücken gearbeitet wird, zudem an Stellen, die kritische für die Benutzeroberfläche sind
(z.B. Bindung von GUI-Elementen an Daten), ist es angeraten eine solche Bibliothek zu
verwenden.
Parserwahl
Die Entscheidung, einen XML-Parser in Java zu verwenden, impliziert die Auswahl einer
solchen Komponente, da Java selbst nur ein Framework definiert. Es gibt dabei eine Vielzahl
an unterschiedlichen Implementierungen, die zusätzliche Funktionen haben oder in
besonderer Weise optimiert sind. Ebenso gibt es von Sun eine JAXP (Java API for XML
Processing) genannte Schnittstelle, die unter anderem den Parserwechsel erheblich
vereinfacht.
Obwohl diese ganzen Funktionen und Möglichkeiten der Parser für sich genommen
beeindruckend sind, sind die Anforderungen des hier entwickelten Interpreters an einen
XML-Parser viel zu gering, als dass eine allzu differenzierte Wahl nach funktionellen und
qualitativen Eigenschaften berechtigt wäre. Der Einsatz des Parsers innerhalb des Interpreters
beschränkt sich im Grunde darauf, ein bereitgestelltes XForms-Dokument bei der Beachtung
von XML Schemata und Namespaces zu parsen. Anschließend müssen noch einige wenige
Operationen auf dem erzeugten Datenmodel durchgeführt werden und die Ergebnisse nach
Abschluss der Arbeit mit der interpretierten GUI in XML-Dateien serialisiert werden. Diese
Funktionen bringt fast jeder verfügbare XML-Parser mit sich.
Letztlich ist die Entscheidung gefallen, Xerces als Parser zu wählen. Erstens ist er Teil eines
renommierten Projektes, des Apache Projects, was zur Folge hat, dass er qualitativ hochwertig
ist und beständig weiter entwickelt und verbessert wird. Zweitens steht er unter einer wenig
restriktiven Open Source Lizenz, die es ermöglicht, den Parser für persönliche, firmeninterne
und sogar kommerzielle Projekte zu nutzen. Drittens bietet er die gewünschte Funktionalität
und kann gleichzeitig eine Fülle von anderen XML verwandten Technologien verarbeiten,
- 27 -
was zwar bei dem derzeitigen Zustand des Interpreters keinerlei Vorteile bringt, jedoch in
Bezug auf Erweiterungen der Bibliothek und der zukünftigen Entwicklung des XML
Standards nützlich sein kann.
Die Idee der Verwendung des JAXP Frameworks im Zusammenhang mit dem Parser wurde
für diese Arbeit nach reichlicher Überlegung verworfen. Dies hat den Grund, dass zwar
generell der Parserwechsel durch den Einsatz von JAXP vereinfacht werden kann, dies aber in
diesem Kontext aufgrund des Code-Overheads mehr Nachteile als Vorteile mit sich bringt.
Stattdessen wurde das Prinzip des Information Hiding verwendet, indem die Referenz auf die
tatsächliche Parser-Implementierung nur innerhalb der Director-Komponente existiert, andere
Klassen dagegen nur mit Interfaces arbeiten. Dies bewirkt gleichsam den einfachen
Parserwechsel ohne jedoch wie bei vorigem Ansatz die Komplexität der Parserverwendung zu
erhöhen.
Parserverwendung und Datenmodel
Bei der Verwendung des Parsers muss darauf geachtet werden, dass die ParserImplementierung gekapselt verwendet wird, also nicht viele Klassen direkten Zugriff auf die
Parserklassen haben. Dies hat den Grund, dass sich Implementierungsdetails ändern können
und die Gültigkeit der benutzten Methoden nicht garantiert werden kann. So empfiehlt die
API-Dokumentation des Xerces-Parsers die Verwendung der in Java definierten W3C
Standard-Interfaces, wo immer dies möglich ist, da die Verwendung einzelner Klassen
offiziell nicht unterstützt wird*. Zudem kann bei Erweiterungen der Bibliothek der Bedarf
nach einer anderen Implementierung auftreten. Ein Wechsel sollte deshalb so leicht wie
möglich durchführbar sein.
Bei Beachtung dieser Kriterien empfiehlt es sich, die Kenntnis der Implementierungen nur in
der Director-Klasse zu programmieren und die anderen Klassen mit Interfaces arbeiten zu
lassen. Im Falle der Notwendigkeit eines Parser-Wechsels, muss dann lediglich die DirectorKlasse angepasst werden. Es ensteht also eine sehr schwache Implementierungsabhängigkeit,
vor allem, weil durch Benutzung der Standard-Interfaces ausgeschlossen werden kann, dass
individuelle, vom Parser abhängige und in anderen Implementierungen nicht vorhandene
Funktionen, in Anspruch genommen werden.
Beim Parsen ist weiterhin das verwendete Datenmodell von großer Bedeutung. XML definiert
zwei standardisierte APIs zur Verarbeitung von Daten. Dies sind SAX (Simple API dor
XML) und DOM (Document Object Model). Für die Verwendung von XML in der
vorliegenden Arbeit kommt dabei nur die DOM-API in Betracht, da SAX lediglich eine
sequentielle Verarbeitung auf Basis von Ereignissen gestattet. Dies wird der Analyse des
XForms-Codes nicht gerecht. DOM hingegen erzeugt ein Modell des Dokumentes im
Speicher, auf das im Anschluss bequem zugegriffen werden kann.
Verwendung der XPath Library Jaxen
Im Gegensatz zu der Parser Bibliothek haben alle Komponenten direkten Zugriff auf die
XPath-Library, es wird also nicht mit Interfaces gearbeitet. Der Vorteil ist, dass alle Klassen
ledglich die entsprechenden Implementierungs-Klassen importieren müssen, um sie zu
verwenden. Es muss also nichts vom Director übergeben werden, was den Code weniger
komplex macht. Ein Nachteil an dieser Art der Architektur ist, dass eine Änderung der
*
„Usage of this class is not supported. It may be altered or removed at any time.“ Siehe z.B.
http://xerces.apache.org/xerces2-j/javadocs/xerces2/index.html
- 28 -
Bibliothek (z.B. Upgrade auf neue Version) zur Folge haben kann, dass die Klassen in allen
verwendeten Komponenten ausgetauscht werden müssen, statt wie beim Parser lediglich im
Director.
Der Grund für die Entscheidung trotzdem diese Art des Designs zu wählen, liegt darin, dass
es keine Interfaces für eine XPath-Factory in der Java-Spezifikation gibt. Eine Factory wäre
aber nötig, um neue Instanzen für die Erstellung von XPath-Ausdrücken zu erhalten. Die
Implementierung einer solchen XPath-Factory wäre also abhängig von der verwendeten
Bibliothek.
Da der Bedarf an einem Wechsel der XPath-Bibliothek, auch aus Mangel an Alternativen, als
gering eingeschätzt wird, sind die Konsequenzen dieser Enscheidung hinnehmbar.
Zentralismus
Der zentrale Einsatz der Director-Komponente ist eine Architekturentscheidung, die
kontrovers bewertet werden kann.
Der Grobentwurf beschreibt den Director als eine Komponente, die alle Informationen über
die anderen Komponente in sich bündelt und zusätzlich mit der Anwendung kommuniziert.
Dieses Design hat den Zweck, die in der Aufgeabenstellung geforderte einfache
Benutzbarkeit und Wartbarkeit der Bibliothek zu gewährleisten. Die Director-Komponente
sorgt für leichte Verwendbarkeit, indem sie sicherstellt, dass für einen reibungslosen Betrieb
tatsächlich nur eine Instanz dieser Klasse benötigt wird. Sie sorgt selbst für die Initialisierung
aller anderen Komponenten und die Koordination der Phasen des Interpretationsprozesses und
-betriebes der erzeugten GUI. Zudem ist die derart gestaltete Verwendung leicht skalierbar, da
mehrere Director-Komponenten nebeneinander arbeiten können und so Zugriff auf mehrere
Web Services gleichzeitig bieten können. Durch die Verwendung des Directors entfällt also
die Verantwortung des Benutzers und der einbindenden Applikation, für das Zusammenspiel
der Komponenten zu sorgen.
Nachteilig ist, dass der Zugriff auf die Funktionalität für die Benutzung der Director-Klasse
optimiert ist. Die separate Verwendung einzelner Klassen erfordert das Beachten von
Implementierungsdetails und wird erschwert.
Applikation als Schnittstelle
Die Anforderungen der Aufgabenstellung den Interpreter als Bibliothek zu realisieren, hat
Konsequenzen für andere Designentscheidungen.
Im Gegensatz zu einer Stand-alone Anwendung ist eine Bibliothek auf externe Resultate
angewiesen. Der Entwurf ist so konzipiert, dass für die Benutzung der Bibliothek eine
Anwendung benötigt wird, die auf Web Server und Ressourcen zugreifen kann. Dies hat den
Grund, dass eine Anwendung, die den Zugriff auf Web Services bündeln und koordinieren
will und zu diesem Zweck die Interpreter Bibliothek einbindet, ohnehin einen
Kommunikationsmechanismus implementieren muss, um z.B. Web Services ausfinding zu
machen und zu validieren, ob die verwendete Zugriffstechnologie tatsächlich XForms ist.
Eine solche Funktionalität über die Bibliothek bereitzustellen, wäre also überflüssig. Wäre die
Bibliothek auf die Anwendung dieses hypothetischen eigenen Mechanismus angewiesen,
wäre es in diesem Fall für die Anwendung sogar kontraproduktiv.
- 29 -
Der Director wurde daher so konzipiert, dass er Netzwerkaufgaben an die Applikation
delegiert. Sie ist deshalb als Schnittstelle modelliert, die Methoden definiert, auf die der
Director sich beziehen kann. Ein Anwendungsszenario ist z.B. dadurch gegeben, dass die
Model Processing-Komponente bei der Analyse einer Dateninstanz anstelle eines XMLDokumentes eine URL vorfindet, an der sich dieses Dokument befindet. In diesem Fall
schickt sie einen Request an den Director, der diesen an die Applikation weiterleitet. Nun
wird natürlich eine XML-Datei oder eine Speicherrepräsentation von der Model ProcessingKomponente erwartet. Diese muss sich beim Aufruf des Requests auf einen Rückgabewert
beziehen. Dies wäre ohne eine Schnittstelle, die die Applikation anweist, im Falle eines
Requests auch einen solchen Rückgabewert zu liefern, nur schwer realisierbar.
5.4 Feinentwurf
5.4.1 Einführung
Der Feinentwurf hat die Aufgabe, die im Grobentwurf vorgestellte Architektur im Detail zu
erklären. Die Abstraktionsebene verschiebt sich von der Sicht auf Komponenten zu der Sicht
auf einzelne Klassen, Variablen und Methoden. Der Feinentwurf dient dabei einerseits als
Anleitung für die Programmierung und andererseits als Referenzdokument für die Sicht auf
die Bibliothek im Detail.
Die Tiefe der Darstellung des Entwurfes wurde so gewählt, dass das Verständnis für die dem
Interpreter zugrundeliegende Architektur vereinfacht wird. Dafür werden einige Teile des
Entwurfes nur unvollständig oder vereinfacht dargestellt. Dies betrifft sowohl die
Gesamtstruktur als auch die Komposition der einzelnen Diagramme.
- 30 -
5.4.2 Architektur
5.4.2.1 Kern
Der Kern des Feinentwurfes wie in Diagramm 1 dargestellt, ist der Teil, der dem Grobentwurf
am nächsten kommt. Er gibt eine Übersicht über die Realisierung über die einzelnen
Komponenten in den Klassen und zeigt die benötigten Methoden und Variablen.
Diagramm 1: Kern
Den Kern der Implementierung bilden die im Grobentwurf vorgestellten Komponenten. Dabei
spielt die Director-Klasse eine zentrale Rolle. Sie kommuniziert mit allen anderen Klassen
und der Applikation.
Jede Komponente wird durch eine Schnittstelle und eine Implementierung repräsentiert. Die
Schnittstellen beschreiben lediglich, welche Funktionen die einzelne Komponente anbieten
müssen, damit die jeweils anderen arbeiten können. Die implementierten Klassen erfüllen
- 31 -
diese Funktionalität in spezifischer Weise. Dieses Prinzip wird „Program to an Interface“
genannt und im Rationale erläutert.
Zu den im Grobentwurf vorgestellten Komponenten sind hier zwei weitere Klassen
beschrieben.
Die erste, XFormsConstants, orientiert sich an der Klasse XMLConstants aus dem Java
Standard Package „javax.xml“. Wie in dieser Klasse für XML sind in XFormsConstants
Basiswerte zur Erkennung von XForms-Elementen, URLs und Namensräumen festgelegt.
Diese Werte sind statisch, so dass die Klasse nicht instanziiert werden muss. Konstanten
dieser Art werden von allen Analyse-Komponenten gebraucht, um sicherzustellen, dass ein
namentlich erkanntes Element auch tatsächlich zum XForms-Namensraum gehört.
Die zweite Klasse ist BehaviourAnalysis. Sie ist aus der Sicht des Grobentwurfes betrachtet,
Teil der Komponenten ModelProcessing und Analysis. Dennoch ist sie als externe Klasse
realsisiert, da erstens beide Klassen auf ihre Funktionalität angewiesen sind, eine
Codeduplizierung aber vermieden werden sollte. Zweitens, ist der Zeitpunkt der
Verhaltensanalyse von großer Relevanz. Wird beispielsweise die Action eines XFControlElementes untersucht und festgestellt, dass sie sich auf eine andere XFControl als Ziel
bezieht, ist eine Zuweisung während der Control Analyse ggf. nicht möglich. Dies ist der Fall,
wenn die Ziel-Control noch nicht analysiert wurde.
Im Folgenden soll auf einzelne Aspekte des Entwurfes genauer eingegangen werden.
- 32 -
5.4.2.2 Daten Container
In XForms werden Daten, wie in Kapitel 3.3 beschrieben, als XML-Dokumente innerhalb von
sogenannten Models gespeichert. Um die Hierarchie dieser Struktur nachzubilden und die
Arbeit mit den Daten zu vereinfachen, wurden die in Diagramm 2 dargestellten Daten
Container entworfen.
Diagramm 2: Daten Container
- 33 -
Das Interface ModelProcessingUnit beschreibt die Methoden, derer es bedarf, um die im
XForms-Dokument definierten Daten für die Bibliothek aufzubereiten. Diese Klasse erzeugt
während der Verarbeitung Container, die die Models im XForms-Dokument repräsentieren.
Diese bestehen aus der Modelklasse und den Objekten, die diese Klasse referenziert, wie im
Diagramm dargestellt.
Die Modelklasse speichert Informationen über das Model selbst. Die Daten Instanzen werden
nicht umgewandelt, sondern als XML-Dokument innerhalb der Models gespeichert. Dabei ist
zu bemerken, dass die ModelProcessingUnit nicht die Implementierung der Document-Klasse
kennt, sondern mit der Document Builder Factory arbeitet, die ihr vom Director übergeben
wurde.
Die unveränderte Speicherung der Instanzen hat den Grund, dass die Bindings sich über
XPath Ausdrücke auf die DOM-Knoten beziehen und daher das XML-Dokument als Kontext
zur Navigation benötigen. Die Zuweisung von XPath-Ausdruck zu DOM-Knoten wird von
der XPath-Klasse, Bestandteil der Jaxen Bibliothek, vorgenommen.
Die Bindings selbst werden nicht zu eigenen Containern umgewandelt. Sie versehen lediglich
die Daten mit Beschränkungen, deshalb wurde der Ansatz gewählt, diese Informationen
innerhalb des Daten Containers DataNode zu speichern, auf den sie sich beziehen.
Das Verhalten der Models wird in der Klasse BehaviourUnit gesammelt. BehaviourUnits
werden, wie im letzten Kapitel beschrieben, von der externen Klasse BehaviourAnalysis
erzeugt, die dafür von der ModelProcessingUnit referenziert wird.
Die Submission Elemente werden in einem eigenen Container gespeichert. Eine Modelklasse
kann mehrere solcher Submission Instanzen besitzen.
Der Container DataNode schließlich ist die wichtigste Klasse. Sie bündelt alle Informationen
über einen Datenknoten. Diese Informationen kommen sowohl aus den Instanz-Daten
(Initialwerte) als auch aus den Bindings (Model Item Properties).
Ein Netz von DataNodes, der Dependency-Graph, repräsentiert die Abhängigkeiten der Daten
innerhalb eines Models. Ein DataNode Objekt übernimmt dafür sowohl die Rolle des
Observers als auch des Observable (Observer Pattern [6]). Dadurch können Änderungen des
Zustands einfach propagiert werden. Details zu dieser Verarbeitung sind in Kapitel 5.4.1 zu
finden.
- 34 -
5.4.2.3 Control Container
Eine XFControl ist ein Model für ein GUI-Element aus XForms. Diagramm 3 zeigt die
verwendete Klassenstruktur.
Diagramm 3: Control Container
Informationen über die XForms-Controls liegen zu Beginn des Interpretationsvorganges in
XML Form vor. Zudem sind die Daten und Beschreibung der Controls getrennt gespeichert
und werden nur durch Bindings verknüpft. Für die Verwaltung der Informationen innerhalb
des Interpreters, vor allem während der Phase der Arbeit mit der Benutzeroberfläche, eignet
sich dieses Format deshalb nur schlecht.
Die XForms-Controls werden in einem XFControl genannten Container verwaltet. Dieser hat
den Zweck, alle Informationen, die der Interpreter zur Arbeit mit dem GUI-Element benötigt,
zentral zu speichern.
Eine XFControl setzt sich aus vier Teilen zusammen, die jeweils eine Kategorie von
Informationen repräsentieren.
- 35 -
XFControl-Objekte selbst speichern neben den zugehörigen Markups zusätzliche
Informationen zu der Beschaffenheit des GUI-Elementes, die beispielsweise durch die
Attribute navindex und accesskey ausgedrückt werden.
Die zugrundeliegenden Daten für die XForms-Control, also die Daten, die durch sie angezeigt
und/oder verändert werden, werden über eine Referenz zum zugehörigen DataNode Objekt
erstellt. Üblicherweise verfügen Controls über solche Daten. In Ausnahmefällen kann jedoch
davon abgewichen werden. Dies ist z.B. für die Output und Trigger Controls möglich.
Der sichtbare Teil des GUI-Elementes wird in einer JComponent aus dem Java Swing
Package realisiert.
Schließlich wird das Verhalten der Control im Sinne des Eventing durch BehaviourUnit
Container ermöglicht. Diese speichern die Eventhandler der Control.
Während der Arbeit mit der GUI werden diese gesammelten Informationen verwendet, um die
Java Swing-Komponente an die geforderten Bedingungen anzupassen. Wird beispielsweise
der Wert der Model Item Property readonly der zugeordneten DataNode durch eine
Interaktion des Benutzers von unwahr auf wahr geändert, muss die Methode setEnabled(false)
der JComponent aufgerufen werden. Durch die Klasse XFControl, die das Verhalten, die
Daten und das Aussehen eines XForms-GUI-Elementes bündelt, wird eine solche Reflektion
der Änderungen erst möglich.
- 36 -
5.4.2.4 Registrierung von Controls
Damit XFControl-Elemente ihren Zweck erfüllen, müssen sie bei der View und ControllerKlasse registriert werden. Diese Registrierung wird im Rahmen der Synthese durchgeführt.
Diagramm 4 zeigt die darunterliegenden Struktur.
Diagramm 4: Registrierung
XFControl-Elemente sind Bestandteil der GUI und müssen als solches bei ihr registriert
werden. Dazu wird der XFControl während der Synthese eine JComponent aus dem Java
Swing Package zugeordnet. Anschließend werden die Eigenschaften der JComponent dem
Status der XFControl entsprechend gesetzt, d.h. Daten, Markups und Model Item Properties
werden auf Swing-Komponenten übertragen. Die JComponent wird dann der View
hinzugefügt. Diese legt die Darstellung des Elementes fest, z.B. seine Größe oder Position auf
- 37 -
der Benutzeroberfläche. Im Rahmen einer Erweiterung könnte hier auch die Behandlung von
CSS Layout Eigenschaften stattfinden.
Nach der Anmeldung bei der View wird das XFControl-Objekt beim Controller registriert.
Dazu wird es auf seine Interaktionsfähigkeit (siehe Kapitel 5.4.1) und seine BehaviourUnits
untersucht und innerhalb des Controllers in der entsprechenden Struktur abgelegt. Weiterhin
wird der Controller bei der View als Listener für die entsprechenden Java Events eingetragen.
Nach Abschluss des Interpretationsvorganges wird das Objekt View, das die sichtbare
Komponente der Benutzeroberfläche repräsentiert, an die Application übergeben. Da es sich
bei dem Objekt um eine Erweiterung der Klasse Java.Swing.JPanel handelt, kann die
Anwendung sie dann problemlos in einem Fenster darstellen.
5.4.3 Rationale für Feinentwurf
Das Rationale für den Feinentwurf ist, bezogen auf den gesamten Entwurf, als Ergänzung
zum Rationale des Grobentwurfes zu betrachten.
Der Prozess des Entwurfes auf dieser Ebene kennzeichnet sich durch eine Reihe von
Entscheidungen, die sich im Feinentwurf niederschlagen. Die wichtigsten sollen hier mit ihren
Konsequenzen erläutert werden.
Information Hiding und Program to an Interface
Durch Einführung der Directorklasse findet eine Entkopplung der Komponenten von den
verwendeten Implementierungen statt, da die Director-Komponente als einizige die genauen
Klassen kennt. Die anderen Klassen arbeiten lediglich mit Schnittstellenbeschreibungen. So
entsteht eine logische Trennung nach Funktionalität und Vorgehensweise. Diese Art des
Designs folgt einem anerkannten Prinzip, dem sogenannten Program to an Interface.
Diese Architektur hat vor allem Einfluss auf die Wartbarkeit und Erweiterbarkeit des
Interpreters, da Änderungen an den Komponenten über ihre Schnittstelle durchgeführt werden
können und so neue Implementierungen wesentlich leichter eingebunden werden können.
Auch das Testen einzelner Klassen oder die Ersetzung durch neue Implementierungen werden
erleichtert. Zudem genügt für ein Grundverständnis der Arbeitsweise des Interpreters die
Betrachtung der Interfaces, die grob vorgeben, was die einzelnen Klassen leisten müssen.
Zudem ensteht durch die vielen Zuweisungen und die damit verbundenen Intialisierungen der
Klassen im Vergleich zu der direkte Referenzierung ein Overhead an Code. Zusätzlich bedarf
es für die Erzeugung einiger Objekte Factories (Factory Design Pattern [6]), da die dafür
benötigten Informationen schrittweise eintreffen. Dies ist z.B. der Fall beim Erzeugen von
neuen Document-Objekten innerhalb des Separators, die abhängig vom verwendeten Parser
sind. Der Director muss hier die Document Builder Factory bereitstellen.
- 38 -
Erweiterbarkeit
Eine komplette Implementierung des XForms-Standards ist im Rahmen dieser Arbeit nicht
möglich. Damit eine einfache Erweiterbarkeit gewährleistet werden kann, müssen
Strukturänderungen klein gehalten werden. Um dies zu erreichen, wurde die Nachimplementierung von vornherein vorgesehen. Dies zeichnet sich z.B. dadurch aus, dass alle
Attribute und Elemente innerhalb der Container definiert sind, auch wenn sie in der
tatsächlichen Implementierung der Bibliothek nicht unbedingt behandelt werden.
Die Werte dieser Attribute, die zusätzliche Eigenschaften wie das Styling durch CSS
Stylesheets oder den komfortablen Zugriff auf Controls spezifizieren, werden während der
Analyse gesammelt, eine Weiterverarbeitung durch die Synthese findet aber nicht
notwendigerweise statt. Eine Erweiterung zur Unterstützung dieser Attribute braucht sich
dann nur mit dem Auswerten der entsprechenden Daten zu befassen.
Nachteilig an dieser Designentscheidung ist, dass Daten analysiert werden, die für den
jetzigen Stand der Implementierung nicht benötigt werden, was einen Overhead darstellt, der
sich auf die Performanz der Anwendung niederschlägt. Allerdings ist zu bermerken, dass es
sich hierbei um die Auswertung von einigen wenigen zusätzlichen DOM-Knoten und
Attributen handelt, die Dimension des in diesem Sinne überflüssigen Aufwandes also klein
ist, und nur vernachlässigbaren Einfluss auf die Gesamtperformance hat.
View als JPanel
Die Entscheidung, die sichtbare Komponente der GUI, die View, als Erweiterung der Java
Swing-Klasse JPanel zu realisieren, ist in der Einbindung durch die Applikation und dem
Einsatz im Kontext von Web Services begründet.
Ein JPanel lässt sich leicht in ein Fenster eingliedern. Zudem hat die Anwendung die
Möglichkeit in einem Fenster mehrere intepretierte Views darzustellen und sie nach Belieben
zu gruppieren. Weiterhin können einem JPanel Eigenschaften zugewiesen werden, die somit
die gesamte GUI betreffen. Beispielsweise kann so in einer Anwendung mit mehreren GUIs
selektiv jeweils nur eine zur Bearbeitung freigegeben werden, indem bei den anderen die
Methode setEnabled(false) aufgerufen wird. Ein anderer Anwendungsfall ist das Hinzufügen
von zusätzlichen Listener-Klassen zu der GUI im Gesamten oder zu den einzelnen Elementen,
um ereignisgesteuerte Verarbeitung durch die Anwendung zu ermöglichen.
Zusätzlich ist dabei das Prinzip des Information Hinding angewandt, da die Anwendung nicht
wissen muss, dass es sich um eine Instanz der Klasse View handelt, um sie darzustellen.
Stattdessen kann sie sich darauf verlassen, dass es sich um ein Instanz der Klasse JPanel
handelt, ohne auf die Erweiterungsdetails eingehen zu müssen.
Zusammengefasst lässt sich sagen, dass durch die Verwendung der JPanel-Klasse sowohl die
Verwaltung, als auch der Zugriff auf die Funktionalität der interpretierten Benutzeroberfläche
für die Applikation verbessert werden.
Design Patterns
Der Einsatz von Design Patterns erlaubt es, eine Struktur schnell zu durchschauen, wenn man
die eingesetzten Pattern kennt. Der entstehende Code wird flexibler, leichter zu lesen und
leichter modifizierbar [6]. Für die Anwendung bedeutet dies eine erhöhte Wart- und
Erweiterbarkeit. Da die Aufgabenstellung besonderen Wert auf die Erfüllung dieser beiden
- 39 -
Qualitätsmerkmale legt, ist der Einsatz von Design Patterns also verstärkt zu erwägen. Dabei
darf es jedoch nicht zu einer zwanghaften Verwendung kommen, also nicht zu der
Anwendung bei Aufgaben, für die sie nicht konzipiert sind.
In der Architektur des Interpreters werden mehrere Pattern verwendet. Informationen zu den
einzelnen Pattern sind unter [6] zu finden.
Die Director-Klasse implementiert das Facade Pattern. Sie bietet eine Selektion der
Schnittstellen ihrer referenziert Komponenten. So kann die Anwendung beispielsweise über
den Director auf Methode der Synthese-Klasse zugreifen. Ebenso können die einzelnen
Komponenten über den Director eine Quelldatei anfordern. Diese Anforderung wird von ihm
an die Applikation weitergeleitet.
Für das Propagieren von Änderungsbenachrichtigungen im Sinne des Processing Cycle
implementiert die Klasse DataNode das Observer-Pattern. Sie übernimmt dabei sowohl die
Rolle des Observers als auch des Obeservable. Einzelheiten zu dem Zweck dieser
Verwendung finden sich in Kapitel 5.4.1.
Des weiteren wird das Observer-Pattern für die Realisierung des Eventings verwendet. Siehe
hierzu Kapitel 5.4.2
Die XForms-Actions werden mit Hilfe des Command-Patterns umgesetzt. Dieses Pattern
besagt, dass an Stelle einer Methode einem Befehl eine eigene Klasse zugeordnet wird. Dieses
Pattern wurden hier verwendet, um den Actions spezifische Informationen gekapselt zur
Verfügung zu stellen und neue Actions einfacher einfügen zu können.
Weiterhin werden Pattern der Java Bibliotheken (z.B. Model View Controller-Pattern in
Swing) und Parser-Bibliotheken implizit verwendet (Factory- und Builder-Pattern für das
Erhalten neuer Dokumentinstanzen).
Sonstiges
Eine gute Architektur kann in einigen Fällen als Muster für einen eigenen Entwurf dienen. In
der vorliegende Arbeit orientiert sich der Entwurf teilweise an den Klassen der Java XMLund W3C-Packages. Insbesondere die Klasse XFormsConstants ist direkt abgeleitet. Die
Exception-Klassen sind ebefalls Äquivalente zu den XML-Exceptions.
Des weiteren werden dort, wo es möglich ist die Standardklassen bzw. -Interfaces verwendet.
Dies erleichtert den Umstieg auf andere Hilfsbibliotheken wie z.B. XML-Parser Bibliotheken.
5.4.4 Ablaufplan der Initialisierung
Die Entwürfe stellen die Bibliothek vor, sagen jedoch nur wenig über den Ablauf des
Interpretierens aus. Dieses Kapitel erläutert als Ergänzung zu den Entwürfe, den Vorgang der
Transformation der XForms-GUI zu einer Java Swing-GUI, in Form der dafür benötigten
Anweisungen. Sie sind in der Reihenfolge ihres Auftretens gelistet und mit aufrufender
Klasse genannt.
- 40 -
Director:
✗
Weise allen Einheiten die benötigten Komponenten zu
✗
Übergebe das von der Applikation enthaltene Dokument an die SeperatorUnit
Separator:
✗
Parse das XML-Dokument in das DOM-Format
✗
Trenne <head> und <body> des Dokumentes
✗
Übergebe einzelne Knoten des <head> - Dokumentes sequentiell an die Model
Processing Unit und verarbeite alle Knoten, die nicht zum XForms-Namespace
gehören (Hostformat-Tags)
Model Processing Unit:
✗
Teile <head> - Dokument in einzelne Models und ihre zugehörigen Informationen
(Instances,Bindings, Actions und Submissions)
✗
Erstelle dafür Dokumente für die einzelnen Instances und speichere sie innerhalb der
Models
✗
Schicke bei Bedarf eine Source Anfrage auf den Output des Directors (Dieser leitet sie
an die Applikation weiter)
✗
Registriere Actions auf Models bzw. Listener für Events, die das Model betreffen
✗
Analysiere Daten und Bindings und erzeuge für jedes Model die DataNodes
✗
Baue den Dependeny-Graphen und beachte dabei Selbstreferenzen und zirkuläre
Abhängigkeiten
✗
Führe Anfangsvalidierung durch
✗
Analysiere und speichere Submissions in eigenen Objekten
Separator:
✗
Übergebe Model-Objekte an Analysis Unit
✗
Übergebe einzelne Knoten des <body> - Dokumentes sequentiell an Analysis Unit
(unabhängig von ihrem Namespace)
Analysis:
✗
Analysiere Knoten und erzeuge entsprechend eine XFControl, XFStructure, einen
unterstützten HTML-Formatierungsbefehl oder gebe aus, dass das Element nicht
unterstützt wird
✗
Weise der XFControl abhängig von iihrem Bindungsattribut eine DataNode, eine
Submission oder einen Wert zu.
Separator:
✗
Übergebe die Ergebnisse der BehaviourAnalysis, die das Verhalten von Models und
Controls analysiert, in BehaviourUnit Objekten speichert und diese in den Containern
referenziert
✗
Übergebe die Ergebnisse der Analysis Unit. Diese erweitert den Dependency-Graphen
um die Control-Referenzen
✗
Übergebe die Controls sequentiell der Synthesis Unit
Synthesis:
✗
Füge Information über die Control der DataNode hinzu (sowohl für die Control selbst
auch als für ihre Markups falls vorhanden)
✗
Erstelle zu der XFControl eine passende JComponent und weise sie der XFControl zu
✗
Registriere die JComponent unter Beachtung des Layouts (CSS, HTMLFormatierung) bei der View
- 41 -
✗
✗
✗
Registriere XFControl bei Controller und weise ihr bei Bedarf den Status eines
Interaction-Objektes zu (siehe Kapitel 5.4.1)
Registriere XFControl bei Controller für Events
Trage Controller als Listener bei der JComponent ein
Die Initialisierung ist an dieser Stelle beendet. Das Rückgabe-Objekt der Interpret-Methode
ist die View, d.h. die Applikation, die diese Methode des Directors aufgerufen hatte, erhält die
transformierte GUI. Sie kann diese anschließend durch Integration in ein Fenster in Betrieb
nehmen.
5.5 Umsetzung in Java
Im Anschluss an die Initialisierung und Übergabe der GUI an die Applikation kann diese in
Betrieb genommen werden. Die hier genannten Prozesse spielen sich in der Phase des
Betriebs der GUI, also der Interaktion mit dem Benutzer, ab.
Die Realisierung des Entwurfes und des in Kaptel 4.2 vorgestellten Konzeptes wird hier
detalliert beschrieben. Dabei wird auf einzelne Klassen und Strukturen des Entwurfes
eingegangen.
5.5.1 Processing Cycle
In XForms ist die Interaktion des Benutzers mit der graphischen Benutzeroberfläche so
umgesetzt, dass nach der Eingabe oder der Auswahl von Daten über ein GUI-Element die
gemachten Änderungen nicht sofort übernommen und angezeigt werden. Stattdessen ist es
üblich, eine Änderung aktiv zu übernehmen, indem man eine bestimmte Taste drückt (Bei
PCs standardmäßig ENTER), also den DOMActivate-Event auslöst, oder aber von dem
Element wegnavigiert, um anzuzeigen, dass die Werte übernommen werden können.
Dieser Prozess unterscheidet sich grundsätzlich von dem in Java Swing üblichen Prozess.
Dort gibt es einen Mechanismus, der vorsieht, Änderungen im Zustand eines GUI-Elementes
durch Listener zu beobachten und sofort zu behandeln. Es wird also abgegrenzt, zwischen
dem Aktivieren oder Verlassen eines Elementes in XForms, bei dem nachträglich auf
gemachte Änderungen eingegangen wird, und dem direkten Beobachten des Zustandes eines
Elementes in Java Swing, bei dem die Absicht des Benutzers, die Änderungen zu
übernehmen, keine Rolle spielt.
Um das XForms-„Look and Feel“ zu simulieren, bedarf es also einiger Anpassungen an der
Ereignisbehandlung. Die beiden Java Events „ActionEvent“ und „FocusEvent“ entsprechen
- 42 -
dabei abstrakt gesehen dem Wunsch des Benutzers, gemachte Änderungen zu übernehmen.
Konkret bedeutet dies, dass der Controller primär diese beiden Java Events beobachten muss.
Die Quellen der Events sind JComponents, die einer aktiven XFControl angehängt sind. Mit
„aktiv“ sind in diesem Kontext Controls gemeint, die Änderungen der Daten durch den
Benutzer direkt ermöglichen, also nicht über das Verhalten der XFControl. Dies trifft auf
folgende XFControls zu:






XFInput
XFSecret
XFSelect, XFSelect1
XFRange
XFTextArea
XFUpload
Alle XFControls dieser Art werden von der Synthese in der Initialisierungsphase der GUI
beim Controller für diese Events registriert.
Weiterhin gibt es GUI-Elemente, die in ihrer Funktionalität auch in Java ein explizites
Aktivieren erfordern. Dies sind die XForms-Controls Trigger und Submit, einer Unterklasse
von Trigger. Diese Elemente werden wie in Tabelle 3 bzw. 4 beschrieben durch ein JButton
ausgedrückt. Für diese Klassen ist der Controller der ActionListener, nicht jedoch der
FocusListener, wie es bei den oben erwähnten aktiven XForms-Controls der Fall ist. Eine
Navigation vom GUI-Element weg, hat hier keine Einfluss.
Andere hier nicht genannte Elemente bieten keine Möglichkeiten zur Interaktion mit dem
Benutzer und müssen deshalb nicht auf Aktivitäten überwacht werden.
Während der Interaktionsphase des Benutzers mit der GUI werden die Events ausgelöst und
vom Controller abgefangen. Ein Auslösen der Events bewirkt das Durchlaufen des Processing
Cycles. Dazu ruft des Controller nacheinander die nötigen Methoden wie in Abbildung 2
gezeigt auf und übergibt die XFControl, die den Event ausgelöst hat, als Parameter. Die
folgenden Methoden beziehen sich jeweils auf das Model, in dem die Änderung stattgefunden
hat. Zu Beginn der Ausführung der Methoden werden jeweils die entsprechenden Events
abgefeuert.
Abbildung 2: Processing Cycle
- 43 -
Rebuild
Der als Rebuild bezeichnete Vorgang hat das Ziel, einen Abhängigkeitsgraphen der im
angegebenen Model enthaltenen Daten zu erstellen, um die Auswirkungen von
Datenänderungen zu koordinieren. Der Abhängigkeitsgraph muss mindest einmal in der
Initialisierungsphase der GUI erstellt werden. Weitere Aufrufe der Methode Rebuild sind nur
nötig, wenn sich etwas an der Struktur der Daten ändert, d.h. wenn ein Lösch- oder
Einfügevorgang auf dem zugrundeliegenden DOM-Baum stattgefunden hat.
Der Abhängigkeitsgraph ist durch eine Verkettung von DataNodes realisiert. Die
Abhängigkeiten werden dadurch ausgedrückt, dass eine DataNode zwei Arten von
Datenstrukturen besitzt – eine, die Referenzen auf alle von ihr abhängigen DataNodes
speichert, und eine weitere, die Verweise auf alle sie referenzierenden XFControls enthält.
Ein Abhängigkeitsgraph wird in drei Phasen erstellt. In der ersten Phase werden von der
Model Processing Unit lediglich alle DataNodes eingefügt, sie verfügen dabei noch über
keine Verweise.
Die zweite Phase ist dadurch gekennzeichnet, dass Verweise auf andere DataNodes
hergestellt werden. Verweise von einer DataNode auf eine andere können immer dort
auftreten, wo ein Attribut mit Hilfe einer XPath Funktion berechnet wird und der Verweis auf
Daten ein Parameter der Funktion ist. Beispielsweise kann ein Model folgendes Binding
enthalten:
<xf:bind id="myBind" ref="/person/smokes" relevant="/person/age > 16" />
Der Wert des Elementes smokes wird also nur abgefragt, wenn der Wert eines anderen
Elementes (age) eine bestimmte Bedingung erfüllt. Damit ergibt sich eine Abhängigkeit der
DataNode des Elementes smokes von der DataNode des Elementes age.
Tabelle 6 Zeigt die weiteren Stellen, an denen Berechnungen von Werten stattfinden, die eine
Abhängigkeit zur Folge haben können:
Klassifizierung
Element
Attribut
Bindings
bind
readonly
bind
required
bind
relevant
bind
constraint
bind
calculate
setvalue
value
insert
at
delete
at
output
value
Actions
Controls
Tabelle 6: Berechenbare Attribute, angelehnt an [5]
- 44 -
Während dieser Analyse ist zu beachten, dass sie sowohl von der Model Processing Unit
(verantwortlich für Bindings und Actions innerhalb von Models) als auch von der Analysis
Unit (verantwortlich für Controls und Actions innerhalb von Controls) durchgeführt werden
muss, um alle Abhängigkeiten abzudecken.
Die dritte Phase schließlich dient der Verknüpfung der Daten mit den XFControls, die sie
referenzieren. Diese Verbindungen sind erforderlich, um im Falle einer Datenänderung auch
die graphische Oberfläche entsprechend anzupassen. Diese Verarbeitung wird von der
AnalysisUnit durchgeführt.
Nach der Erzeugung besitzt der Graph einen Zustand, der angibt, ob er aktuell ist. Wenn der
Zustand den Graphen als nicht aktuell deklariert, wird ein Rebuild, d.h. eine
Neustrukturierung des Graphen, durchgeführt. Ist der Graph hingegen aktuell, braucht diese
Phase des Processing Cycles nicht durchlaufen zu werden. Eine Änderung der Datenstruktur
kann dabei an den in Tabelle 7 gezeigten Stellen stattfinden.
XForms-Tag
Kontext
copy
In Select und Select1-Strukturen
insert
In Repeat-Strukturen
delete
In Repeat-Strukturen
Tabelle 7: Xforms-Tags, durch die die Datenstruktur geändert wird
Jede dieser Aktionen hat zur Folge, dass der Zustand des betroffenen Abhängigkeitsgraphen
auf veraltet gesetzt wird. Dadurch wird ein Rebuild nötig und bei der nächsten Änderung
durchgeführt.
Recalculate
Diese Phase des Processing Cycles dient dazu, die dynamischen Werte und Zustände von den
zugrundeliegenden Daten neu zu berechnen. Berechnungen werden in XForms über XPath
Funktionen durchgeführt, die an den Tabelle 6 in genannten Stellen vorkommen können.
Durch die Aktualisierung von Daten müssen sich die angezeigten GUI-Elemente anpassen. So
kann beispielsweise eine Benutzereingabe dazu führen, dass ein Texteingabefeld überhaupt
angezeigt wird. Dies ist der Fall, wenn die Daten, auf die das Eingabefeld referenziert, eine
Model Item Property relevant haben, die über einen XPath-Ausdruck den Inhalt eines anderen
Datenknotens benutzt und dessen Zustand von false auf true setzen.
Das wichtigste Werkzeug für die Methode recalculate ist daher der durch Rebuild erzeugte
Abhängigkeitsgraph. Er dient dazu, die Auswirkungen der vorgenommene Datenänderung zu
ermitteln. Im Detail funktioniert dies so, dass eine DataNode durch von ihr abhängige
DataNodes und auf sie verweisende XFControls beobachtet wird. Beide Arten von Elementen
übernehmen hier die Rolle des Observers. Die DataNodes sind also gleichzeitig Observer und
Observable. Das zugrundeliegende Konzept ist, dass die durch Benutzereingaben oder
Actions beeinflussten DataNodes dafür verantwortlich sind, die Änderungen weiterzugeben.
Wird eine DataNode verändert, informiert sie sukzessiv ihre alle von ihr abhängigen
DataNodes. Diese erhalten den Status changed im Sinne des Observer Patterns. Die Phase
Refresh untersucht die DataNodes schließlich auf diesen Zustand und benachrichtigt ggf. die
abhängigen Elemente. So wandert eine Änderung schließlich zu allen betroffenen
- 45 -
XFControls. Diese wiederum setzen die betroffenen Eigenschaften ihrer JComponents, was
schließlich (Refresh-Phase) zu einem Update der View führt: Die Änderungen an den Daten
haben die GUI erreicht.
Hierbei ist zu bemerken, dass das Element, das die Änderung vorgenommen hat, selbst nicht
aktualisiert wird (wohl aber die Daten, auf die es verweist). Dies hat den Grund, dass sonst im
Zusammenhang mit der „calculate“ Property eine Abhängigkeit entstehen könnte, die dazu
führen würde, dass man einen Wert nicht sicher setzen könnte. Man könnte sich
beispielsweise ein Texteingabefeld für eine Zahl vorstellen, das die Eingabe des Benutzers
mit einer Konstante multipliziert.
Gibt der Benutzer einen Wert ein und bestätigt ihn durch Drücken der ENTER Taste, werden
die Daten, auf die das Texteingabefeld verweist aktualisiert. Würden nun Änderungen auch
für dieses GUI-Element angezeigt werden, so würde das Texteingabefeld das Produkt aus der
gemachten Eingabe und der Konstante anzeigen. Wenn nun von diesem Element wegnavigiert
werden würde, würde der aktuelle Zustand der Eingabe, also das Produkt als Eingabe
betrachtet werden und erneut mit einer Konstante multipliziert werden. Dies entpräche nicht
der Intention des Benutzers. Obwohl dieses Problem durch eine differenzierte
Implementierung abgefangen werden könnte, ist der Stellenwert der vernachlässigten
Funktionalität zu gering, um eine solche zu rechtfertigen. Die Implementierung des XSmiles
Browsers ist in dieser Hinsicht ebenso beschaffen.
Insbesondere gilt es die Property calculate so zu verarbeiten, dass das Resultat der
gewünschten Semantik gerecht wird.
Daten die mit einer Calculate Property gebunden sind werden abhängig von dieser Property
aktualisiert. Ein einfacher Anwendungfall ist wie bereits beschrieben die Multiplikation des
eingegebenen Wertes mit einer Konstante. In diesem Fall handelt es sich um eine
Selbstreferenz, da die Daten von ihrem vorherigen (die Eingabe wird sofort gesetzt) Wert
abhängen. Es ist jedoch auch möglich Daten von anderen Knoten an eine Datenknoten über
calculate zu binden. So kann z.B. ein Eingabefeld die Summe der Werte zweier Datenknoten
anzeigen. In diesem Fall hat der damit gebundene Datenknoten keine Referenz auf sich selbst,
d.h. Interaktionen des Benutzers mit diese Eingabefeld haben keinen Einfluss auf die
darunterliegenden Daten.
Änderungen die eine DataNode ohne Selbstreferenz betreffen müssen daher ignoriert werden.
Revalidate
Die Möglichkeit, eine clientseitige Validierung durchzuführen, ist eine der großen Stärken
von XForms. Dabei wird, wie in Kapitel 3.4.2 beschrieben, XML Schema verwendet.
Die Methode Revalidate hat die Aufgabe, veränderte Daten gegen statische (in einem XML
Schema definierte) und dynamische (Verwendung des Attributes type) Constraints zu prüfen.
Wird die Methode während des Processing Cycles aufgerufen, durchläuft sie alle betroffenen
DataNodes und prüft diese auf ihre Validität. Ist eine der DataNodes nicht valide, wird das
gesamte Model auf invalid gesetzt. Dies ist für die Submission von Bedeutung, da diese nur
bei gültigen XML-Dokumente durchgeführt werden darf. Eine erneute Prüfung nach Eingabe
von neuen Werten kann die Gültigkeit der DataNode wieder herstellen.
- 46 -
Zusätzlich wird der Zustand der DataNode auf changed verändert. In der Refresh-Phase kann
dann die entsprechende grafische Auszeichnung veranlasst werden.
Refresh
In XForms bezeichnet Refresh das Update der graphischen Benutzeroberfläche. Dieser Schritt
ist in Java Swing Komponenten durch die einzelnen Methoden zum Setzen von Attributen
gekapselt. Sobald der Wert einer JComponent verändert wird, wird sie automatisch
aktualisiert. Da dies in der Refresh Phase passieren soll, werden während des Recalculates
und Revalidates DataNodes die zu ändernde XFControls enthalten, nur markiert (Zustand
changed). Die Markierung wird dann in der Refresh Phase aufgelöst und die Attribute der
JComponents den zugrundeliegenden Daten angepasst. Das visuelle Update wird dabei
implizit von Java Mechanismen vorgenommen.
Bemerkungen zum Auslösen des Processing Cycles:
Im Falle des Elementes XFTextArea führt ein Betätigen der ENTER-Taste zu einem
Zeilenumbruch und kann nicht als ein Signal für die Aktivierung gewertet werden. Klassen
dieses Elementes sind infolgedessen nur der Focus Überwachung ausgesetzt.
5.5.2 Events
Events treten in XForms häufig auf. Es gibt Events, die sich auf den Zustand der XFormsEngine beziehen (Lifecycle), Events, die Hinweise auf besondere Ereignisse geben
(Notification), solche die aus der Interaktion des Benutzers mit der GUI entstehen,
(Interaction) und Events, die auf Fehler aufmerksam machen (Error Handling). Zudem lassen
sich über die Action „dispatch“ auch eigene Events auslösen.
Ein Event in XForms bezieht sich entweder auf ein Model, eine (Daten-) Instanz, eine
XForms-Control, einen Bestandteil einer XForms-Struktur, eine Submission oder ein Binding.
In der Bibliothek ergibt sich folgende Zuordnung: Die Quellen für die Events sind GUIElemente (JComponents), an der Verarbeitung beteiligte Komponenten (ModelProcessing,
Analyse, Synthese) oder Models.
Ziele für Events, also Orte, an denen eine Verarbeitung von Events möglich ist, sind XFormsControls und Models. Die Implementierung des Eventing-Mechanismus ist dabei vom Ziel
abhängig.
- 47 -
Events die sich auf XForms-Controls beziehen:
Der Controller hat die Aufgabe, die XForms-Controls zu benachrichtigen, falls ein Event
aufgetreten ist. Hierfür enthält er für jede Art von Event eine Datenstruktur, die speichert,
welche Elemente von diesem Event betroffen sind. Handelt es sich um ein Standard Java
Event, wie beispielsweise „java.awt.event.FocusEvent“, so muss die Datenstruktur lediglich
das Verhalten der XFControl speichern. Wenn hingegen ein Event beobachtet werden soll,
dass XForms-spezifisch (bzw. XML-spezifisch) ist, so speichert die Datenstruktur zusätzlich
die genaue Klasse des Events. Gleiches gilt für eigene Events, die vom Autor angegeben
wurden. Die Interpretation des Events ist dabei teilweise von der verwendeten JComponent
abhängig. Tabelle 8 und 9 zeigen die so klassifizierten Datenstrukturen:
Datenstruktur
Java Swing Event*
In XForms
verwendeter Event
ActionObjects
ActionEvent
DOMActivate
FocusObjects
FocusEvent
xforms-focus
DOMFocusIN
DOMFocusOUT
ChangeObjects
ChangeEvent
xforms-out-of-range
xforms-in-range
xforms-value-changed
JSlider
ListSelectionObjects
ListSelectionEvent
xforms-select
xforms-deselect
JList
TextObjects
TextEvent
JComponent
xforms-value-changed Solche, bei denen die
„Incremental“
Property gesetzt ist
Tabelle 8: Datenstrukturen für Events, die durch Standard Java Swing Events abgebildet werden können
Datenstruktur
Eventklassen
In XForms verwendeter
Event
XFObjects
(Werden bei
Zustandsänderung innerhalb
von recalculate() und
revalidate() ausgelöst, siehe
Kapitel 4.4.4)
XFValidEvent
XFInvalidEvent
XFReadOnlyEvent
XFReadWriteEvent
XFRequiredEvent
XFOptionalEvent
XFEnabledEvent
XFDisabledEvent
Xforms-valid
xforms-invalid
xforms-readonly
xforms-readwrite
xforms-required
xforms-optional
xforms-enabled
xforms-disabled
CustomObjects
CustomEvent
Vom XForms-Autor
spezifizierte eigene Events
Tabelle 9: Andere Datenstrukturen
Die Datenstrukturen werden während der Erzeugung der Java Swing-GUI von der SyntheseKomponente gefüllt. Dabei wird für jede XFControl, die von der Analyse an die Synthese
*
Alle genannten Klassen beziehen sich auf das Package: java.awt.event
- 48 -
übergeben wurde, ihr Verhalten beim Controller registriert. Die Informationen über das
Verhalten einer XFControl, also bei welchen Events sie welche Aktionen auf welche Ziele
ausführen soll, wird in einer Klasse namens BehaviourUnit gespeichert. Dabei kann eine
XFUnit mehrere BehaviourUnits besitzen.
Im Zuge der Registrierung werden nun alle BehaviourUnits einer XFControl in die
entsprechende Datenstruktur abgelegt. Der Controller ist so aufgebaut, dass er alle oben
genannten Events beobachtet. Dafür implementiert er im Falle der Standard Java Events die
entsprechenden Listener-Interfaces und das Observer-Interface für alle anderen Events. Tritt
nun während der Arbeit des Nutzers mit der GUI ein Event auf, wird der Controller darüber
benachrichtigt, indem die entsprechende Methode aufgerufen wird. Innerhalb der Methoden
wird dann geprüft, welche BehaviourUnits für dieses speziellen Event registriert sind, und für
jede BehaviourUnit ihre zugehörige Action ausgeführt. Im Falle eines XFEvents oder eines
CustomEvents muss zuvor noch die Art des Events ermittelt werden.
Events die sich auf Models beziehen:
In XForms lösen Models Events aus. Dies passiert z.B. wenn ein Model erzeugt worden ist
oder ein Rebuild stattgefunden hat. Anders als bei Events, die sich auf Controls beziehen,
kann hier jedoch auf eine komplexe Benachrichtigung verzichtet werden. Dies hat den Grund,
dass Models ihre Events selbst behandeln. Hat ein Model ein Verhalten spezifiziert, z.B. die
Ausgabe einer Nachricht nach der Initialisierung, ist dieses Verhalten in einer BehaviourUnit
innerhalb des Model-Objektes gespeichert. Tritt während der Erzeugung des Models durch
die Model Processing Unit die entsprechende Stelle auf, kann diese Komponente das
Vorhandensein einer passenden BehaviourUnit prüfen und ggf. die angehängte Behandlung
durchführen.
5.5.3 Actions
XForms Actions werden in Klassen gespeichert, die von der Klasse XFAction erben. Die
Actions sind als Commands im Sinne des Command-Patterns realisiert, verfügen also über
eine Execute-Methode. Der Aufruf dieser Methode entspricht dem Druchführen der
gewünschten Aktion.
Wird eine Control über das Auftreten eines für sie interessanten Events informiert, teilt sie
dem in ihren BehaviourUnits gespeicherten XFAction-Objekten mit, dass sie ausgelöst
wurden. Die Aktionen werden durchgeführt.
5.5.4 Submission
Der Phase der Arbeit mit der GUI folgt das Abschicken der eingegebenen Daten. Das Ende
dieser Phase wird durch die Betätigung eines Submit-Buttons oder der Action „send“
- 49 -
eingeleitet. Der Auftreten dieses Falles wird dem Director von der Controller-Komponente
mitgeteilt. Der Director überprüft das Dokument auf seine Validität und serialisiert es durch
Verwendung des XML-Parsers. Anschließend übergibt er das Ergebnis und die zugehörigen
Submission-Information an die Applikation. Die Übergabe erfolgt über die im ApplicationInterface definierte Methode receiveSubmission. Diese kann sich dann um das Weiterleiten an
die entsprechende Quelle kümmern, oder eine eigene Verarbeitung durchführen.
- 50 -
6. Betriebsinformationen
Das folgende Kapitel hat den Betrieb der Bibliothek zum Inhalt. Es werden sowohl
Systemanforderungen, als auch konkrete Informationen zur Einbettung in eine Anwendung
gegeben. Zudem werden die Einschränkungen der Implementierung und ihre Erweiterbarkeit
diskutiert.
6.1 Versionen
Es wurden jeweils die neusten Versionen der eingesetzten Software verwendet. Die
Abwärtskompatibilität wurde nicht getestet und kann nicht garantiert werden.
Java wurde in der Version 1.5.0 (Build 1.5.0_04-b05) verwendet. Die XML Parsing
Bibiliothek ist in der Version Xerces2 Java Parser 2.7.1 Release, die XPath Bibliothek Jaxen
in der aktuellen Version 1.1 beta 8.
6.2 Lizenzen
Die verwendeten Bibliotheken stehen unter verschiedenen Open Source Lizenzen. Diese
Lizenzen erlauben die Verwendung des Codes im Rahmen der Arbeit ohne Einschränkungen,
solange auf die Lizenzen verwiesen wird. Eine Modifikation der Interpreter-Bibliothek und
das Nutzen zu wissenschaftlichen Zwecken sind ebenso gestattet. Details zu den Lizenzen
sind den beigefügten Dateien zu entnehmen.
6.3 Verwendung der Bibliothek in Anwendungen
Der Einsatz der Bibliothek im Zusammenhang mit der Anwendung ist in Kapitel 5.3 bereits
angedeutet worden. Grundsätzlich muss eine Anwendung, die den Interpreter verwenden soll,
die Interpreter-Bibliothek importieren. Zusätzlich müssen die Dateien der beiden verwendeten
Bibliotheken Xerces und Jaxen bereitgestellt werden. Sie befinden sich auf der enthaltenen
CD, können aber auch von den in [10] und [15] genannten Quellen bezogen werden.
Nachdem die Infrastruktur so gelegt ist, muss eine Anwendung das in der InterpreterBibliothek integrierte Application Interface implementieren, also Implementierungen für die
darin vorkommenden Methoden liefern.
Eine so beschaffene Anwendung braucht nun lediglich eine Instanz der Director-Klasse zu
bilden, um die Basisfunktionalität, also das Interpretieren eines XForms-Dokumentes, zu
nutzen. Der Interpreter ist auf die Verwendung der Directorklasse ausgelegt, es kann jedoch
von dieser Art der Verwendung abgesehen werden, um die einzelnen Komponenten bewusst
getrennt zu verwenden. Da die Directorklasse jedoch eine Fassade für die Funktionalität der
darunterliegenden Komponenten bietet, ist von diesem Ansatz jedoch abzusehen, zumal die
Implementierungsdetails der Komponenten zu beachten sind.
- 51 -
Der Interpreter ist weiterhin auf Skalierbarkeit angelegt, d.h. die gleichzeitige Verwendung
von mehreren Instanzen der Directorklasse wird unterstützt. So können in einer einzigen
Anwendung
mehrere
XForms-Dokumente
interpretiert
und
somit
mehrere
Benutzeroberflächen gleichzeitig dargestellt werden, bzw. auf mehrere Web Services
koordiniert werden. Hier ist jedoch zu beachten, dass die Directorkomponente auch nach der
Erzeugung der GUI noch mit ihr verknüpft ist, da sie Änderungen am Datenmodell
koordiniert etc. Dies bedeutet, dass eine Instanz des Directors nicht für die Interpretation von
mehreren XForms-Dokumenten verwendbar ist.
Da das Ergebnis der Interpretation, die GUI, in Forms eines JPanels realisiert ist, kann eine
Anwendung eine flexible Anordnung von mehreren solcher GUIs durchführen, bzw. mit
weiteren logischen Merkmalen (eingeschränkte Anzeige, gegenseitige Beeinflussung etc.)
verknüpfen. Für eine komplexere Anwendung mit solcher Funktionalität genügt es, die
Directorklasse mehrmals zu instanziieren, eine Instanz füt jedes XForms-Dokument.
Den Abschluss der Arbeit mit der GUI zeigt für gewöhnlich die Submission an. Die
Anwendung wird bei ihrem Auftreten vom Director über eine Methode benachrichtigt und
erhält das serialisierte Ergebnisdokument, sowie Informationen zu den verlangten
Übertragungmodalitäten (URI etc.) Sie kann anschließend eine Zerstörung der GUI
veranlassen.
Zu beachten ist, dass, wie in Kapitel 4.2 angeführt, die zu interpretierenden XFormsDokumente nicht auf Fehler überprüft werden, so dass die Ergebnisse der Bibliotheksausgabe
von der Korrektheit der Dokumentes abhängen. Zu Testzwecken sollte deshalb ein XFormsDokument, dass nicht einem realen Einsatzumfeld entnommen worden ist, erst mit einer
XForms-Implementierung wie XSmiles [12] geprüft werden.
Ein Beispiel für die Einbettung in einer Anwendung ist im Anhang aufgeführt.
6.4 Einschränkungen der Implementierung
6.4.1 Einleitung
Die vorliegende Arbeit beschäftigt sich mit der Interpretation von XForms-Dokumenten mit
dem Ziel, sie in einer Java Anwendung zu integrieren. Das Einsatzgebiet ist dabei im Web
Service Kontext zu sehen. Diese Vorgaben haben Konsequenzen auf den Umfang der
Implementierung. Die umzusetzenden Eigenschaften, Konzepte und Funktionen wurde
danach ausgewählt, von welcher Relevanz sie für den vorgesehenen Zweck sind. Die
Einschränkungen sind nach funktionale und syntaktische Aspekten gegliedert. Der XFormsCode, der sich auf die erwähnten nicht unterstützten Funktionen bezieht, wird als fehlerhaft
mit genauen Exceptions der Applikation gemeldet. Diese kann dann je nach gewünschtem
Modus diese ignorieren, um ein Intepretieren nicht zu unterbrechen, oder mit einer eigenen
Fehlermeldung darauf eingehen. Diese Art der Fehlerbehandlung ermöglicht es, das
Interpretieren unabhängig von einzelnen nicht unterstützten Elementen druchzuführen und so
Teilergebnisse zu liefern.
- 52 -
6.4.2 Funktionelle Einschränkungen
Die XForms-Control Input kann mit einem Datentyp als Beschränkung versehen werden und
sollte dann laut Sepzifikation in einer auf diesen Datentyp spezialisierten Weise dargestellt
werden. Wenn das <input> Element z.B. vom Typ xsd:date ist, sollte es als eine sogenannte
„date picker control“ angezeigt werden. In Java Swing gibt es standardmäßig kein solches
Element. In der Arbeit wird daher ein Eingabefeld ohne Ausnahme als einfaches
Texteingabefeld (JTextField) dargestellt. Eine mögliche (kommerzielle) Implementierung
einer „date picker control“ für Java ist unter [14] zu finden.
Die Verarbeitung von CSS Stylesheets wird wie in Kapitel 4.2 erwähnt nicht unterstützt, kann
aber im Rahmen einer Erweiterung hinzugefügt werden.
Die Verwendung von DTDs (Document Type Definitions) zur Beschränkung der Instanzdaten
wird nicht unterstützt, da es sich um eine im Grunde veraltete Technologie handelt, die durch
XML Schema ersetzt worden ist.
Die Definition von Eventhandlern mittlels Skriptsprachen wie Javascript wird nicht
unterstützt, da die Komplexität der Bibliothek dadurch unproportional steigen würde.
Generell werden Skripte nicht interpretiert, da ihr funktionelle Umfang unbegrenzt ist.
Die XForms-Control Upload ermöglicht es, Dateien vom Client auf den Server zu übertragen,
wo diese in der instance data gespeichert werden. Die Quellen für den Upload dürfen dabei
von einer Vielzahl von Formaten sein, so z.B. einfache Dateien, Bilder, Video, Audio etc.
Dabei beziehen sich die meisten dieser unterstützten Formate auf die Benutzung auf anderen
Geräten als einem Desktop-PC. Man kann so beispielsweise über die Quelle „scribble“ mit
einem handheld pen gezeichnete Bilder hochladen. Diese Funktionalität von XForms wird für
die hier gestellte Aufgabe nicht benötigt, da sie nicht in den Kontext passt. Insofern wird die
XForms-Control Upload nur rudimentär unterstützt.
Das Attribut Appearance dient dazu, das Rendering einer XForms-Control festzulegen, um
z.B. auf kleinen Geräten (PDA, Handy etc.) eine kompakte Darstellung anzufordern. Im
Rahmen dieser Arbeit spielt diese Funktion jedoch keine Rolle, da bei der Bibliothek lediglich
die Lauffähigkeit auf einem PC verlangt wird.
Die Angabe von Renderings via Attribut appearance wird daher nicht unterstützt.
Insbesondere wird die Vorgabe von eigene Renderings per Angabe einer URL ignoriert, da
die zugrundeliegenden Swing Formate zur Darstellung verwendet werden müssen. Als
Konsequenz wird stets das Java Swing Äquivalent zur XForms-Control gewählt, wie in
Kapitel 3.7. angeführt.
6.4.3 Syntaktische Einschränkungen
Wie in jeder Auszeichnungssprache gibt es auch in XForms viele syntaktische Freiheiten.
Formell entsteht dabei fehlerfreier Code, jedoch ist die Semantik nicht klar. Mit der
Möglichkeit, die beabsichtigte Wirkung auf verschiedene Arten zu erzielen, erhöht sich
zudem die Komplexität des Codes, was eine automatische Codeanalyse erschwert. In dieser
Arbeit wurde der Ansatz gewählt, konventionelle syntaktische Methoden der XFormsCodierung zu unterstützen und in Fällen von „unsauberem“ Code eine vereinfachte Syntax
- 53 -
anzunehmen. Dies hat zum Vorteil, dass die Analyse an sich weniger komplex und somit
wartbarer ist. Dabei wurde Wert darauf gelegt, dass die Funktionalität, die durch die
Vereinfachungen entfiel, auf konventionellem Wege implementiert werden kann, d.h. keine
Einschränkungen der Funktionalität bestehen, sondern lediglich deren Beschreibung. Es
wurde dabei darauf geachtet, die konventionelle Methode für eine solche Beschreibung mit
anzugeben. Die Beschränkungen beziehen sich auf die im folgenden genannten Aspekte
Einbettung von Text in Elemente ohne Auszeichnung:
Es besteht die Möglichkeit, Text als Inhalt eines Elementes anzugeben, ohne ihn z.B. als
Label zu deklarieren. Dieser Text wird dann je nach XForms-Prozessor als Beschreibungstext
vor der jeweiligen XForms-Control oder aber abhängig von der hierarchischen Positionierung
des Textes dahinter dargestellt. Da die Semantik einer solchen Beschreibung nur visuell durch
den User erschlossen werden kann, führt dies dazu, dass der Code sehr unübersichtlich
werden kann und zudem die intendierte Position und Funktion des Textes bei der CodeAnalyse nicht nachvollziehbar ist.
Konventionelle Methode: Soll die Darstellung des Textes der Beschreibung des GUIElementes dienen, so sollte der Text als Label des Elementes deklariert werden. Soll hingegen
der Text einem anderen Zwecke dienen, so sollte er als output GUI-Element ausgelagert
werden.
Beispiel:
Falsch
<xf:output ref=“/example/text“>
Überflüssiger Text
</xf:output>
Richtig
<xf:output ref=“/example/text“>
<xf:label>RichtigerText</xf:label>
</xf:output>
Verschachtelung von Elementen
XForms als XML-Vokabular bietet die Möglichkeit, Elemente hierarchisch zu verschachteln,
was beispielsweise unabdingbar für die Definition von Markup Elemente als Kindknoten ist.
Gleichzeitig kann man dadurch, XForms-Control Elemente ineinander zu verschachteln, was
zwar syntaktisch korrekt, jedoch semantisch nicht eindeutig ist. In Abgrenzung zu der
XForms-Implementierung XSmiles (Darstellung als nacheinander definierte Controls) wird in
der Interpreter-Bibliothek eine solche Hierarchie so ignoriert, dass nur das erste Element
beachtet wird.
Konventionelle Methode: Die Definition von mehreren GUI-Controls sollte hintereinander
erfolgen. Soll hingegen durch die Verschachtelung eine Gruppierung ausgedrückt werden,
muss die Control Group zur Definition verwendet werden.
- 54 -
Beispiel:
Falsch
Richtig
<xf:output ref=“/example/text“>
<xf:label>Output Label</xf:label>
<xf:input ref=“/example/data“>
<xf:label>Input Label</xf:label>
</xf:input>
</xf:output>
<xf:output ref=“/example/text“>
<xf:label>Output Label</xf:label>
</xf:output>
<xf:input ref=“/example/data“>
<xf:label>Input Label</xf:label>
</xf:input>
Mehrere Namespaces
Die Zuweisung eines Namespace für ein Element kann auf zwei verschiedene Arten
geschehen: Erstens durch die Angabe eines entsprechenden Prefixes und zweitens durch die
Verwendung des „xmlns“-Attributes. Da ein Element nur zu einem Namespace zugehörig
sein kann, wird bei der Verwendung beider Möglichkeiten die Angabe über das Attribut
gegenüber dem Prefix vernachlässigt.
Konventionelle Methode: Die Angabe des Namespace sollte nur über das Prefix geschehen,
dies macht den Code lesbarer und eindeutig.
Beispiel:
Falsch
Richtig
<html xmlns:xf=
"http://www.w3.org/2002/xforms">
<html xmlns:xf=
"http://www.w3.org/2002/xforms">
<xf:input xmlns=“http://www.example.de“>
<xf:label>Label</xf:label>
</xf:input>
<xf:input>
<xf:label>Label</xf:label>
</xf:input>
Angaben von mehreren Bindings
Die im Model definierten Bindings (siehe Kapitel 3.3) beziehen sich jeweils auf einen Knoten
der Instanzendaten. Dabei darf jedem Knoten nur ein Binding zugeordnet werden. Alle
nachfolgenden werden in der vorliegende Implementierung ignoriert. Der maßgebliche Grund
für diese Art der Verarbeitung ist die Tatsache, dass sonst widersprüchliche Aussagen über
die Daten getroffen werden könnten.
Konventionelle Methode: Defnition von jeweils einem Binding pro Element. Sollen mehrere
Model Item Properties (siehe Kapitel 3.5) gesetzt werden, können sie jeweils als Attribute
dieses einen Bindingelementes deklariert werden.Auf diese Weise ist es möglich, alle sieben
Properties für einen Datenknoten zu setzen.
- 55 -
Beispiel:
Falsch
<xf:bind id=“b1“
ref=“/example/element“
required=“false“/>
Richtig
<xf:bind id=“b“
ref=“/example/element“
required=“false“
readonly=“true“/>
<xf:bind id=“b2“
ref=“/example/element“
readonly=“true“/>
6.5 Erweiterbarkeit
6.5.1 Einführung
Aufgrund des großen Umfangs des XForms-Standards war es nicht möglich, alle
spezifizierten Elemente auch in der Interpreter-Bibliothek zu implementieren. Aufgrund
dessen war es nötig, ein Konzept zu erstellen, dass die einzelnen Aufgaben einer
Priorisierungen unterzieht und so eine schrittweise wachsende Implementierung ermöglicht.
Aufgrund des auf Wart- und Erweiterbarkeit ausgelegten Entwurfs ist es möglich, die so
entstehende Bibliothek um einzelne Funktionsaspekte und Elemente zu ergänzen. Die
Bibliothek kann anschließend mit Hilfe der angefügten Testklassen auf ihre Funktionalität
überprüft werden.
Die in der Implementierung der Bibliothek fehlenden Aspekte sind dabei grundsätzlichen von
den in Kapitel 6.5 genannten zu unterscheiden, da diese bewusst nicht implementiert worden
sind und eine Erweiterung nicht vorgesehen ist.
Ebenso sind sie von den Erweiterungen des Funktionsumfanges in Kapitel 6.6.5 und den
Änderungen der Komponenten im nachfolgenden Kapitel abzugrenzen.
6.5.2 Implementierungskonzept
Das Ziel der Implementierung muss sein, eine Bibliothek zu erstellen, die eine
Grundfunktionalität in Bezug auf die Interpretation von XForms-Dokumenten bietet.
Eine solche Funktionalität zeichnet sich dadurch aus, dass sie einfache Benutzeroberflächen
fehlerfrei umsetzen kann. Neben der Analyse und reinen Synthese der GUI ist insbesondere
von Bedeutung, die zugrundeliegenden Abläufe, also Processing Cycle und Eventing mit
Eventhandlern zur Verfügung zur stellen.
Diese Mechanismen sind von höchster Priorität, da eine Nachimplementierung aufgrund der
strukturellen Verflechtung der benötigten Klassen und Methoden nur schwer zu bewältigen
wäre.
- 56 -
Von mittlerer Priorität ist dagegen, dass funktionelle Gruppen (Actions, Events, Controls)
jeweils durch typische Elemente vertreten sind, um die Einbettung in die Architektur zu
zeigen und damit ein Muster für die Nachimplementierung zu bieten.
Von geringer Priorität sind Aspekte, die den Komfort der Arbeit mit einer Benutzeroberfläche
betreffen. Diese können ohne Funktionseinbußen außer Acht gelassen werden. Auch
Elemente des Hostformates werden aus gleichem Grund vernachlässigt.
6.5.3 Durchgeführte Implementierung
Die Umsetztung des Implementierungskonzeptes ist detalliert in einem gleichnamigen
Dokument auf der beigefügten CD dokumentiert.
6.5.4 Erweiterung um Grundelemente
Die fehlenden in XForms spezifizierten Elemente können nachimplementiert werden, um den
Funktionsumfang des Interpreters zu erweitern.
Die betreffenden Elemente sind in der Implementierung vorgesehen, d.h. es existieren
Klassen- und Methodenrümpfe, die helfen, die benötigten Informationen über ein Element
zusammenzutragen. Im Gegensatz zu der Erweiterung um neue Elemente ist eine
Veränderung der aktuellen Methoden grundsätzlich nicht nötig.
Für die Implementierung eines Elementes aus einer der drei Gruppen sind die jeweilig
vorhandenen Elemente zu beachten. Diese geben Anhaltspunkte für die entsprechende
Erweiterung.
6.5.5 Erweiterung um neue Elemente
Die Möglichkeit, eigene XForms-Elemente zu definieren, und die Weiterentwicklung des
XForms-Standards können es unter Umständen nötig machen, die Bibliothek um neue
Elemente zu erweitern. Diese Erweiterung kann sich an den vorhandenen Elementen
orientieren, erfordert jedoch die Einführung neuer Klassen.
Im Folgenden soll beispielhaft die Ergänzung um eine neue XFControl erklärt werden. Dies
geschieht vor dem Hintergrund des Feinentwurfes und bezieht sich auf
Implementierungsdetails.
- 57 -
Eine neue Control erfordert zu allererst eine Klasse, die die Klasse XFControl im Package
controls erweitert. Die Klasse kann dann durch spezifische Attribute und Elemente ausgebaut
werden.
Damit ist der Container für das Element gegeben. Nun muss die Verankerung in der Analyse
und Synthese druchgeführt werden. Zunächst muss dazu die Analysisklasse modifiziert
werden. Die Methode analyseXFUnit ist so anzupassen, dass das Element am Namen erkannt
wird. Als nächstes muss eine neue Methode vom Stil der anderen analyseXFControl
Methoden implementiert werden, die die genaue Analyse in Bezug auf die spezifischen
Attribute und Kindelemente vornimmt.
Schließlich ist die Synthese des Elementes zu definieren. Dazu wird die Methode
buildControls der Synthesis-Klasse um die Verarbeitung des Containers ergänzt. Als letztes
muss nun einen neue Methode vom Typ buildXFControl bereitgestellt werden. Diese hat die
Aufgabe, dem Element ein Java Swing Äquivalent zuzuweisen und die Eigenschaften des
Elementes darauf zu übertragen.
6.5.6 Änderung der Komponenten
Änderungen an den kompletten Komponenten können zu Testzwecken und Erweiterungen
des Funtionsumfanges notwendig werden. Dabei lassen sich zwei Gruppen unterscheiden,
einerseits die implementierten Komponenten, wie im Grobentwurf beschrieben, und
andererseits die beiden Fremdbibliotheken.
Die Kernkomponenten aus dem Package core sind jeweils in Interfaces definiert. Der Director
verwendet als einzige Klasse die konkreten Implementierungen. Eine neue Klasse, die eine
core-Komponente ersetzen soll, muss also lediglich das jeweilige Interface implementieren.
Um für die Interpretation verwendet zu werden, hat der Director weiterhin die Aufgabe, sie zu
assoziieren. Weitere manuelle Änderungen der abhängigen Komponenten sind aufgrund des
Designs nicht erforderlich.
Der komplette Wechsel der XPath Bibliothek ist, wie in Kapitel 5.2.4 erläutert, nicht
vorgesehen. Muss dennoch ein Wechsel stattfinden, ist es nötig, alle Referenzen auf JaxenKlassen manuell zu ändern.
Der Wechsel des Parsers hingegen ist leicht möglich, es müssen lediglich die Referenzen in
der Directorklasse angepasst werden. Ein Wechsel des Parsers kann vorteilhaft sein, da ein
Parser eine sogenannte Whitespaceunterstützung besitzen kann. Diese Funktion erlaubt es,
leere Textknoten von Elementen automatisch entfernen zu lassen. Ist diese Funktion nicht
vorhanden, werden leere Textknoten als Kinder der Elemente angehängt und erschweren so
die Navigation in einem DOM-Dokument.
Die verwendete Bibliothek Xerces bietet diese Funktion leider nicht, so dass an einigen
Stellen des Codes diese Whitespace-Knoten extra behandelt werden mussten. Im Falle der
Benutzung einer neuen Parserimplementierung können diese Stellen vereinfacht werden, falls
der Parser diese Funktion bietet. Die Stellen sind dazu mit einem speziellen Kommentar
versehen worden, um zu kennzeichnen, dass ein Parserwechsel an diesen Stellen Vorteile
hätte. Die verwendete Markierung ist: Whitespace (WS).
- 58 -
7. Zusammenfassung und Ausblick
Das Ziel der Arbeit war es, eine Java Swing Interpreter Bibliothek für XForms zu entwerfen
und zu implementieren.
In der Aufgabenstellung wurde die Interpreter Bibliothek als eine Komponente definiert, die
verwendet wird, um eine Anwendung um eine Schnittstelle zu Web Services zu erweitern.
Diese Schnittstelle sollte durch die Interpretation von in XForms beschriebenen
Benutzeroberflächen in Java Swing realisiert werden. Dabei war anzunehmen, dass in diesem
Szenario der gleichzeitige Zugriff auf mehrere solcher Web Services stattfinden kann (SOAs),
die Bibliothek also die entsprechende Funktionalität bieten muss.
In der Arbeit wurde diskutiert, wie eine so beschriebene Bibliothek beschaffen sein kann.
Angefangen bei der Untersuchung der XForms-Technologie und dem Vergleich zwischen den
dort beschreibbaren Benutzeroberflächen mit solchen aus Java Swing wurde ein Konzept zur
Realisierung erläutert. Es wurde ein Entwurf vorgestellt, erläutert und begründet, der dieses
Konzept erfüllt und als Anleitung für die Implementierung der Bibliothek diente. Weiterhin
wurden Informationen zum Betrieb der Bibliothek dargelegt. Schließlich wurden die Art der
möglichen Erweiterungen, ihre Durchführung und der Funktionsumfang der vorliegenden
Implementierungen dargelegt.
Die aus diesem Entwurf hervorgegangene Implementierung der Bibliothek erlaubt die Arbeit
mit grundlegenen Benutzeroberflächen und bietet der einbindenden Applikation die
Möglichkeit, diese zu koordinieren und unabhängig vom Interpretationsvorgang flexibel zu
erweitern. Um die Interpretation von komplexeren in XForms beschreibbaren
Benutzeroberflächen zu gewährleisten, bedarf die Bibliothek der Erweiterung. Erweiterungen
sind aufgrund der Architektur verhältnismäßig einfach durchführbar.
Das Potential von XForms ist aufgrund seiner Leistungsfähigkeit und der Nachteile seines
Vorgängers enorm hoch. Auch Web Services sind aufgrund der breiten Akzeptanz bereits sehr
beliebt. Der Ansatz, diese beiden Bereiche zu verbinden und mit XForms Web ServiceSchnittstellen zu erzeugen, wird durch die XML-Technologie ermöglicht. Eine Anwendung,
die diese Schnittstellen durch Einsatz einer Bibliothek nutzen kann, ist in der Lage, einen
großen Funktionsumfang zu bieten. Als Basis für eine solche Bibliothek leistet die hier
vorgenommene Implementierung gute Dienste.
- 59 -
8. Literaturverzeichnis
[1] W3C XForms 1.0 (Second Edition):
http://www.w3.org/TR/2005/PER-xforms-20051006/
[2] XForms Essentials, Micah Dubinko, O’Reilly, 2003
[3] W3C XML 1.0 (Zweite Auflage, deutsche Übersetzung):
http://www.edition-w3c.de/TR/2000/REC-xml-20001006/
[4] Google Web API: http://www.google.com/apis/
[5] XForms – XML Powered Web Forms, T.V. Raman, Addison-Wesley, 2004
[6] Design Patterns – Java Workbook, Steven John Metsker, Addison-Wesley, 2002
[7] Java und XML, 2. Auflage, Brett Laughlin, O’Reilly, 2002
[8] XML Schema Part 0: Primer Second Edition:
http://www.w3.org/TR/xmlschema-0/
[9] XML Path Language (XPath) Version 1.0:
http://www.w3.org/TR/1999/REC-xpath-19991116
[10] Xerces2 Java XML-Parser homepage: http://xerces.apache.org/xerces2-j/
[11] XML kompakt: Die wichtigsten Standards, Thilo Rottach / Sascha Groß, Spektrum
akademischer Verlag GmbH, 2002
[12] XSmiles Browser homepage: http://www.xsmiles.org/
[13] XForms Extension für den Firefox Browser:
http://www.mozilla.org/projects/xforms/
[14] Java Swing Kalender-Komponente, homepage: http://www.java-calendar.com/
[15] Jaxen, universal Java XPath engine: http://jaxen.codehaus.org/index.html
- 60 -
A. Anhang
A.1. Beispiele für die Intepretation und Anwendung
Um die Leistungsfähigkeit des Interpreters zu demonstrieren und Anwendungsfälle zu zeigen,
führt dieses Kapitel die Anwendung der Bibliothek an zwei Beispielen vor.
Beispiel 1: Interaktive GUI
Dieses Beispiel zeigt die Fähigkeit der Bibliothek, ein XForms Dokument mit einer DirectorInstanz zu interpetieren und dabei Bezug auf die Model Item Properties zu nehmen. Zudem
wird die Arbeit mit der GUI erläutert.
Folgendes Dokument repräsentiert eine GUI mit voneinander abhängigen Elementen und
bedingungsgesteuerter Anzeige:
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms">
<head>
<xf:model>
<xf:instance xmlns="">
<math>
<number1>12</number1>
<number2/>
<result/>
<info>Pretty large number</info>
</math>
</xf:instance>
<xf:bind id="b" ref="/math/result" calculate="/math/number1 +/math/number2"/>
<xf:bind id="b1" ref="/math/info" relevant="/math/result > 1000"/>
<xf:submission action="http://www.example.com" method="put" id="s0"/>
</xf:model>
</head>
<body>
<xf:input ref="/math/number1">
<xf:label>Number 1</xf:label>
</xf:input>
<xf:input ref="/math/number2">
<xf:label>Number 1</xf:label>
</xf:input>
<xf:output bind="b1">
<xf:label>Sum</xf:label>
</xf:output>
<xf:output bind="b2">
<xf:label>Info</xf:label>
</xf:output>
<xf:submit submission="s0">
<xf:label>Submit</xf:label>
</xf:submit>
</body>
</html>
- 61 -
Die Bilder zeigen wie die GUI in einer Anwendung dargestellt wird.
Das Bild zeigt die GUI direkt nach der
Interpretation. Hier kann man sehen, dass
der Initialwert übernommen worden ist.
Zudem wird bereits die calculate property
ausgewertet, liefert jedoch noch keine
Zahl (NaN = Not a number).
Bei Eingabe der zweiten Zahl wird die
Summe berechnet und im Output-Feld
angezeigt. Dabei wird der richtige
Datentyp unterstützt
Die nun eingegebene Zahl macht die
Summe größer als 1000, die Bedingung
für die Darstellung des Infofeldes wird
erfüllt und das entsprechende Element
angezeigt.
- 62 -
Nach der Betätigung des Submitbuttons wird das XML-Dokument mit den eingegebenen
Daten an die Anwendung übergeben. Diese kann es dann zum Server weiterleiten, oder eine
andere in der Submission definierte Aktion ausführen.
Das enstandene Dokument ist das folgende.
<?xml version="1.0" encoding="UTF-16"?>
<math>
<number1>12</number1>
<number2>997</number2>
<result>1009</result>
<info>Pretty large number</info>
</math>
- 63 -
Beispiel 2: Verwaltung von GUIs
Das folgende Beispiel zeigt die Einbettung von mehreren interpretierten Benutzeroberflächen
in einem Fenster der Anwendung. Folgende Dokumente wurde dafür interpretiert.
Folgendes Dokument spezifiziert eine Login Benutzeroberfläche:
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms">
<head>
<xf:model>
<xf:instance xmlns="">
<login>
<info>Login</info>
<username/>
<password/>
</login>
</xf:instance>
<xf:submission action="http://www.example.com" method="put" id="s0"/>
</xf:model>
</head>
<body>
<xf:input ref="/login/username">
<xf:label>Username</xf:label>
</xf:input>
<xf:secret ref="/login/password">
<xf:label>Password</xf:label>
</xf:secret>
<xf:submit submission="s0">
<xf:label>Submit</xf:label>
</xf:submit>
</body>
</html>
- 64 -
Weiterhin wird von einer zweiten Director-Instanz nachfolgendes XForms Dokument
interpretiert. Es beschreibt eine einfache GUI zur Umrechnung der Einheit PS in KW.
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms">
<head>
<xf:model>
<xf:instance xmlns="">
<Leistung>
<PS>1</PS>
<KW/>
</Leistung>
</xf:instance>
<xf:bind id="b" ref="/Leistung/KW" calculate="/Leistung/PS * 0.7356" />
</xf:model>
</head>
<body>
<xf:input ref="/Leistung/PS">
<xf:label>PS</xf:label>
</xf:input>
<xf:output bind="b">
<xf:label>KW</xf:label>
</xf:output>
</body>
</html>
Die Anwendung lässt beide XForms-Dokumente von der Bibliothek interpretieren und kann
dann ihre Anordnung verwalten. In diesem Beispiel wurde die Anwendung so konfiguriert,
dass zunächst die Ergebnisse der ersten GUI abgeschickt und validiert werden müssen, damit
die zweite aktiviert wird.
Die folgenden Bilder illustrieren dies:
Auf der linken Seite befindet sich
die erste interpretierte GUI, auf der
rechten die zweite. Letzere kann
noch nicht benutzt werden, da die
Useridentifikation über die erste
noch nicht erfolgt ist.
- 65 -
Die Useridentifikation hat
stattgefunden, ein Server hat dies
validiert und die zweite GUI kann
deshalb verwendet werden. Die
erste wird nicht mehr benötigt und
deaktiviert.
- 66 -
A.2. Erklärung
Hiermit versichere ich, dass ich die vorliegende Bachelorarbeit selbständig und ohne fremde
Hilfe verfasst und keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel
verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keinem anderen
Prüfungsamt vorgelegen.
Hannover, den 20. Februar 2006
____________________
Lukas Klejnowski
- 67 -