XML Editing Tool

Transcrição

XML Editing Tool

HTBLA Salzburg
Höhere Lehranstalt für Elektronik
Ausbildungsschwerpunkt Technische Informatik
DIPLOMARBEIT
XML Editing Tool
Ausgeführt im Schuljahr 2007/8 von:
Jürgen Leobacher, 5AHELI-Tb16
Martin Planer, 5AHELI-Tb20
Betreuer:
Prof. Mag. Dr. Anton Hofmann
Diplomarbeit
XML Editing Tool
Inhaltsverzeichnis
1 Abstract
3
2 Solution
3
2.1
2.2
2.3
2.4
Application modules . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Web UI . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
XML upload . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.3
XML editing interface . . . . . . . . . . . . . . . . . .
5
2.1.4
XSD to Cocoon files transformer . . . . . . . . . . . .
6
2.1.5
Output Handling . . . . . . . . . . . . . . . . . . . . .
7
Call-Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1
/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2
/editing interface . . . . . . . . . . . . . . . . . . . . .
7
2.2.3
/output . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.4
/transform . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.5
/webui . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1
Premises . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2
Installing XET . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3
Adding a user . . . . . . . . . . . . . . . . . . . . . . . 11
User documentation . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1
Web UI - Login . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2
Web UI - Uploading/Creating XML data . . . . . . . . 13
2.4.3
XML Editing Interface . . . . . . . . . . . . . . . . . . 14
2.4.4
Saving/Viewing . . . . . . . . . . . . . . . . . . . . . . 14
3 Verzeichnisse
Leobacher, Planer, 5AHELI HTBLA-Salzburg
15
1
Diplomarbeit
XML Editing Tool
Aufgabenstellung
Es soll eine webbasierte XML-Editorschnittstelle zur einfachen Bearbeitung
von XML-Metadaten entwickelt und für alle Kunden von Sony DADC bereitgestellt werden. Jedem Kunden ist eine benutzerdefiniert konfigurierbare
Website zur Verfügung zu stellen, in der er nach erfolgreicher Authentifizierung existierende Produkte in Form von XML-Daten laden oder neue Produkte erzeugen kann.
Durch einen modularen Aufbau des Systems wird die spätere Erweiterung
und Anpassung an Kundenbedürfnisse (Design, Layout, Sprache, etc.) erleichtert. Die Vielfalt der von den Kunden in ihren Unternehmen eingesetzten Betriebssystemen setzt die Kompatibilität mit den gängigsten Browsern
(Mozilla Firefox, Internet Explorer, Safari, etc.) voraus. Die Kundenspezifischen Parameter (Firmenname, interne Kundennummer, Sprache, XMLValidierungs-Schemata, etc.) sollen zentral in Java-Property-Dateien gespeichert werden.
Um das Problem der nicht wohlgeformten XML-Daten in den Griff zu bekommen, müssen alle vom Kunden eingegebenen Daten gegen das entsprechende
XML-Schema validiert und bei Falscheingabe eine Fehlermeldung erzeugt
werden.
Die Weiterverarbeitung der Produktinformationen in verschiedener Art und
Weise erfordert die Ausgabe in mehreren Dateiformaten (HTML, PDF, DOC,
XLS, etc.).
2
Diplomarbeit
XML Editing Tool
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbständig
und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten Quellen wörtlich und inhaltlich
entnommenen Stellen als solche erkenntlich gemacht habe.
Salzburg, am
——————————————
Jürgen Leobacher
——————————————
Martin Planer
3
Diplomarbeit
1
XML Editing Tool
Zusammenfassung
Da es für die Firma Sony DADC und deren Kunden bislang notwendig
war, Programme von Drittanwendern zur Bearbeitung von XML-Daten heranzuziehen, wurde das Projekt, eine Webapplikation zur Bearbeitung von
XML-Daten zu erstellen, vorgestellt. Der größte Nachteil der meisten XMLBearbeitungsprogramme, die auf dem Markt erhältlich sind, ist deren vorausgesetztes Wissen bezüglich XML-Datenstrukturen. Für Kunden, die mit
solchen Strukturen nicht vertraut sind, kann sich die Bearbeitung dieser Daten als umständlich und komplex erweisen.
Wir haben somit eine, den Wünschen von Sony DADC entsprechende, Editorlösung entwickelt, die im Browser ausgeführt wird, und somit von Kundenseite, außer einem Webbrowser, keine technischen Voraussetzungen (z.B.
installierte Software, Laufzeitumgebungen, etc.) erfordert. Die wichtigsten
Aspekte, die bei der Implementierung berücksichtigt worden sind, waren eine übersichtliche Benutzerführung und eine einfache Bearbeitung der XMLDaten.
Über den Anmeldevorgang am Beginn der Applikation authentifizieren sich
die verschiedenen Organisationen (Kunden), damit das Programm die kundenspezifischen Daten wie beispielsweise XSD-Dateien, die das eigentliche
XML-Produkt beschreiben, oder auch Kundenlogos, dynamisch, also von der
aktuellen Organisation abhängig, laden zu können.
Um die komplexe XML-Struktur so übersichtlich wie möglich auf eine dem
0-8-15-Benutzer gewohnte Ansicht abzubilden, werden die Daten verarbeitet
und in einer sogenannten Baumstruktur zur Anzeige gebracht. Mit dieser
können die verschiedenen Hierarchiestufen dargestellt werden, wobei, vergleichbar mit einem wirklichen Baum, jede Verzweigung für einen Hierarchiewechsel steht. Durch eigens vorgesehene Buttons können XML-Elemente
hinzugefügt beziehungsweise weggenommen werden.
Zur Entwicklung des Tools wurde das XML-Publishing-Framework der Apache Foundation, namens Cocoon, eingesetzt, das einige hilfreiche Funktionen,
wie beispielsweise automatische AJAX-Unterstützung, oder XML-Validierung,
automatisiert bereitstellt. Die Validierung, die nach jedem Absenden neuer
Daten ausgeführt wird, läuft ohne jegliche Einwirkung des Benutzers ab. Sollten eingefügte Datensätze nicht gültig sein, erscheint neben dem betroffenen
Element ein Ausrufezeichen, das durch dessen anklicken Informationen über
den Fehler ausgibt.
Cocoon selbst wird als Java-Servlet ausgeführt, und die Applikation wird,
4
Diplomarbeit
XML Editing Tool
samt Laufzeitumgebung, im Apache Tomcat Servlet-Container auf einem Server der Firma Sony bereitgestellt.
2
Abstract
Until now, Sony DADC and their customers had to use third party software
products to edit XML documents. Therefore the need for an easy-to-use
XML editing tool emerged. The main disadvantage of existing XML editing
tools is the need for knowledge about XML data structures. As customers of
Sony DADC hardly have this kind of knowledge, editing XML data can be
difficult and complex. Another withdraw of existing tools is often the need
for an installation on the computer of the end-user and therefore a higher
administration effort.
According to the specifications that were given to us by Sony DADC, we
created an editing solution that runs in a web browser and therefore eliminates the need for technical prequisites (installation, runtime environment,
etc.) other than a standard web browser. The main aspect that was taken
into account during the whole development process was usability by persons
without previous knowledge of XML.
As many different organizations should be able to use the tool independently,
the users are asked to authorize at the beginning of login window loads the
user-specific data (XML schema, logo, stylesheets) dynamically after the login
procedure.
To hide the complex XML structure from the end-user and display it in a
more familiar way, the tool uses a tree-view where each branch represents a
hierarchical level. Elements can be created or be removed by buttons inside
the tree-view.
The application was created using the XML publishing framework Cocoon
from the Apache Foundation. It contains several useful functions, e.g. AJAX
support or XML validation, that were helpful during the development process
that can run transparent to the user and only show notifications if something
went wrong.
Cocoon itself runs as a Java-Servlet in an Servlet-Container, e.g. Apache
Tomcat, that has been provided by Sony DADC.
5
Diplomarbeit
3
XML Editing Tool
Firmenvorstellung
Digital Content Services Software Engineering
Digital Works
A-5081 Anif, Sonystrae 20
Sony DADC hat langjährige Erfahrung in der Entwicklung individualisierter Anwendungen für die Audio-/Videoverwaltung und -lieferung, wobei wir
unsere Asset-Management-Anwendung verwenden, um Firmen erfolgreich zu
helfen, ihren Inhalt innerhalb einer kunden- und markenspezifischen Schnittstelle zu liefern.
4
Ist-Analyse
Digital Content Services stellt kommerziellen Kunden (meist Musiklabels)
Audio-/Video-Content inklusive deren Produktinformationen z.B. für den
Verkauf über das Internet zur Verfügung. Die Produkt-Metadaten liegen in
der Form von XML-Dateien den Mediendaten bei und beschreiben wichtige
Eigenschaften der Daten, wie zum Beispiel bei einer Audio-CD:
• Spieldauer
• enthaltene Musiktitel
• Künstler
• Genre
• Altersfreigaben
• Preis
• etc.
Sollen diese Daten geändert werden besteht bis jetzt nur die Bearbeitung über
externe Programme, zum Beispiel direkt in einem Texteditor. Da sich durch
die manuelle Bearbeitung sehr leicht Fehler, die eine weitere Verarbeitung
unmöglich machen, in die sensiblen Daten einschleichen, bedarf es genauer
Kenntnis über die Struktur der Daten und über XML im Allgemeinen.
6
Diplomarbeit
5
XML Editing Tool
Auswirkungen auf die Aufgabenstellung
Da die zur manuellen Bearbeitung benötigten Vorkenntnisse nicht von jedem vorausgesetzt werden können, sollen diese gänzlich eliminiert und die
Bedienung drastisch vereinfacht werden.
Die Daten sollen in einer einheitlichen, übersichtlichen und intuitiv zu bedienenden Oberfläche dargestellt werden, um diese auch von Laien bearbeitbar
zu machen.
6
Ziele
Ziel dieses Projektes ist die Erstellung eines webbasierten, einfachen Editors
zur Bearbeitung von XML-Dateien.
Über die Benutzeroberfläche müssen bestehende XML-Datensätze bearbeitet
und Neue eingefügt werden können.
Das Editieren is für mehrere Benutzer gleichzeitig zu ermöglichen und die
Einbindung von neuen Benutzern soll einfach möglich sein.
Der modulare Aufbau der Applikation soll eine einfache Erweiterbarkeit sicherstellen um das Programm in späteren Phasen um Funktionen, z. B.
Mehrsprachen- oder MS-Excel-Unterstützung, ergänzen zu können.
Das Aussehen der Seiten soll von den Benutzern selbst über Stylesheets angepasst und die benutzerspezifischen Parameter über Java-Property-Dateien
konfiguriert werden können.
Der Editor muss in allen gebräuchlichen Webbrowsern (Firefox, Safari, Internet Explorer) auf allen gebräuchlichen Plattformen (Mac OS, Windows,
Linux) fehlerfrei dargestellt und bedient werden können und soll keinerlei
zusätzliche Vorraussetzungen besitzen.
Alle Daten eines XML-Dokuments müssen vor dem Abspeichern gegen das
jeweilige XML-Schema auf Gültigkeit überprüft werden.
7
Nachvorschungen
Nachforschungen haben ergeben, dass es keine vergleichbaren Programme
gibt, die eine XML-Bearbeitung im Browser ausführen können. Bekannte
Applikationen, die XML-Daten bearbeiten können, wie beispielsweise XML
7
Diplomarbeit
XML Editing Tool
Spy, sind für Anwender die mit der XML-Datenstruktur nicht versiert sind,
zu schwer zu bedienen und läuft zudem nicht im Webbrowser. Dieser Zustand
gab den Anstoß, eine eigene Applikation zu entwickeln.
8
Lösungsvarianten
Um zu Entscheiden welche Technologie für die Realisierung des XML-Tools
zum Einsatz kommt, wurde eine Evaluation bereits vorhandener XML-Frameworks
vorgenommen. Diese wurden auf folgende Gegebenheiten überprüft:
• Open Source
• XML-Bearbeitung via HTML Forms
• XML-Validierung gegen XSD
• einfache Implementierungsmöglichkeiten
• Community
• Technologie up-to-date
Die Entscheidung fiel auf das Apache Cocoon Framework:
• umfangreiche Möglichkeiten
• modulare Struktur
• aktuelle Technologie
• Open Source
• flexible Schnittstellengestaltung möglich
Bei der Evaluation (siehe Technology Evaluation im Anhang) schien das
XML-Publishing-Framework Apache Cocoon, im Vergleich zu ähnlichen Frameworks, am umfangreichsten und deswegen geeignet für den Einsatz für das
XML Editing Tool.
8
Diplomarbeit
9
9.1
9.1.1
XML Editing Tool
Lösung/Solution
Organization
Schedule
9
Diplomarbeit
9.2
XML Editing Tool
Application modules
This section describes the technical realization of the modules in detail and
how they work together.
Abbildung 1: Module overview
9.2.1
Web UI
If the xml tool is used standalone the Web UI acts as superior interface
that supplies the XML editing interface with the XML product file using the
HTTP POST method.
The Web UI is realized with standard HTML technology, to offer sites for
several user groups/customers a stylesheet should be used. Further two logos,
one for Sony DADC and one for the customer, must be configurable for each
site.
12
Diplomarbeit
9.2.2
XML Editing Tool
XML upload
To edit XMLs the user can select an .xml file from the local hard drive.
When the user has chosen an XML file and confirmed he is redirected to
the XML editing interface which displays an html form with the data of the
XML file (create binding and load document Cocoon flowscript functions).
Only one single file can be chosen for editing, multiple files have to be edited
sequentially. Also no kind of merging two or multiple XMLs exists therefore.
The extension of files must be configurable and is set to .xml in the initial
phase.
The server part must run within Tomcat, the client part is integrated into the
Web UI sites. Embedding the application into an existing website happens
by including the XML upload by means of an iframe. The correct url to reach
it is [server]/xmlgt/webui/main/[organization].
9.2.3
XML editing interface
The XML editing interface is called with the parameter load (...editingpage/load) which is processed by the sitemap (Sitemap.xmap). This parameter
effects a call of the onload function in the flowscript (flow.js) with the product file (dynamic filename). First step by the function is creating a new
form by using a form definition file (formDefinition.xml) from the transformer. Last step ere redirecting back to the sitemap an xml filestream has to be
set up by the function loadXML with the product file as parameter. Now after the conditions for representing a dynamic XML editing page with apache
cocoon has been taken the onload function calls the sitemap with the function load ok. The load ok part implements the pretransformed formDefinition
and formTemplate files. After submitting the changed metadata values, the
flowscript is re-entered for saving the new XML file data onto the server.
Now that editing process is over, the output handler is called if all data is
valid against the formDefiniton file (equivalent to the XSD file). To prevent
a potential validation error executed by cocoon an additional validation step
against the actual XSD file is carried out.
13
Diplomarbeit
9.2.4
XML Editing Tool
XSD to Cocoon files transformer
Abbildung 2: Sequence diagram of transformation
14
Diplomarbeit
XML Editing Tool
Given that Cocoon uses its own format for defining forms (form files) a XSD
to form definition file and form template file transformer has to be developed.
To perform successful transformation make sure the XSD file is located at
xmlgt/transform/input with the username (name of organization) as filename
and the extension .xsd. If a form has to be created, the according XSD is
read, parsed and the matching form definition file and form Template file
is created and written to the server. These files may now be copied from
xmlgt/transform/output to xmlgt/editinginterface/resources/[username] to
make use of these files.
As XSDs can have rather complex rules the transformation has to consider
typical XSD types (e.g. XSD simple type / complex type) and rules (e.g.
min- and maxOccurence fields, data format restrictions, etc.).
9.2.5
Output Handling
Output of the XML editing interface is an XML containing the metadata
manipulated in the html form previously by catching it from the server.
For the initial phase this XML can be either downloaded or displayed in the
browser. In later project phases the output handler should handle alternative
formats (Excel, doc, pdf, etc.) and also allow redirection to a system like
Webservices.
9.3
9.3.1
Call-Paths
/
Simply calling / will redirect you to the webui an will show the login form.
9.3.2
/editing interface
The Editing-Interface is the main part of the XET project. Everything from
reading and loading the XML document and editing it up to runtime-validation
is taken place here.
/editing interface/new/[username]
the user-specific schema.
Creates an empty form based on
[username ] The username as used to login (same as the filename of the
corresponding properties-file)
15
Diplomarbeit
/editing interface/load/[username]/[xml-file]
file into a form for editing.
XML Editing Tool
Loads the given XML
[xml-file ] The name of the XML file in /uploads. The file has to exist before
calling this function.
9.3.3
/output
The Output-Handler is used to show the user a menu for showing or downloading the desired XML document. It also reverts some changes that were made
to the XML document by Apache Cocoon by applying some transformations
on it.
/output/[username]/[xml-file] Applies the transformations and shows
the user a menu to choose between showing and downloading the XML file.
It also validates the outgoing XML against it’s XSD and shows an error if
not valid.
/output/transform/[xml-file] Only applies the transformations and displays the output in the browser. This pipeline is only called internally and/or
for debugging.
/output/show/[xml-file] Displays the XML file directly in the browser.
As the transformations are only called by /output/[username]/[xml-file] and
/output/transform/[xml-file], one of these functions has to be called first in
order to get a valid XML file.
16
Diplomarbeit
XML Editing Tool
/output/download/[xml-file] Is used to download the XML file and save it on the harddisk. As the transformations are only called by /output/[username]/[xmlfile] and /output/transform/[xml-file], one of these functions has to be called
first in order to get a valid XML file.
/output/outputmenu/[username]/[xml-file] Only shows the user a
menu to choose between showing and downloading the XML file. As the transformations are only called by /output/[username]/[xml-file] and /output/transform/[xmlfile], one of these functions has to be called first in order to get a valid XML
file.
9.3.4
/transform
The Transformer is user to convert the xml schema definition to the equivalent file formats used by Apache Cocoon (form definition, form template).
/transform/[username] Applies the XSD =¿ formDefinition, formTemplate transformation to the file [username].xsd in /xsd and writes the output
to /transform/output.
/transform/[xsl]/[xsd]/[root-element] Applies the XSD =¿ formDefinition, formTemplate transformation to the file [xsd] and writes the output
to /transform/output using the specified XSL and starting with the given
root-element [root-element].
[xsl ] The XSLT file in /transform/resources that should be used for the
transformation.
17
Diplomarbeit
XML Editing Tool
[xsd ] The XSD file in /xsd that should be transformed.
[root-element ] The root-element of the given XSD where the transformation should start.
9.3.5
/webui
The Web-UI is used to authenticate a user and to display a menu to choose
between inserting a new XML file and editing an existing one.
/webui
Calls the login() function and displays the login form.
/webui/main/[username] Shows the main menu where the user can
choose between inserting a new XML file and editing an existing one.
9.4
9.4.1
Installation
Premises
To get XET up and running you will need the following:
• XET.war file (including Apache Cocoon)
• Apache Tomcat Servlet Container (Version 5.5.25 or higher recommended) or equivalent
9.4.2
Installing XET
Simply deploy the XET.war file to your Apache Tomcat Server like any other
Servlet using manual or auto deployment.
18
Diplomarbeit
9.4.3
XML Editing Tool
Adding a user
To successfully add a new user to the XET application you will need
• the XSD that validates the user-specific XML files
• access to the Tomcat webapps folder with writing permissions
Create a new properties file in der /properties folder called like the desired
username (e.g. sample.properties if the desired username is sample) and fill
the required lines. You can use the sample.properties file as a starting point
in creating a new properties file. More information about the required properties can be found in chapter ??.
Put the user-specific XSD file in the /xsd folder (note that the filename of
the XSD file and the XSD property in the properties file have to identical!).
Now the XSD file has to be transformed into the Cocoon-specific CForms
files by calling the /transform/::username:: path of the application (e.g.
http://localhost/xet/transform/sample for user sample). A message will show
up if the transformation process has been completed successfully. Create a
new folder with the name ::username:: in the /editing interface/forms folder
(e.g. /editing interface/forms/sample for user sample) and move the 3 files
that were generated by the transformer from /transform/output to this new
folder.
The new user should now be ready to be used.
9.5
User documentation
In this chapter a full interaction cycle that the user executes while using the
application is simulated. Every part is described so that the user knows how
and why several steps ought to be taken.
19
Diplomarbeit
9.5.1
XML Editing Tool
Web UI - Login
Abbildung 3: Login Screen
After entering the appropriate URL (to reach the XML Editing Tool) a login dialog appears. Two user specified properties are needed, and should be
inserted in the available text boxes:
• User name Equivalent to the name of the organization.
• Password Generally the user name will do. If required, insert your
password too.
20
Diplomarbeit
9.5.2
XML Editing Tool
Web UI - Uploading/Creating XML data
Abbildung 4: Uploading/Inserting Screen
Provided that all inserted user data matches the correct patterns, the user is
forwarded to the so called XML Uploading/Creating page. Two options are
offered, to either create a new file by clicking the Insert button, or to edit
an existing file by clicking the designated Edit button.
If the Edit option was chosen, a file dialog occurs to upload an existing XML
file from the local hard drive. In case of the Insert option, the user is directly
forwarded to the XML Editing Interface.
21
Diplomarbeit
9.5.3
XML Editing Tool
XML Editing Interface
Abbildung 5: Editing Interface
The conventional XML data structure may be a bit unclear and confusing in
some respect. Therefore the hierarchical structure of XML data is illustrated
as tree view to provide a clearly arranged view at the data. Adding or removing elements is just as easy as clicking on the provided Add ’Element’ and
Remove ’Element’ button respectively. After deciding to save changed data
by clicking the Save button a data validation against the specified XSD is
carried out. In case of an inserted entity is invalid an exclamation occurs to
the right of the text box. To receive information about the error just click
on it. A blue asterisk beside a text box indicates that the XML element is
required and therefore must contain data.
9.5.4
Saving/Viewing
After successfully editing existing XML files or inserting a new one, the user
gets offered the choice to download the new XML file or just to view it in the
browser. As the name of each button suggests, clicking Download effects a
file download and Display illustrates the produced XML data in the browser.
22
Diplomarbeit
XML Editing Tool
The third button named Back to home redirects to the Inserting/Uploading
page to give chance for editing or creating another XML file.
10
Ertrag
Während der Entwicklung des hier vorliegenden Projekts haben wir sehr
viel wertvolle Erfahrung für den Ablauf eines Projekts mit dieser Größe im
Allgemeinen gesammelt. Auch die Zusammenarbeit mit einer großen Firma
wie Sony DADC gab uns Einblick in die internen Strukturen und Abläufen
in wirtschaftlichen Unternehmen und zeigte uns Differenzen zwischen diesen
und den in der Schule Gelernten auf.
Die Verwendung des XML-Publishing-Frameworks Cocoon war, im Nachhinein betrachtet, wahrscheinlich nicht die Beste. Die Eigenheiten dieses Produkts (spezielle XML-Struktur zur Verwendung von Repeatern nötig, Transformation von XSD auf Cocoon-spezifische Formate nötig, etc.) sind nur
durch Umwege (z.B. wie in unserem Fall durch unzählige XSL-Transformationen)
in den Griff zu bekommen und behindern den Fluss der Entwicklung.
Die Dokumentation des Cocoon-Frameworks ist leider dürftiger als es auf den
ersten Blick aussieht. Die einzigen brauchbaren Quellen, die zur Entwicklung
herangezogen werden können, sind die (sehr oberflächliche,) offizielle Dokumentationswiki1 , das Buch ”Cocoon 2 und Tomcat”2 von Stephan Niedermeier, das Cocoon-Tutorial3 desselben Autors sowie das Cocoon-Forum4 .
Alles was über die Grundlagen hinausgeht, muss mühselig selbst erarbeitet
werden. Die Fehlersuche gestaltet sich, aufgrund des fehlenden Debuggers
für die Pipelines (es existiert nur ein Flowscript-Debugger, den uns nie eine
wirkliche Hilfe war), zur Suche nach der Nadel im Heuhaufen.
Bei einer neuen Entwicklung in diesem Tätigkeitsfeld würden wir nicht mehr
auf Cocoon, sondern auf weiter verbreitete Frameworks und Programmiersprachen zurückgreifen (Java Servlets, Google Web Toolkit, Ruby on Rails,
...).
1
http://cocoon.apache.org/2.1
Niedermeier 2006: Stephan Niedermeier, Cocoon 2 und Tomcat: XML-Publishing mit
dem Open-Source-Framework. (Galileo Press 2006)
3
http://cocoontutorial.logabit.com/
4
http://www.cocoonforum.de/
2
23
Diplomarbeit
11
XML Editing Tool
Verzeichnisse
Abbildungsverzeichnis
1
Module overview . . . . . . . . . . . . . . . . . . . . . . . . .
4
2
Sequence diagram of transformation . . . . . . . . . . . . . . .
6
3
Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4
Uploading/Inserting Screen . . . . . . . . . . . . . . . . . . . 13
5
Editing Interface . . . . . . . . . . . . . . . . . . . . . . . . . 14
24
Diplomarbeit
12
XML Editing Tool
Anhang
Alle hier aufgelisteten Dateien liegen der Diplomarbeit, am Ende hinzugefügt,
bei.
12.1
Vertiefende Arbeiten
• Google Web Toolkit
• XML und Datenbanken
12.2
Meeting Minutes/Report
• XML Generation Tool Meeting Minutes 20071113
12.3
Weekly Report
• XML Generation Tool Weekly Report KW05
12.4
Technology Evaluation
• XML Tool Technology Evaluation
12.5
Requirements
• XML Generation Tool Requirements v1.0
25
HTBLA Salzburg
DIPLOMARBEIT
Google Web Toolkit
Ausgeführt im Schuljahr 2007/8 von: Jürgen Leobacher, 5AHELI-Tb16
Betreuer: Prof. Mag. Dr. Anton Hofmann
Diplomarbeit
Google Web Toolkit
Inhaltsverzeichnis
1 Einleitung
6
2 Einführung ins GWT
6
3 Benutzerschnittstelle
7
3.1
Widgets und Panels . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Widgets selber schreiben . . . . . . . . . . . . . . . . . . . . . 10
3.2.1
Composite . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2
Neues Widget . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3
Styles mit CSS . . . . . . . . . . . . . . . . . . . . . . 13
4 Architektur
4.1
15
Debugging und Deployment . . . . . . . . . . . . . . . . . . . 15
4.1.1
Hosted Mode . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2
Web Mode . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3
Java-to-JavaScript Compiler . . . . . . . . . . . . . . . 15
5 Applikationsentwicklung
5.1
16
Remote Procedure Calls . . . . . . . . . . . . . . . . . . . . . 16
5.1.1
5.2
7
RequestBuilder . . . . . . . . . . . . . . . . . . . . . . 16
Performanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1
Startzeit . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2
Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3
Commandlinetools . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4
Projektverzeichnisstruktur . . . . . . . . . . . . . . . . . . . . 21
5.5
Codebeispiel - Einfaches Tutorial . . . . . . . . . . . . . . . . 21
5.5.1
Projektsourcen erzeugen . . . . . . . . . . . . . . . . . 22
5.5.2
Projekt in Eclipse laden . . . . . . . . . . . . . . . . . 23
5.5.3
Style hinzufügen . . . . . . . . . . . . . . . . . . . . . 29
5.5.4
Am Webserver bereitstellen . . . . . . . . . . . . . . . 32
Jürgen Leobacher, 5AHELI
HTL Salzburg
1
Diplomarbeit
Google Web Toolkit
6 Pizzaprogramm
34
6.1
Programmbeschreibung . . . . . . . . . . . . . . . . . . . . . . 34
6.2
Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3
Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4
6.3.1
MeinRadioPanel
. . . . . . . . . . . . . . . . . . . . . 36
6.3.2
Zusatzbelag (CheckBox) . . . . . . . . . . . . . . . . . 37
6.3.3
Zahlungsart . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.4
Bestellung abschicken . . . . . . . . . . . . . . . . . . . 40
Style verpassen . . . . . . . . . . . . . . . . . . . . . . . . . . 45
HTL Salzburg
2
Diplomarbeit
Google Web Toolkit
1
Widgets-Liste . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2
Panels-Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3
Daten/Code-Zyklus . . . . . . . . . . . . . . . . . . . . . . . . 18
4
Basisverzeichnisstruktur . . . . . . . . . . . . . . . . . . . . . 21
5
ProjectCreator . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6
ApplicationCreator . . . . . . . . . . . . . . . . . . . . . . . . 22
7
Projektimport . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8
Importdialog
. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9
Importdialog
. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10
Applikationsgerüst . . . . . . . . . . . . . . . . . . . . . . . . 26
11
Compilieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12
GWT-Browser Hosted Mode . . . . . . . . . . . . . . . . . . . 29
13
Hinweisfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14
Neue Datei anlegen . . . . . . . . . . . . . . . . . . . . . . . . 30
15
Dateidialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16
GWT-Browser Hosted Mode . . . . . . . . . . . . . . . . . . . 32
17
Java-to-JavaScript compilieren . . . . . . . . . . . . . . . . . . 32
18
Applikation im Safari-Browser . . . . . . . . . . . . . . . . . . 33
19
Programm ohne Style . . . . . . . . . . . . . . . . . . . . . . . 45
20
Programm mit Style . . . . . . . . . . . . . . . . . . . . . . . 47
HTL Salzburg
3
Diplomarbeit
Google Web Toolkit
Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbständig
Salzburg, am
——————————————
Jürgen Leobacher
HTL Salzburg
4
Diplomarbeit
Google Web Toolkit
Abstract
As the web and its enormous scope of use is spreading so fast these days,
modern web frameworks are gaining popularity. Their aim is to provide developers with easy-to-use programming tools for intuitive user interface design.
The key element of modern web technology is AJAX, which is an acronym
that stands for Asynchronous JavaScript and XML, and is frequently implemented in this kind of frameworks. This fact makes it hard to differentiate
between relevant frameworks that are worth considering in conjunction with
successfully creating web applications. The Google Web Toolkit (GWT) is
a prime example in terms of reducing the costs of writing highly sophisticated browser applications. Therefore the focus of the present document lies
on the technical implementation of Google’s web developing tools. Reading
this document requires no previous knowledge about the GWT. In fact, an
understanding of Java programming and the basic internet infrastructure
(HTTP-Protocol, Webserver, HTML/CSS, XML etc.) is taken for granted.
The toolkit itself basically comprises of the actual framework and a banner
cross compiler. The framework supplies developers with a bunch of functions,
methods, APIs and reusable UI components that are capable of automating
AJAX implementation. Google’s Java-to-JavaScript compiler converts Java code into compact JavaScript. The benefits of applying JavaScript are
its minimalistic resource requirements and the automatic cross browser support. Furthermore a full life cycle of creating, programming and deploying
a GWT project from scratch will be simulated. Since developers are writing
in Java they may use their favorite IDE like Eclipse or NetBeans with fullfeatured debugging and unit testing support. Preventing memory leaks and
redundant server calls (RPC) is of utmost significance. In return a paragraph
about performance prevents web developers from programming error-prone
and inefficient routines.
HTL Salzburg
5
Diplomarbeit
1
Google Web Toolkit
Einleitung
Da sich der Einsatz von Webtechnologien zur Applikationsgestaltung in der
letzten Zeit immer mehr verbreitete, haben Frameworks, wie beispielsweise
das Google Web Toolkit, die Entwicklern bei der Softwareentwicklung unter
die Arme greifen sollten, an Interesse gewonnen. War vor wenigen Jahren
der Einsatz von purem HTML noch ausreichend, sind aktuelle, moderne
Webframeworks in ihrem Umfang bereits mit Frameworks für Desktopanwendungen vergleichbar. In der vorliegenden Arbeit wird, wie es der Titel
schon vermuten lässt, das Web-Toolkit von Google, mit dem unter anderem
die bekannte Webapplikationen Google Maps entwickelt worden ist, näher in
dessen Möglichkeiten zur intuitiven Webgestaltung beleuchtet.
2
Einführung ins GWT
Das Google Web Toolkit (GWT) ist, allgemein gesprochen, darauf ausgelegt die AJAX-Programmierung zu vereinfachen. AJAX (Asynchronous JavaScript and XML) macht aus einem passiven Webbrowser, der HTMLSeiten parst und anzeigt, eine intelligente JavaScript interpretierende Software, die durch dessen Implementierung die Ausführung von anspruchsvollen Webapplikationen erlaubt. Ohne AJAX führt jede Statusänderung der
Webseite zu einem vollständigen Neuladen der Seite, und ein Verlaufseintrag
wird angelegt, der es dem Benutzer ermöglicht, vergangene Zustände durch
den Zurückbutton des Browsers abzurufen. Genau dort setzt AJAX an und
konstatiert: ’Verwende nie den Zurückbutton!’. In dem praktischen Anwendungsbeispiel einer Onlinetransaktion wird es klar, warum das Verwenden
des Zurückbuttons dem Anwender zum Nachteil gereicht. Wird der Auftrag
zu bezahlen gegeben, folgt dem ein komplettes Neuladen der Seite. Angenommen der Browser bleibt nun genau zwischen dem Zeitpunkt vom Absenden
der Daten und der geladenen, folgenden Seite stecken, oder der Webserver ist
überlastet, dann kann das Klicken auf ’Zurück’ dazu führen, dass die Transaktion wiederholt ausgeführt wird. Theoretisch sollte es derartige Probleme
bei mit AJAX-Technologie entwickelten Webapplikationen nicht geben, da
der Status der Website nun clientseitig ausgeführt wird, indem bloß der sich
ändernde Teil der Website in Form von XML-Daten mittels JavaScript zum
Server geschickt wird. Dies ist dann ein sogenannter XML-HTTP-Request1 .
Somit werden aufwendige Operationen, die normalerweise der Server, der
mit HTTP angesprochen wird, ausführen müsste, auf des Clients System
1
http://www.w3.org/TR/XMLHttpRequest/
HTL Salzburg
6
Diplomarbeit
Google Web Toolkit
übertragen. Ein vorteilhafter Nebeneffekt dabei ist eine Echtzeitinteraktion
mit dem Benutzer, die bei Webapplikationen lange ersehnt war. GWT ist
also ein Framework um Browserapplikationen vollständig in Java, mit allen
gewohnten Tools und Klassen, ohne manuell JavaScript schreiben zu müssen,
zu entwickeln. Möglich ist dies durch einen Crosscompiler, der den Java-Code
in eine JavaScript Anwendung übersetzt, die nun ohnehin von allen gängigen
modernen Browsern interpretiert werden kann. Der Unterschied zu JavaApplets dabei ist, die fehlende Notwendigkeit einer, am Client installierten Java
Virtual Machine, die Java-Code interpretiert und ausführt.
3
Benutzerschnittstelle
3.1
Widgets und Panels
Die Widgets2 des GWT enthalten alle bekannten HTML-UI-Elemente (UI=
Userinterface), wie beispielsweise eine Listbox, Textbox, Button, Checkbox,
etc. Den Entwicklern des Frameworks war es wichtig alle HTML-Widgets zu
belassen, und nur dann Neue zu implementieren, wenn diese wirklich die Benutzerfreundlichkeit verbessern. Der Unterschied zu ähnlichen UI-Frameworks
wie SWING3 oder SWT4 ist, dass die Oberfläche mit dynamischem HTML
statt mit Pixelgrafiken erzeugt und dargestellt wird.
Dies bewirkt eine Betriebssystem native Darstellung, sofern der Browser dies
unterstützt. Die Liste der Widgets und Panels, die in der GWT user-interface
library integriert sind, ist groß und sollte den Webentwicklern alles Notwendige für eine benutzerfreundliche Schnittstelle zur Verfügung stellen.
2
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.
DeveloperGuide.UserInterface.html
3
http://java.sun.com/javase/6/docs/technotes/guides/swing/
4
http://www.eclipse.org/swt/
HTL Salzburg
7
Diplomarbeit
Google Web Toolkit
(a) Button
(b) RadioButton
(c) PushButton
(d) ToggleButton
(e) TextBox
(f) CheckBox
(g) PasswordTextBox
(h) TextArea
(i) Hyperlink
(j) ListBox
(k) MenuBar
(l) Tree
(m) Table
(n) TabBar
(o) DialogBox
Abbildung 1: Widgets-Liste
HTL Salzburg
8
Diplomarbeit
Google Web Toolkit
(a) PopUpPanel
(b) StackPanel
(c) HorizontalPanel
(d) VerticalPanel
(e) FlowPanel
(f) VerticalSplitPanel
(g) HorizontalSplitPanel
(h) DockPanel
(i) TabBar
Abbildung 2: Panels-Liste
Neben den Widgets bestehen, wie ersichtlich, sogenannte Panels. In Panels ,
vergleichbar mit Containern der Java-Swing-Library, können Widgets gegeben werden, und dienen eher dem Layout, als der eigentlichen Benutzerinteraktion.
HTL Salzburg
9
Diplomarbeit
3.2
Google Web Toolkit
Widgets selber schreiben
Ein Widget basiert also auf einem UI-Object (bezogen auf das DOM5 ), das
als Basisklasse dient, und unterscheidet sich prinzipiell bloß darin, dass es
zusätzliche Funktionalitäten, wie ein anderes Aussehen oder wenn man eine
Textbox betrachtet, eine Funktion besitzt, die mögliche Textboxwerte anzeigt. Will man nun selber ein Widget schreiben, gibt es grundsätzlich zwei
Ansätze dies zu realisieren. Man kann entweder die Composite-Funktionalität
des GWTs verwenden, mit der aus bereits vorhandenen Widgets ein eigenes
erstellt werden kann, oder man erzeugt eines, das auf keinem bestehenden
Widget basiert. Mit der zuletzt erwähnten Methode sind beispielweise alle
Basis-Widgets des GWTs implementiert worden.
3.2.1
Composite
Ein Composite, das selbst ein Widget ist, erlaubt es eigene Widgets und
Panels zu erstellen. Dies geschieht durch das Zusammenfügen bereits vorhandener Widgets.
Code 1 Composite-Beispiel
class MeinComposite extends Composite {
private FlowPanel pan = new FlowPanel ( ) ;
private Label lbl = new Label ( ) ;
private TextBox tbox = new TextBox ( ) ;
}
public MeinComposite ( ) {
p . add ( lbl ) ;
p . add ( tbox ) ;
initWidget ( pan ) ;
}
(vgl. J. Webber - Creating Widgets, S.5)
Dieses Composite-Beispiel zeigt, wie man ein eigenes Widget (MeinComposite) als Unterklasse der bereits vorhandenen Composite-Klasse ableitet.
Zunächst werden alle Basis-Widgets als private, das bedeutet keine andere
Klasse kann diese instanziieren, erzeugt. Zuletzt wird der Konstruktor MeinComposite() als public, jede Klasse kann Instanzen dieser Klasse erzeugen,
5
http://www.w3.org/DOM/
HTL Salzburg
10
Diplomarbeit
Google Web Toolkit
so definiert, dass dem Panel pan ein Label lbl und eine Textbox tbox eingebunden werden. Bei der Verwendung von ”Mein Composite”wird also automatisch eine TextBox zusammen mit einem Label angezeigt. Wie in diesem
Beispiel klar erkennbar wird, dient ein Composite prinzipiell als Bündelung
bereits vorhandener Widgets, und kann in der Strukturierung der Benutzerschnittstelle Anwendung finden.
3.2.2
Neues Widget
GWT bietet eine DOM-Klasse, die mit dem DOM (Document Object Model) kommunizieren kann. Das DOM beschreibt die Struktur eines HTMLDokuments. Somit kann man durch hinzufügen neuer HTML-Tags ein Widget erstellen, das ausschließlich auf vorhandenen HTML-Tags besteht. Mit
der sinkEvents Methode wird dem neuen Widget ein EventListener zugewiesen.
Im Programmcode wird, ähnlich wie bei den Composites, das zu Erzeugende
Widget von der Basisklasse namens Widget abgeleitet. Praktisch sieht dies
in Java wie folgt aus:
Code 2 Ableiten von der Widget-Klasse
public class NeuesWidget extends Widget {
Im Konstruktor dieses Widgets, public NeuesWidget(), werden die eigentlichen (HTML-)Elemente, die dieses Widget repräsentieren, festgelegt. Es ist
möglich, mehrere HTML-Tags hinzuzufügen, es muss jedoch ein Hauptelement gesetzt werden, was unter Verwendung der setElement Methode passiert, dessen Übergabeparameter ein Basis-UI-Element6 aus dem Document
Object Model ist:
Code 3 Hauptelement setzen
setElement ( DOM . createHTMLTAG ( ) ) ;
Wie bereits kurz angesprochen, muss jedem Widget einen EventListener zugeteilt werden. Diese Zuteilung erfolgt durch die sinkEvents Methode, deren
Liste der UI-Elemente: http://google-web-toolkit.googlecode.com/svn/
javadoc/1.4/com/google/gwt/user/client/DOM.html
6
HTL Salzburg
11
Diplomarbeit
Google Web Toolkit
Aufruf der Widget-Basisklasse mitteilt, auf welche Ereignisse reagiert werden
soll. Diese Zuweisung wird ebenso im Konstruktor vorgenommen, und könnte,
für ein Widget das auf einen Click und auf MouseEvents, also möglicherweise
OnMouseOver oder OnMouseOut, reagiert, so aussehen:
Code 4 sinkEvents Beispiel
sinkEvents ( Event . ONCLICK | Event . MOUSEEVENTS ) ;
Von den Widgets, die von Google implementiert wuden, ist bereits bekannt,
dass jedem Widget standardmäßig ein Stylename zugewiesen ist. Dem eigenen Widget wird mittels setStyleName(”Name”), innerhalb des Konstruktors, ein sogenannter default StyleName zugewiesen. Mehrere Events7 , werden mit einer Pipe verbunden, was für eine Oderverknüpfung zu einem einzigen Wert steht.
Wie aus der Objektorientierten Programmierung bereits bekannt, müssen
Schnittstellen vorgesehen werden, mit denen man Variablen setzen kann. In
diesem Beispiel eines Widgets, werden diese Schnittstellen vorgesehen, um
Attribute des Widgets setzen zu können. Man bedient sich der set-Methoden,
die die DOM-Klasse zum Setzen der eigentlichen Attribute bereitstellt.
Code 5 Set-Methode
public void setAttForWidget ( String Value ) {
DOM . setAttribute ( getElement ( ) , Attribut , Wert ) ;
}
Um dem Widget eine Schnittstelle für EventListners geben zu können, muss
die Klasse, beispielsweise für einen MouseListener, die SourcesMouseEvents
implementieren:
Code 6 Implement SourcesEvents
public class WidgetName extends Widget implements SourcesMouseEvents {
private MouseListenerCollection mouseListeners ;
Die Collection-Variablen beinhalten die eigentlichen Listener der Events. Um
solche Listener für das Widget auch setzen zu können, müssen Methoden,
Liste der Events:http://google-web-toolkit.googlecode.com/svn/javadoc/1.
4/com/google/gwt/user/client/Event.html
7
HTL Salzburg
12
Diplomarbeit
Google Web Toolkit
die dies ausführen, vorgesehen werden. Dies wird jeweils mit einer add bzw.
remove Methode realisiert:
Code 7 add/remove Listener Methoden
public void addMouseListener ( MouseListener listener ) {
mouseListeners . add ( listener ) ;
}
public void removeMouseListener ( MouseListener listener ) {
mouseListeners . remove ( listener ) ;
}
Die vom Browser erkannten Events müssen noch an die Listener verteilt werden, damit sie im Programmcode ebenfalls erkannt werden können. Dies erfolgt durch Überschreiben (override) der onBrowserEvent Methode. In dieser
Methode müssen alle Events, auf die das Widget reagieren soll, berücksichtigt
werden:
Code 8 fire MouseEvent
public void onBrowserEvent ( Event event ) {
switch ( DOM . eventGetType ( event ) ) {
case Event . ONCLICK :
case Event . ONMOUSEDOWN :
case Event . ONMOUSEUP :
case Event . ONMOUSEMOVE :
case Event . ONMOUSEOVER :
case Event . ONMOUSEOUT :
if ( mouseListeners != null )
mouseListeners . fireMouseEvent ( this , event ) ;
break ;
}
}
Das waren alle Schritte, die vorgenommen werden müssen, um ein eigenes
Widget, unabhängig eines bestehenden Widgets, zu erstellen.
3.2.3
Styles mit CSS
In der folgenden Übersicht sind alle möglichen Methoden aufgelistet, die ein
Widget mit einer Klasse in CSS in Beziehung bringen. Dies kann mit dem
Attribut class, das man bei einem HTML-Tag setzen kann, gleichgesetzt werden.
HTL Salzburg
13
Diplomarbeit
Google Web Toolkit
Code 9 Style-Methoden Übersicht
Widget .
setStyleName ( ) // StyleName s e t z e n
addStyleName ( ) // StyleName h i n z u f u e g e n
removeStyleName ( )
// StylenName e n t f e r n e n
setStylePrimaryName ( ) // p r i m a e r e n StyleName s e t z e n
Die Form eines Composites könnte zwar ausschließlich im Java-Code verändert
werden, bringt jedoch, verglichen mit CSS8 , auch einige Probleme mit sich.
Einerseits erfreuen sich CSS großer Beliebtheit, die meisten Entwickler sind
bereits vertraut mit ihnen, und andererseits ist der Aufwand, verglichen mit
äquivalentem, Java-Code geringer.
Code 10 Style-Methoden in Anwendung
// Java−Code
MeinComposite wid = new MeinComposite ( ) ;
wid . setStylePrimaryName ( " meinWidget " ) ;
wid . addStyleDependentName ( " aktiv " ) ;
//CSS−Code
. meinWidget { }
. meinWidget . meinWidget−aktiv { }
Wie die GWT-Style-Methoden zusammen mit CSS-Code funktionieren, wird
im obigen Codebeispiel deutlich. Empfohlen werden Primary- und Dependent-Stylenames, die es einfach machen CSS-Selektoren für verschiedene Zustände
zu definieren. Die Wahl von CSS muss jedoch nicht zwangsläufig von Vorteil
sein. Prinzipiell sollte auf CSS immer dann verzichtet werden, wenn eine Eigenschaft für das Widget auf dessen Funktion oder Layout Einfluss nimmt.
Absolute Positionsangaben beispielsweise, sollten im eigentlichen Programmcode stehen, da für potenzielle Unterelemente die Art der Positionierung
wichtig sein kann.
Cascading Style Sheets: Styles definieren wie HTML-Elemente dargestellt werden, und
werden üblicherweise in Style Sheets mit der Endung ’css’ gespeichert. www.w3schools.com
8
HTL Salzburg
14
Diplomarbeit
4
Google Web Toolkit
Architektur
4.1
4.1.1
Debugging und Deployment
Hosted Mode
Läuft eine Applikation im Hosted Mode, wird diese als Bytecode in der Java Virtual Machine ausgeführt. Dieser Modus ist während der Entwicklung besonders vorteilhaft, da man alle Java Debugging Funktionen zur
Verfügung hat und ein Treelogger 9 sowie der Hosted Browser, die das Debuggen zusätzlich vereinfachen.
4.1.2
Web Mode
Im Web Mode läuft die Applikation als purer JavaScript-Code, kombiniert
mit HTML. Die Transformation des Java-Codes in JavaScript erfolgt mit dem
GWT Java-to-JavaScript Compiler. Üblicherweise wird eine Applikation an
einem Server im Web Mode bereitgestellt, von wo aus diese dann für Benutzer
erreichbar ist. Der Benutzer bekommt so den eigentlichen Bytecode oder die
Binärversion des Programms nie zu Gesicht.
4.1.3
Java-to-JavaScript Compiler
Dieser Compiler ist, neben dem Framework mit den vorgefertigten Widgets
und Panels, die Hauptkomponente des GWT. Wie der Name sagt, übersetzt
dieser den programmierten Java-Code in JavaScript. Um den Java-to-JavaScript
Compiler auszuführen, muss das Projekt im Web Mode laufen. Um den JavaScript Output möglichst klein zu halten, werden nur Klassen und Methoden übersetzt, die in der Applikation auch wirklich eingesetzt werden, und
redundante Codeformatierungen werden entfernt. Der letzte Punkt führt leider zu einer Nichtlesbarkeit des JavaScript Codes, was sich, hinsichtlich eines
potentiellen Codediebstahls, auch vorteilhaft auswirken kann.
9
http://google-web-toolkit.googlecode.com/svn/javadoc/1.4/com/google/
gwt/core/ext/TreeLogger.html
HTL Salzburg
15
Diplomarbeit
5
5.1
Google Web Toolkit
Applikationsentwicklung
Remote Procedure Calls
An einem gewissen Punkt, kann die clientseitige Kommunikation einer Webapplikation nicht mehr ausreichenden sein und somit müssen, um Daten
von einem Server laden zu können, Remote Procedure Calls (RPCs) ausgeführt werden. Moderne Browser stellen ein XMLHttpRequest-Objekt zur
Verfügung, das das Senden der HTML-Form-Daten zu einem Server erlaubt,
ohne ein komplettes Neuladen der Seite zu erfordern. Mit GWT können
RPCs entweder mit der RequestBuilder -Klasse ausgeführt werden, die die
Funktionalitäten des eigentlichen XMLHttpRequest-Objekts aufweist, oder
mit GWT-RPC 10 , das es erlaubt, dass die Kommunikation mittels JavaObjekten stattfindet. Im folgenden Abschnitt wird gezeigt, wie ein RPC mit
dem RequestBuilder funktioniert.
5.1.1
RequestBuilder
Die RequestBuilder -Klasse erlaubt es, Daten, einer HTML-Form zum Beispiel, an einen Server zu schicken, und auch Daten von einem Server zu
empfangen.
Code 11 RequestBuilder instanziieren
RequestBuilder rb = new RequestBuilder ( RequestBuilder . GET , url ) ;
Zuerst muss eine Instanz der Klasse erzeugt werden, in der die HTTPMethode (in diesem Fall GET) und die Zieladresse angegeben wird. Diese
Instanz kann dann auf Methoden, die diese Klasse bietet, zugreifen.
10
http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.
DeveloperGuide.RemoteProcedureCalls.html
HTL Salzburg
16
Diplomarbeit
Google Web Toolkit
Code 12 Request ausführen
Request request = rb . sendRequest ( "term=GWT+in+ Action " ,
new RequestCallback ( ) {
public void onResponseReceived ( Request req , Response res ) {
// Ausfuehrung
}
});
public void onError ( Request req , Throwable exception ) {
// b e i F e h l e r n
}
(Hanson, Tasy - GWT in Action. S. 14)
Nun wird der Request über eine Methode der Klasse ausgeführt, die ein Handle zurückgibt, die vom Typ Request ist, und somit von einem Try/Catch gesichert werden muss. Die sendRequest-Methode hat zwei Übergabeparamter,
nämlich einen String, der zum Server gesendet wird und eine RequestCallback
Instanz, die die Kommunikation steuert, und eventuelle Fehler aufzeigt. Die
Verwendung von der Handler -Klasse ist notwendig, da dieser Request asynchron vollzogen wird, das heißt, die Daten werden zum Server geschickt und
dort sofort verarbeitet, ohne dass von diesem eine Bestätigung zurückkommt.
Die Daten, die bei RPCs verschickt werden, können vom Typ XML, HTML,
oder auch JSON11 sein. JSON ist ein einfaches Nachrichtenformat, das besonders für die Kommunikation im Browser geeignet ist.
5.2
Performanz
Das GWT-Framework bietet viele Möglichkeiten eine Webapplikation schnell
und speichereffizient bereitzustellen. Man muss sich jedoch im Klaren sein,
dass eine Webapplikation nunmal in einem Webbrowser läuft, und auch wenn
aktuelle Browsergenerationen so gute Laufzeitumgebungen bieten wie noch
nie zuvor, kann diesbezüglich noch kein Vergleich zu betriebssystemnativen
Programmen bereitgestellt werden. Auch JavaScript ist sehr zeitaufwendig,
betrachte man bloß den mehrfachen Zeitbedarf des Interpreters verglichen zu
compilierten Code.
Da in manchen Fällen JavaScript-Code sogar um das Hundertfache langsamer sein kann als nativer Code, sollte es ein zusätzlicher Ansporn sein zeit11
http://www.json.org/
HTL Salzburg
17
Diplomarbeit
Google Web Toolkit
und speichereffizienten Code zu schreiben. Der wichtigste Aspekt ist deshalb
immer die vom Benutzer gefühlte Performanz, die immer als erster Faktor
betrachtet werden sollte.
5.2.1
Startzeit
Die Zeit, wie lange eine Applikation startet ist ein sehr wichtiger, aber auch
komplexer Faktor. Da dieser einerseits grundsätzlich von den IT-Ressourcen
des Benutzers abhängt und andererseits oft bloß davon abhängt wie viel
Zeit der Benutzer gewillt ist, beim Start des Programms zu warten. Die
Konkurrenz im Web ist groß, deshalb sollte man diese Zeit so weit wie möglich
verkürzen, um die Zahl der frustrierten Benutzer möglichst klein zu halten,
um eine Vielzahl von Kunden zu gewinnen.
Abbildung 3: Daten/Code-Zyklus
(vlg. J. Webber - Performance, S.8)
Die abgebildete Grafik zeigt, welche Phasen der Code (oder auch Daten)
durchläuft, bis er dem Anwender sichtlich zur Anzeige gebracht wird. Zuerst muss berücksichtigt werden, ob der JavaScript-Code bereits gecacht ist,
da dieser somit kein zweites Mal heruntergeladen werden müsste. Ehe dieses Skript interpretiert und ausgeführt wird, muss ein Download erfolgen,
dessen Dauer je nach Datenmenge variieren kann. Bei großen Skriptdaten,
beispielsweise MB-Größe, sollten diese mit gzip12 komprimiert werden.
Die erstmalige Downloadzeit ist, entgegen möglicher langläufiger Meinung,
nicht wichtiger als das Cachen großer Skripts, weshalb das GWT diesbezüglich
eine automatisierte Lösung bietet. HTTP-Requests sind das mit Abstand
zeitaufwendigste, das Webapplikationen im Browser je ausführen, und sollten
deswegen, wo die Möglichkeit besteht, unbedingt vermieden werden. Beispiele dafür sind unteranderem externe JS-Dateien, CSS-Dateien, Bilder oder
auch RPC-Requests13 die sehr viel Zeit kosten können. Abhilfe kann dem
gzip (GNU zip) ist ein Kompressionstool, das entwickelt wurde um Compress (UNIX
Kompressionsprogramm) zu ersetzen. www.gzip.org
13
http://technet2.microsoft.com/windowsserver/en/library/
988b4438-d83b-45f3-b930-ee92e68ac32c1033.mspx?mfr=true
12
HTL Salzburg
18
Diplomarbeit
Google Web Toolkit
durch Aggregation von mehreren einzelnen Skripts geschehen. Bei Bildern
ist dies nicht ganz so einfach, weshalb die Verwendung von ImageBundle 14 ,
das Entwicklner erlaubt Bündel von statischen Bildern zu erzeugen, um diese
mit einem einzigen HTTP-Request herunterzuladen, empfehlenswert ist. Die
Bildgröße ist beim Compilieren bekannt, dadurch kann verhindert werden,
dass sich eine Applikation sprunghaft aufbaut. Um Aktivitäten, wie Servercalls, im Auge zu behalten, gibt es praktische HTTP-Logger für den Browser
die oft sehr hilfreich sein können.
5.2.2
Laufzeit
Wie bereits angesprochen, ist die Manipulation eines DOM generell langsam,
wodurch darauf geachtet werden sollte, keine unnötigen UI-Elemente, die
nicht ausgeführt werden, zu laden. Ein guter Anhaltspunkt kann dabei die
Erwartung an die Benutzeroberfläche seitens des Benutzers sein.
Code 13 Inner-HTML Beispiel
String id = HTMLPanel . createUniqueId ( ) ;
String html =
"<table >" +
" <tr ><td >Header </td ></tr >" +
" <tr ><td id=’" + id + " ’/></tr >" +
" </table >" ;
HTMLPanel p = new HTMLPanel ( html ) ;
p . add ( new MeinComposite ( ) , id ) ;
(vgl. J. Webber - Performance, S.16) Direkte Einbindung von HTML-Code
kann beispielsweise schneller passieren, und man kann einer langsamen DOMManipulation aus dem Weg gehen. Der obige Beispielcode zeigt einen Auszug
der praktischen Anwendung dieser Methode. Wie im Zusammenhang mit
der Startzeit einer Applikation bereits erwähnt, können sich zu viele HTTPRequests zur Laufzeit ebenfalls negativ auswirken. Ein Ansatz dem entgegen
zu halten, ist die Aggregation von mehreren RPCs.
Code 14 Einzelne Servercalls
public interface MyService {
String login ( String user , String pass ) ;
Settings getSettings ( String authToken ) ;
Contact [ ] getContacts ( String authToken ) ;
}
14
http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign
HTL Salzburg
19
Diplomarbeit
Google Web Toolkit
(vgl. J. Webber - Performance, S.20)
Folgt der Code der Struktur des obigen Beispiels und weiß man, dass der
Benutzeranmeldung immer die gleichen RPCs folgen, können diese in einen
einzigen Aufruf zusammengefasst werden.
Code 15 Aggregierte Servercalls
public class LoginResult {
public String authToken ;
public Settings settings ;
public Contacts [ ] contacts ;
}
public interface MyService {
LoginResult login ( String user , String pass ) ;
}
(vgl. J. Webber - Performance, S.21)
Nun kann dem Server in einem einzigen Aufruf gemeldet werden, die benötigten
Daten zu laden.
5.3
Commandlinetools
Mit dem GWT kommen hilfreiche Commandlinetools, die über das Terminal bedient werden. Diese beinhalten unter anderem Funktionalitäten zur
Erzeugung des Projektverzeichnisses und der Projektdateien (siehe 5.3 und
5.4.1), um das Projekt in Eclipse laden zu können. Für jedes Projekt, wird
automatisch ein Skript angelegt, um den Java-Code in JavaScript zu kompilieren (ProjektName-compile). Der dadurch neu entstandene Code wird
im Verzeichnis www, das im Hauptverzeichnis angelegt wird, abgelegt. Die
Skripts ProjektName-shell und ProjektName-launch starten die Applikation
im Hosted- bzw. im Webmode.
HTL Salzburg
20
Diplomarbeit
5.4
Google Web Toolkit
Projektverzeichnisstruktur
Abbildung 4: Basisverzeichnisstruktur
5.5
Codebeispiel - Einfaches Tutorial
Da zur Entwicklung dieses Beispiels das Betriebssystem Mac OS X Leopard verwendet wird, ist die Wahl der korrekten GWT-Version, unter diesem
Betriebssystem, sehr wichtig. Mit der aktuellen (März ’08) Version gibt es
Probleme mit JAXP15 , dem Xerces16 Parser und dem von Google angepassten WebKit17 basierten Browser, der unter Carbon in Leopard nicht läuft.
Die GWT-for-Mac-Entwickler haben viel Arbeit geleistet und eine dezidierte
Leopard Version zum Download bereitgestellt, der jedoch nicht auf konventionelle Art, sondern ausschließlich über eine, im GWT-Forum bekannt gegebene, Adresse erreichbar ist: http://google-web-toolkit.googlecode.
com/files/gwt-leopard-1.4.61.tar.gz. Den Tarball wie gewöhnlich extrahieren und in das Verzeichnis eines Webservers kopieren.
15
https://jaxp.dev.java.net/
http://xerces.apache.org/
17
http://webkit.org/
16
HTL Salzburg
21
Diplomarbeit
5.5.1
Google Web Toolkit
Projektsourcen erzeugen
Die Projekterzeugung erfolgt mit den mitgelieferten Commandlinetools. Zuerst wird die Projektstruktur mit dem Kommando
./projectCreator-eclipseprojectName-outprojctDir
erzeugt.
Abbildung 5: ProjectCreator
Der zweite und letzte Schritt zur Projekterzeugung erfolgt mit
./applicationCreator-eclipseprojectName-outprojectDirorg.client.
ProjectName
Abbildung 6: ApplicationCreator
Der applicationCreator wird ausgeführt und erstellt alle notwendigen Dateien
(Abbildung 2, Zeile:4-12) für ein GWT-Projekt unter Eclipse.
HTL Salzburg
22
Diplomarbeit
5.5.2
Google Web Toolkit
Projekt in Eclipse laden
Die Eclipse Workbench öffnen, und Menüpunkt Import auswählen.
Abbildung 7: Projektimport
Es öffnet sich ein neues Fenster mit möglichen Projektladeoptionen. In diesem
Fall wird ein bereits vorhandenes Projekt geöffnet.
HTL Salzburg
23
Diplomarbeit
Google Web Toolkit
Abbildung 8: Importdialog
Im nächsten Fenster den Pfad des Projektordners auswählen (also: HelloDir).
HTL Salzburg
24
Diplomarbeit
Google Web Toolkit
Abbildung 9: Importdialog
Ob das Projekt wirklich geladen werden konnte, erkennt man, indem im
Projektfenster der Name des Projekts erscheint und das Flag automatisch
gesetzt wurde. Alles bestätigen und das Projekt wird in Eclipse geladen.
HTL Salzburg
25
Diplomarbeit
Google Web Toolkit
Abbildung 10: Applikationsgerüst
In der Projektstruktur für diese einfache Applikation bestehen zwei relevante
Dateien:
• HelloWorld.html: Layout der Applikation in einfachem HTML.
• HelloWorld.java: Programmierung der Funktionen, in Java, mit einfacher automatischer AJAX-Unterstützung.
Die Datei HelloWorld.html kann auf die einfachste Ebene einer HTML-Datei
heruntergebrochen werden:
Das Script-Element darf nicht vergessen werden, da es den JavaScript-Code
einbindet.
Der Java-Code ist ebenso einfach gehalten, wie die HTML-Datei:
Wie der Name der Funktion onModuleLoad bereits verrät, wird der Code in
dieser bei Seitenaufruf automatisch ausgeführt. Als erster Schritt wird ein
Button namens b mit dem Text Say Hello! erzeugt, der durch den ClickListener etwas macht wenn man ihn anklickt. Ausgeführt wird der Code in
der Funktion onClick, die ein neues Fenstern mit dem Hinweis Hello World!
am Bildschirm erscheinen lässt. Der Button wird nun noch ins so genannte
HTL Salzburg
26
Diplomarbeit
Google Web Toolkit
Code 16 HelloWorld.html
<html>
<head>
<title>Hello World</ title>
<script l a n g u a g e =’ j a v a s c r i p t ’ src=’ o r g . HelloWorld . nocache . j s ’ />
</ head>
<body>
<h1>Greet the earth</ h1>
</ body>
</ html>
Code 17 HelloWorld.java
package org . client ;
import
import
import
import
import
import
com . google . gwt . core . client . EntryPoint ;
com . google . gwt . user . client . ui . Button ;
com . google . gwt . user . client . ui . ClickListener ;
com . google . gwt . user . client . ui . RootPanel ;
com . google . gwt . user . client . ui . Widget ;
com . google . gwt . user . client . Window ;
public class HelloWorld implements EntryPoint {
public void onModuleLoad ( ) {
Button b = new Button ( "Say Hello !" , new ClickListener ( ) {
public void onClick ( Widget sender ) {
Window . alert ( " Hello World !" ) ;
}
});
RootPanel . get ( ) . add ( b ) ;
}
HTL Salzburg
27
Diplomarbeit
Google Web Toolkit
RootPanel geladen, das in diesem Fall dem Bereich zwischen der Überschrift
und dem geschlossen body-Element in der HTML-Datei entspricht.
Der Java-Code ist nun bereit compiliert zu werden, indem man Run Hello
World in der Toolbar auswählt.
Abbildung 11: Compilieren
Folglich öffnet sich die Google Web Toolkit Development Shell und der angepasste GWT WebKit, in dem die Applikation im Hosted Mode läuft.
HTL Salzburg
28
Diplomarbeit
Google Web Toolkit
Abbildung 12: GWT-Browser Hosted Mode
Klickt man nun auf Say Hello! öffnet sich der vorhin definierte Dialog.
Abbildung 13: Hinweisfenster
5.5.3
Style hinzufügen
Natürlich ist eine Website ohne anspruchsvollem Design nicht zeitgerecht.
Diesem Problem kann mit einem CSS-Stylesheet einfach Abhilfe geschafft
werden. Hierzu wird eine zusätzliche Zeile im HTML-Skript hinzugefügt, die
angibt, unter welchem Pfad das Stylesheet zu erreichen ist.
Wird das href -Attribut wie im Codebeispiel darüber angegeben, muss die
Datei im selben Verzeichnis wie die eigentliche HTML-Datei liegen. Indem
man mit einem Rechtsklick auf die HTML-Datei im Package Explorer, erst
New und dann File auswählt, wird die CSS-Datei erzeugt.
HTL Salzburg
29
Diplomarbeit
Google Web Toolkit
Code 18 HelloWorld.html
<html>
<head>
<title>Hello World</ title>
<script l a n g u a g e =’ j a v a s c r i p t ’ src=’ o r g . HelloWorld . nocache . j s ’ />
<link rel=" stylesheet " type="text/css" href=" style .css" />
</ head>
<body>
<h1>HelloWorld</h1>
</ body>
</ html>
Abbildung 14: Neue Datei anlegen
Im darauf folgendem Fenster sollte darauf geachtet werden, ob der automatisch erstellte Pfad wirklich korrekt ist.
HTL Salzburg
30
Diplomarbeit
Google Web Toolkit
Abbildung 15: Dateidialog
Die Datei ist nun erzeugt, steht im PackageExplorer direkt unter der HTMLDatei, und kann editiert werden.
Code 19 style.css
h1 {
color : #c64 ;
}
. gwt−Button {
color : #c64 ;
}
Dieses sehr einfach gehaltene Stylesheet färbt den Text der Überschrift und
des Buttons in einem blassen Orange. Der erzeugte Button wird im Stylesheet
GWT-spezifisch mit
.gwt-Button
angesprochen. Grundsätzlich, werden alle Widgets mit der gleichen Notation,
nämlich
.gwt-WidgetName
HTL Salzburg
31
Diplomarbeit
Google Web Toolkit
angesprochen.
Abbildung 16: GWT-Browser Hosted Mode
So einfach kann etwas Farbe in die Webapplikation gebracht werden.
5.5.4
Am Webserver bereitstellen
Um die Applikation anderen Benutzern zur Verfügung zu stellen, muss diese
auf allen gängigen Webbrowsern zur Anwendung gebracht werden. Hier liefert
das GWT wiederum ein hilfreiches Commandlinetool um dies zu realisieren.
Abbildung 17: Java-to-JavaScript compilieren
Mit
{ProjektName}-compile
wird der Java-to-JavaScript Compiler ausgeführt und die neu erzeugten
Sourcen werden ins Verzeichnis
HTL Salzburg
32
Diplomarbeit
Google Web Toolkit
www/org.{ProjektName}
geschrieben. Dieses Verzeichnis kann nun auf einen beliebigen Webserver geladen, und davon aufgerufen werden.
Abbildung 18: Applikation im Safari-Browser
HTL Salzburg
33
Diplomarbeit
6
Google Web Toolkit
Pizzaprogramm
Ziel dieses Anwendungsbeispiels ist es, alle behandelten Funktionalitäten des
GWTs in einer Applikation zur Anwendung zu bringen.
6.1
Programmbeschreibung
Dieses Pizzaprogramm soll die Bestellung einer Pizza über das Internet übernehmen.
Diese Webapplikation könnte in einer Pizzeria praktisch Anwendung finden.
Der Kunde kann sich, über das Webinterface, eine Pizza aussuchen, und diese nach Bedarf belegen. Abschließend kann der Kunde zwischen Bezahlung
per Kreditkarte oder bar wählen. Nach Abschicken der Bestellung wird eine
Rechnung, mit den zusammengefasseten Informationen, ausgegeben.
6.2
Voraussetzungen
Die Entwicklung dieses Programms setzt voraus, dass ein GWT-Projekt für
Eclipse erstellt (siehe: Einfaches Tutorial), und in Eclipse so weit geladen
werden kann, um direkt in die Implementierung einsteigen zu können. Außerdem wird gleich zu Anfang ein Stylesheet eingebunden.
6.3
Implementierung
Als Ausgangspunkt dienen die folgenden drei Dateien, die bislang einfache
Grundgerüste sind.
Code 20 Pizza.html
<html>
<head>
<script l a n g u a g e =’ j a v a s c r i p t ’ src=’ o r g . P i z z a . nocache . j s ’></ script>
<link rel=" stylesheet " type="text/css" href=" style .css"/>
</ head>
<body>
<h1>Pizza bestellung</h1>
</ body>
</ html>
HTL Salzburg
34
Diplomarbeit
Google Web Toolkit
Code 21 Pizza.java
package org . client ;
import
import
import
import
import
import
com . google . gwt . core . client . EntryPoint ;
com . google . gwt . user . client . ui . Button ;
com . google . gwt . user . client . ui . ClickListener ;
com . google . gwt . user . client . ui . Label ;
com . google . gwt . user . client . ui . RootPanel ;
com . google . gwt . user . client . ui . Widget ;
public class Pizza implements EntryPoint {
}
}
Code 22 style.css
( noch leer )
Es wird davon ausgegangen, dass ein Kunde auch nur eine Pizza bestellt.
Deswegen werden für die Auswahl der Pizzen RadioButtons vorgesehen, die
eine Pizza wählen lassen:
HTL Salzburg
35
Diplomarbeit
6.3.1
Google Web Toolkit
MeinRadioPanel
Code 23 MeinRadioPanel schreiben
public class Pizza implements EntryPoint {
class MeinRadioPanel extends Composite {
private FlowPanel MyPanel = new FlowPanel ( ) ;
private Label PanelHeader = new Label ( ) ;
public MeinRadioPanel ( ) {
PanelHeader . setVisible ( true ) ;
MyPanel . add ( PanelHeader ) ;
initWidget ( MyPanel ) ;
setStyleName ( " MeinRadioPanel " ) ;
}
public void add ( Widget w ) {
MyPanel . add ( w ) ;
}
}
public void setCaption ( String HeaderName ) {
PanelHeader . setText ( HeaderName ) ;
}
Um MeinRadioPanel, so der Name des eigenen Widgets, von der Composite
Klasse ableiten zu können, muss das Paket com.google.gwt.user.client.
ui.Composite importiert werden. Zunächst alle Widgets instanziieren, die
anschließend im Konstruktor zusammengefügt werden.
Im Konstruktor wird nun dem FlowPanel namens MyPanel das Label namens
PanelHeader angehängt, ehe initWidget, das in jedem Composite-Konstruktor
notwendig ist, aufgerufen wird. Um das Widget über CSS ansprechen zu
können, wird ein StyleName gesetzt.
FlowPanels besitzen eine add Methode, mit der, wie in diesem Fall beispielsweise, die RadioButtons hinzugefügt werden. Diese add Methode muss, wie
die Methode zum Setzen der Überschrift, für das eigene MeinRadioPanel
selbst programmiert werden, was über eine set Methode realisiert wird. Der
Übergabeparameter ist ein Widget, da man jedes Widget zu MeinRadioPanel
hinzufügen können soll.
HTL Salzburg
36
Diplomarbeit
Google Web Toolkit
Code 24 Pizzen Buttons erzeugen
// P i z z e n RadioButtons e r z e u g e n
final RadioButton Margherita = new RadioButton ( " PizzaListe " ,
" Margherita (5 EUR)" ) ;
final RadioButton Salami = new RadioButton ( " PizzaListe " ,
" Salami (7 EUR)" ) ;
final RadioButton FruttiDiMare = new RadioButton ( " PizzaListe " ,
" Frutti di Mare (7 ,5 EUR)" ) ;
// s t a n d a r d m a e s s i g P i z z a M a r g h e r i t a waehlen
Margherita . setChecked ( true ) ;
// Pizza−Panel i n s t a n z i i e r e n
MeinRadioPanel pizzapanel = new MeinRadioPanel ( ) ;
pizzapanel . setCaption ( " Suchen Sie sich eine Pizza aus" ) ;
// P i z z e n zum Panel h i n z u f u e g e n
pizzapanel . add ( Margherita ) ;
pizzapanel . add ( Salami ) ;
pizzapanel . add ( FruttiDiMare ) ;
RootPanel . get ( ) . add ( pizzapanel ) ;
}
}
Zu Beginn werden Objekte der Klasse RadioButton erzeugt, wobei für jede
Pizza ein eigenes angelegt wird. Mit setChecked(true) wird beim Programmstart automatisch der RadioButton der Pizza Margherita ausgewählt. Alle
RadioButtons zusammen, werden einem FlowPanel hinzugefügt, innerhalb
dessen, jeweils nur ein Element von vielen ausgewählt werden kann.
Es wäre nicht gerade benutzerfreundlich, bloß die RadioButtons anzuzeigen,
ohne einen Hinweis zu geben, was getan werden soll. Da FlowPanels standardmäßig keine Beschriftung oder vergleichbares unterstützen, wird an dieser Stelle einfach das eigene Widget implementiert, das sich von der CompositeKlasse ableitet, auf einem FlowPanel basiert, und die Möglichkeit der Beschriftung über ein Label anbietet.
6.3.2
Zusatzbelag (CheckBox)
Da der Kunde theoretisch jeden Zusatzbelag auswählen kann, macht in diesem Fall der Einsatz von CheckBoxen Sinn. Alle CheckBoxen zusammen
HTL Salzburg
37
Diplomarbeit
Google Web Toolkit
werden einem Panel hinzugefügt, und dieses wird dann wiederum dem RootPanel hinzugefügt.
Code 25 CheckBoxen für Zusatzbelag
// Belag−Panel i n s t a n z i i e r e n
MeinRadioPanel belagpanel = new MeinRadioPanel ( ) ;
belagpanel . setCaption ( " Welcher Zusatzbelag darf es sein? ( Jeder Belag 1 EUR)" ) ;
// Z u s a t z b e l a g
final CheckBox
final CheckBox
final CheckBox
RadioButtons e r z u e g e n
Kaese = new CheckBox ( "Viel Kaese " ) ;
Oliven = new CheckBox ( " Oliven " ) ;
Knoblauch = new CheckBox ( " Knoblauch " ) ;
// Belag zu Panel h i n z u f u e g e n
belagpanel . add ( Kaese ) ;
belagpanel . add ( Oliven ) ;
belagpanel . add ( Knoblauch ) ;
RootPanel . get ( ) . add ( belagpanel ) ;
6.3.3
Zahlungsart
Code 26 CheckBoxen für Zusatzbelag
// Z a h l u n g s a r t e n e r z e u g e n
final RadioButton kreditkarte = new RadioButton ( " Zahlungsarten " , " Kreditkarte " ) ;
final RadioButton barzahlung = new RadioButton ( " Zahlungsarten " , " Barzahlung " ) ;
// Z a h l u n g s a r t −Panel
MeinRadioPanel zahlungsart = new MeinRadioPanel ( ) ;
zahlungsart . setCaption ( "Wie moechten Sie zahlen ?" ) ;
// Z a h l u n g s a r t e n zum Panel h i n z u f u e g e n
zahlungsart . add ( kreditkarte ) ;
zahlungsart . add ( barzahlung ) ;
RootPanel . get ( ) . add ( zahlungsart ) ;
Vom Grundaufbau unterscheidet sich die Auswahl der Zahlungsart nicht von
den vorhergehenden Auswahlmöglichkeiten. Nun wird jedoch ein Feature hinzugefügt, das, wenn die Zahlungsart Kreditkarte ausgewählt wurde, ein Widget anzeigt, das es erlaubt, Kreditkarteinformationen anzugeben. Dieses WidJürgen Leobacher, 5AHELI
HTL Salzburg
38
Diplomarbeit
Google Web Toolkit
get wird eigens geschrieben, und wieder von der Anzeige entfernt, falls doch
bar gezahlt werden will.
Code 27 Widget für Kreditkarteninformationen
class KreditKartenInfo extends Composite {
private TextBox tbName = new TextBox ( ) ;
private TextBox tbExpDate = new TextBox ( ) ;
private Label lbName = new Label ( "Name auf Karte " ) ;
private Label lbExpDate = new Label ( " Ablaufdatum " ) ;
private FlowPanel MyPanel = new FlowPanel ( ) ;
public KreditKartenInfo ( ) {
MyPanel . add ( lbName ) ;
MyPanel . add ( tbName ) ;
MyPanel . add ( lbExpDate ) ;
MyPanel . add ( tbExpDate ) ;
initWidget ( MyPanel ) ;
setStyleName ( " KreditKartenInfo " ) ;
}
public String getName ( ) {
return tbName . getText ( ) ;
}
}
public String getExpDate ( ) {
return tbExpDate . getText ( ) ;
}
Das KreditKartenInfo Widget leitet sich, wie das MeinRadioButton Widget auch, von der Composite Klasse ab, und unterscheidet sich vom zuvor
geschriebenen Widget, bezüglich der Codestruktur, grundsätzlich nicht. Jedoch werden, um die eingegebenen Informationen auch abrufen zu können,
get Methoden vorgesehen. Sie geben jeweils einen String zurück, der den, in
die TextBox eingegebenen Text, enthält.
Um das dynamische Hinzufügen bzw. Entfernen zu realisieren, wird ein ClickListener hinzugefügt, der das Selektieren bzw. Deselektiren der jeweiligen
Zahlungsinformationen mithorcht:
HTL Salzburg
39
Diplomarbeit
Google Web Toolkit
Code 28 ClickListener für Zahlungsart
final KreditKartenInfo KartenInformationen = new KreditKartenInfo ( ) ;
KartenInformationen . setVisible ( false ) ;
barzahlung . setChecked ( true ) ;
// Klick −L i s t e n e r um r a u s z u f i n d e n wenn RadioButton a n g e k l i c k t wurde
kreditkarte . addClickListener ( new ClickListener ( ) {
kreditkarte . setChecked ( true ) ;
KartenInformationen . setVisible ( true ) ;
}
});
barzahlung . addClickListener ( new ClickListener ( ) {
barzahlung . setChecked ( true ) ;
KartenInformationen . setVisible ( false ) ;
}
});
RootPanel . get ( ) . add ( KartenInformationen ) ;
Beim Anklicken, also in der Funktion onClick, wird das zuvor instanziierte Widget KartenInformation, im kreditkarte ClickListener, angezeigt, und
im barzahlung ClickListener entfernt. Standardmäßig wird Barzahlung ausgewählt. Zuletzt, wie gewöhnlich, das Widget dem RootPabel hinzufügen.
6.3.4
Bestellung abschicken
Damit der Kunde seine Bestellung abschicken kann, wird ein Button vorgesehen, der ein eigens geschriebenes Widget ist, das sich diemal nicht von der
Composite-, sondern von der Widget-Klasse ableitet.
HTL Salzburg
40
Diplomarbeit
Google Web Toolkit
Code 29 Eigenes Abschicken-Widget
public class Abschicken extends Widget
implements SourcesClickEvents {
private ClickListenerCollection clickListeners ;
public Abschicken ( String Caption ) {
setElement ( DOM . createButton ( ) ) ;
String CaptionBold = "<strong >" + Caption + " </strong >" ;
DOM . setInnerHTML ( getElement ( ) , CaptionBold ) ;
sinkEvents ( Event . ONCLICK ) ;
setStyleName ( " AbschickenButton " ) ;
}
public void addClickListener ( ClickListener listener ) {
if ( clickListeners == null ) {
clickListeners = new ClickListenerCollection ( ) ;
}
clickListeners . add ( listener ) ;
}
public void removeClickListener ( ClickListener listener ) {
clickListeners . remove ( listener ) ;
}
}
public void onBrowserEvent ( Event event ) {
switch ( DOM . eventGetType ( event ) ) {
case Event . ONCLICK :
if ( clickListeners != null ) {
clickListeners . fireClick ( this ) ;
}
}
}
Das Abschicken Widget leitet sich, wie bereits erwähnt, von der Klasse Widget ab, und implementiert SourcesClickEvents um dem Widget einen ClickListener hinzufügen zu können. Dem Konstruktor, der als Übergabeparameter
einen String für den Namen hat, wird mit setElement dem Widget ein Button
hinzugefügt, der durch die DOM -Klasse geladen wird.
Um dem Button einen Namen, also den Text im Button, zu geben, wird sich
der setInnerHTML Methode der DOM Klasse bedient. Der Button-Name
könnte zwar auch mit setInnerText gesetzt werden, dann gäbe es jedoch
nicht direkt die Möglichkeit, den Text fett (strong) darzustellen. Somit wird
HTL Salzburg
41
Diplomarbeit
Google Web Toolkit
der String erst mit dem strong HTML-Tag eingeschrieben, und anschließend mit setInnerHTML in den Button geschrieben. Mit sinkEvents wird
der Klasse das ONCLICK Event aktiv hinzugefügt, ehe der StyleName gesetzt wird. Um im eigentlichen Programmablauf dem instanziierten Objekt
den ClickListener hinzufügen zu können, muss die addClickListener Methode
vorgesehen werden, in der der ClickListenerCollection 18 der eigentliche Listener hinzugefügt wird. Kann ein Listener hinzugefügt werden, muss es auch
eine Methode geben, die diesen wieder entfernt, wofür removeClickListener
vorgesehen ist.
Das Widget muss eingehende Events, die von DOM-Klasse erkannt werden, also vom Browser kommen, noch an die Listener verteilen, was durch
Überschreiben (override) der onBrowserEvent Methode des Widgets passiert. Im Falle eines ONCLICK Events wird der Click ausgeführt (fire).
Code 30 Abschicken und Rechnung instanziieren
final Abschicken SendeBestellung = new Abschicken ( " Bestellen " ) ;
final Label Rechnung = new Label ( ) ;
Rechnung . setVisible ( false ) ;
//ID−S e l e k t o r f u e r Rechnung s e t z e n
DOM . setElementAttribute ( Rechnung . getElement ( ) , "id" , " Rechnung " ) ;
RootPanel . get ( ) . add ( SendeBestellung ) ;
RootPanel . get ( ) . add ( Rechnung ) ;
Der SendeBestellung Button und das Label für die Rechnung werden instanziiert, wobei die Rechnung vorerst noch verborgen wird, da die Bestellung
noch nicht abgesendet wurde. Mit setElementAttribute wird dem Rechnung
Widget das Attribut id, mit dem Wert Rechnung zugewiesen, um es im Stylesheet ansprechen zu können.
18
http://google-web-toolkit.googlecode.com/svn/javadoc/1.4/com/google/
gwt/user/client/ui/ClickListenerCollection.html
HTL Salzburg
42
Diplomarbeit
Google Web Toolkit
Code 31 Rechnung auswerten
SendeBestellung . addClickListener ( new ClickListener ( ) {
int Preis = 0 ;
String Bestellungen = "" ;
String ZahlungMit = "" ;
if ( Margherita . isChecked ( ) ) {
Preis += 5 ;
Bestellungen = "<p> Margherita </p>" ;
}
else if ( Salami . isChecked ( ) ) {
Preis += 7 ;
Bestellungen = "<p>Salami </p>" ;
}
else if ( FruttiDiMare . isChecked ( ) ) {
Preis += 8 ;
Bestellungen = "<p> Frutti di Mare </p>" ;
}
if ( Kaese . isChecked ( ) ) {
Preis++;
Bestellungen += "<p> und mehr Kaese </p>" ;
}
if ( Oliven . isChecked ( ) ) {
Preis++;
Bestellungen += "<p>und mehr Kaese </p>" ;
}
if ( Knoblauch . isChecked ( ) ) {
Preis++;
Bestellungen += "<p>und mehr Knoblauch </p>" ;
}
if ( kreditkarte . isChecked ( ) ) {
ZahlungMit = "<p><strong > Zahlung mit Kreditkarte </ strong ></p>" +
"Name:" + KartenInformationen . getName ( ) + "<br/>" +
" Kartenablaufdatum :"+KartenInformationen . getExpDate ( ) ;
}
else if ( barzahlung . isChecked ( ) ) {
ZahlungMit = "<p>Sie Zahlen Bar </p>" ;
}
// w e i t e r f u e h r u n g im n a e c h s t e n Code
Beim Klicken auf den Abschicken-Button wird jede Bestellmöglichkeit abgefragt, und der daraus resultierende Preis ermittelt. Da nur eine Pizza
HTL Salzburg
43
Diplomarbeit
Google Web Toolkit
ausgewählt werden kann, wird die Abfrage mit if/else if realisiert, da bei
Eintreten eines Falls, die darauffolgenden automatisch falsch sind. Die Bezeichnungen der Auswahl werden in einen String geschrieben, der nach jeder
Auswahl erweitert wird. Der String wird mit HTML-Tags versehen.
Code 32 Rechnung schreiben und anzeigen
// W e i t e r f u e h r u n g d e s v o r h e r g e h e n d e n Codes
String StrPreis = "<p>"+Integer . toString ( Preis)+"EUR </p>" ;
DOM . setInnerHTML ( Rechnung . getElement ( ) ,
"<h3 >Rechnung </h3 >" +
"<strong >Pizza </ strong >" + Bestellungen +
"<strong >Preis </ strong >" + StrPreis +
ZahlungMit
);
Rechnung . setVisible ( true ) ;
}
});
Der Preis muss erst einer Typkonvertierung von Integer zu String unterzogen
werden. Die zuvor erzeugten Strings werden mit DOM.setInnerHTML in die
Rechnung geschrieben, und da jeder String HTML-Tags enthält, werden diese
nun als solche Interpretiert und angezeigt.
HTL Salzburg
44
Diplomarbeit
6.4
Google Web Toolkit
Style verpassen
Abbildung 19: Programm ohne Style
Die Webapplikation könnte zwar so verwendet werden, sieht aber nicht gerade
schön aus, und ist alles andere als Übersichtlich. Um das zu ändern, kommt
das am Anfang bereits erzeugte Stylesheet, style.css, zum Einsatz:
HTL Salzburg
45
Diplomarbeit
Google Web Toolkit
Code 33 style.css
h1 {
text−align : center ;
color : #8e2800 ;
}
. MeinRadioPanel {
padding−bottom : 20 px ;
background−color : #fff0a5 ;
}
. gwt−RadioButton {
padding−right : 20 px ;
}
. gwt−CheckBox {
padding−right : 20 px ;
}
. KreditKartenInfo {
background−color : #468966;
}
#Rechnung {
background−image : url ( papier . png ) ;
border : 1px solid #000000;
}
Wendet man dieses Stylesheet an, sieht die Applikation schlussendlich so aus:
HTL Salzburg
46
Diplomarbeit
Google Web Toolkit
Abbildung 20: Programm mit Style
HTL Salzburg
47
Diplomarbeit
Google Web Toolkit
Quellennachweise
Google 2008: Google Code - Webtoolkit (Modes). Internet: http://code.
google.com/webtoolkit/overview.html#Modes (08/04/08 8:29)
Google 2008: Google Code - Webtoolkit (Architechture). Internet: http://
code.google.com/webtoolkit/overview.html#Architecture (07/04/08 17:18:19)
Voices That Matter: Google Web Toolkit Conference 2007: Joel Webber,
Creating Widgets - GWT Conference. Internet: http://www.voicesthatmatter.
com/gwt2007/presentations/CreatingWidgets_Webber.pdf (07/04/08 16:32:08)
Google 2008: Google Code - Webtoolkit (Getting Started - Eclipse). Internet:
http://code.google.com/webtoolkit/gettingstarted.html (28/03/08 17:18:22)
Voices That Matter: Google Web Toolkit Conference 2007. Joel Webber, Performance. Internet: http://www.voicesthatmatter.com/gwt2007/presentations/
Performance_Webber.pdf (12/04/08 10:32:08)
Dewsbury 2008: Ryan Dewsbury, Google Web Toolkit Applications. (AddisonWesley Longman, Amsterdam; 28. Januar 2008)
Hanson, Tasy 2007: Robert Hanson, Adam Tacy, GWT in Action: Easy Ajax
with the Google Web Toolkit. (Manning Pubn, 31. Juli 2007)
HTL Salzburg
48
HTBLA Salzburg
DIPLOMARBEIT
XML und Datenbanken
Ausgeführt im Schuljahr 2007/8 von: Martin Planer, 5AHELI-Tb20
Betreuer:
Prof. Mag. Dr. Anton Hofmann
Diplomarbeit
XML und Datenbanken
Inhaltsverzeichnis
3
Zusammenfassung
4
Abstract
5
1 XML
6
1.1
XML Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.1.1
XML Element . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.2
XML Attribut . . . . . . . . . . . . . . . . . . . . . . .
8
1.1.3
XML-Deklaration . . . . . . . . . . . . . . . . . . . . .
9
1.1.4
Wohlgeformtheit . . . . . . . . . . . . . . . . . . . . .
9
1.1.5
Gültigkeit . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2
XSD (XML Schema Definition) . . . . . . . . . . . . . . . . . 11
1.2.1
1.3
1.4
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1
XPath Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2
Achsen . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.3
Knotentests . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.4
Prädikate . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.5
XPath Beispiele . . . . . . . . . . . . . . . . . . . . . . 20
XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.1
FLWOR . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Martin Planer, 5AHELI
HTL Salzburg
1
Diplomarbeit
XML und Datenbanken
2 Datenbanken
24
2.1
Warum ist XML keine (gute) Datenbank? . . . . . . . . . . . 24
2.2
XML Verwendung mit Datenbanken . . . . . . . . . . . . . . . 25
2.3
2.2.1
Verwendung von XML als Datenaustauschformat . . . 25
2.2.2
Direktes Speichern der XML-Dokumente . . . . . . . . 27
XML-enabled Datenbanken . . . . . . . . . . . . . . . . . . . 29
2.3.1
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4
Native XML-Datenbanken . . . . . . . . . . . . . . . . . . . . 35
2.5
Berkeley DB XML . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5.1
Einführung in Berkeley DB XML . . . . . . . . . . . . 38
2.5.2
Berkeley DB XML API . . . . . . . . . . . . . . . . . . 42
Literaturverzeichnis
47
49
Tabellenverzeichnis
50
Listings
51
HTL Salzburg
2
Diplomarbeit
XML und Datenbanken
Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig
Salzburg, am
——————————————
Martin Planer
HTL Salzburg
3
Diplomarbeit
XML und Datenbanken
Zusammenfassung
Die steigende Anzahl von verschiedensten Applikationen, vor allem im Internet, und die Vernetzung dieser untereinander, stärkte das Erfordernis nach
einem einfachen Weg zum universellen Datenaustausch zwischen den Anwendungen. Seit seiner ersten Veröffentlichung 1998 entwickelte sich XML
(eXtensible Markup Language) zu genau diesem Standard.
XML bietet eine einfache, aber dennoch leistungsfähige Möglichkeit strukturierte Daten einheitlich und plattformunabhängig darzustellen bzw. auszutauschen, die dabei sowohl für EDV-Systeme, als auch für Menschen lesbar
bleiben. Aufgrund der immer weiter steigenden Popularität von XML haben
sich unzählige weitere Sprachen auf Basis von XML, für fast jeden erdenklichen Anwendungsfall, entwickelt.
Obwohl XML schon heutzutage als de facto Standard für den Datenaustausch
angesehen werden kann, erfolgt die Speicherung von Daten zum Großteil
immer noch in relationalen Datenbanken. Diese Systeme bieten sehr viele Funktionen auf die Firmen nicht mehr verzichten können und die XML
nicht bieten kann, zum Beispiel Datenintegrität, hohe Performanz, ausgereifte Administrations- und Diagnosewerkzeuge.
Die Zusammenführung der Vorteile beider Systeme ist jedoch nicht ohne
Weiteres möglich, da die Struktur der Datenspeicherung sehr unterschiedlich
ist.
Der erste Teil dieses Dokuments geht nun auf XML, inkl. aller relevanten XML-Derivate, im Allgemeinen ein, die notwendig sind, um mit XMLDokumenten im Zusammenspiel mit relationalen, aber auch mit nativen
XML-Datenbanken, arbeiten zu können.
Im zweiten Teil wird nähre auf die Verbindung von XML und Datenbanken eingegangen. Es bestehen mehrere Möglichkeiten, um XML-Dokumente
einerseits in einer Datenbank abzulegen, andererseits bestehende Daten in
einer Datenbank als XML-Dokument darzustellen.
Im abschließenden Kapitel werden die theoretischen Grundlagen über XML
und Datenbanken, mit Hilfe der freien Berkeley DB XML von Oracle, auf
ein praktisches Beispiel angewandt und die Verwendung eines solchen Datenbanksystems in einer Anwendung verdeutlicht.
HTL Salzburg
4
Diplomarbeit
XML und Datenbanken
Abstract
The myriads of emerging software applications - mainly on the internet an the interconnection between them, boosted the need for an easy way to
share data between those applications. Since its first release in 1998, XML
(eXtensible Markup Language) has developed to such a standard.
XML delivers an easy yet powerful possibility to display and exchange structured data, while staying readable by computer systems and humans. Due to
its continuing increas in popularity, there have been countless developments
in languages based on XML.
Although XML has become the de facto standard for data exchange, relational database management systems still dominate the market for information
storage. These systems provide several features, that corporations can’t go
without, but XML does not feature. To mention only a few, these features are e.g. data integrity, high performance or mature administration and
diagnostic tools.
Bringing the advantages of both systems together isn’t a goal that can be
achieved easily, since the data structure of both systems is very different.
The first part of this document will cover the basics of XML and all relevant
XML derivates, that are neccessary to use XML with relational but also with
native XML databases.
The second part will deal with the interconnection between XML and databases. There are several ways to store XML documents in a database as well
as to generate an XML document from an existing database.
In the last chapter the theoretical foundations on XML and databases will
be used on a concrete example using the free Berkeley DB XML from Oracle
and will show the usage of such a database system in own applications.
HTL Salzburg
5
Diplomarbeit
XML und Datenbanken
Kapitel 1
XML
1.1
XML Allgemein
XML (eXtensible Markup Language oder erweiterbare Auszeichnungssprache) ist eine Sprache, um Daten in einer hierarchischen Struktur zu speichern
und darzustellen. Die Struktur selbst, in der die Daten gespeichert werden,
ist bei XML nicht vorgegeben, sondern kann, nach Belieben und Bedarf, frei
definiert werden (z.B. in einer XSD-Datei, vgl. Kap. 1.2).
Ein XML-Dokument besteht aus Elementen, diese können optional noch Attribute enthalten, Daten und, falls benötigt, Kommentare.
Listing 1.1: Ein simples Beispiel-XML
<? xml version="1.0" e n c o d i n g="ISO -8859 -1" ?>
<c d k a t a l o g>
<cd>
< t i t e l>Ein Albumtitel</ t i t e l>
<k u e n s t l e r>Ein Kuenstler</ k u e n s t l e r>
<j a h r>2099</ j a h r>
</ cd>
<cd>
< t i t e l>Ein weiterer Albumtitel</ t i t e l>
<k u e n s t l e r>Ein weiterer Kuenstler</ k u e n s t l e r>
<j a h r>2017</ j a h r>
</ cd>
</ c d k a t a l o g>
HTL Salzburg
6
Diplomarbeit
1.1.1
XML und Datenbanken
XML Element
Ein Element in XML beschreibt in der für XML-Dokumente typischen Baumstruktur einen der Knotenpunkte. Elemente können entweder direkt Daten
beinhalten oder wieder weitere Elemente und somit eine hierarchische Struktur erzeugen. Optional können XML-Elemente auch Attribute enthalten.
Elemente werden in XML durch eine spitze, öffnende Klammer ( <“) einge”
leitet. Anschließend folgt der Name des Elements und, durch ein Leerzeichen
getrennt, 0 bis unendlich viele Attribute, sowie eine sich schließende spitze
Klammer ( >“), um die Elementdefinition abzuschließen.
”
Der Name des Elements kann frei gewählt werden, jedoch müssen einige
Regeln beachtet werden:
• Der Name des Elements darf nicht mit einer Ziffer oder einem Satz/Sonderzeichen beginnen.
• Der Name darf nicht mit xml“ (egal in welcher Schreibweise) beginnen.
”
• Der Name darf keine Leerzeichen ( ) enthalten
””
(vgl. Jänicke 2007, Kap. ”XML-Elemente”)
Die Definition eines Elements wird in XML mit einer schließenden spitzen
Klammer abgeschlossen. Das komplette Konstrukt aus öffnender Klammer,
dem Namen, den optionalen Attributen sowie der schließenden Klammer
nennt man auch Tag.
Listing 1.2: Ein öffnendes XML-Tag
<Elementname A t t r i b u t 1=" Wert1 ">
Nach der Definition des Elements folgt der eigentliche Inhalt, der, wie bereits
oben erwähnt, entweder wieder aus einem oder mehreren Elemente(n) oder
aus Daten bestehen kann.
Um ein Element abzuschließen, muss das entsprechende schließende Tag des
Elements angegeben werden. Es besteht im Grunde genommen aus den selben Bereichen wie das öffnende Tag, jedoch wird direkt nach der öffnenden
Klammer ein Schrägstrich ( /“) eingefügt, um es als schließendes Tag zu
”
kennzeichnen und die Attribute des Elements werden weggelassen, da sie ja
schon oben definiert wurden.
HTL Salzburg
7
Diplomarbeit
XML und Datenbanken
Listing 1.3: Ein schließendes XML-Tag
</ Elementname>
Enthält ein Element keine Daten oder Elemente - es ist also leer - kann
das Tag auch direkt, in einer Zeile, abgeschlossen werden. Dazu wird der
Schrägstrich schon in der Definition des Elements vor die schließende spitze
Klammer gesetzt, um Platz zu sparen und das Dokument übersichtlicher zu
halten.
Listing 1.4: Ein leeres, geschlossenes XML-Element
<Elementname A t t r i b u t 1=" Wert1 " />
< !−− a e q u i v a l e n t zu −−>
</ Elementname>
Wie im obigen Beispiel bereits zu sehen ist, können XML-Dokumente mit
Kommentaren versehen werden, um die Verständlichkeit zu erhöhen. Kommentare werden in XML durch die Zeichenfolge <!— eingeleitet und gelten,
”
”
bis sie durch die Zeichenfolge −− > wieder aufgehoben werden. Der Text
”
”
zwischen diesen beiden Zeichenfolgen wird nicht weiter verarbeitet.
1.1.2
XML Attribut
Mittels eines XML Attributs kann einem XML-Element ein zusätzlicher Parameter übergeben werden.
Wie in den Beispielen zu den XML-Elementen schon zu sehen ist, werden Attribute im Element-Tag, durch ein Leerzeichen vom Elementnamen getrennt,
definiert. Der Name eines Attributs ist wiederum frei wählbar. Der Wert des
Attributs wird durch ein folgendes Gleichheitszeichen ( =“) dem Namen zu”
gewiesen und muss in Anführungszeichen gesetzt werden ( ... oder ’ ... ’).
” ”
Ein Attribut darf weiters keine Unterelemente enthalten sondern nur alphanumerische Daten.
Listing 1.5: Ein XML-Attribut
</ Elementname>
HTL Salzburg
8
Diplomarbeit
1.1.3
XML und Datenbanken
XML-Deklaration
Ein XML-Dokument wird durch ein spezielles Element in der ersten Zeile als
solches definiert.
Listing 1.6: Eine XML-Deklaration
<? xml ?>
Die XML-Deklaration wird, wie im Listing ersichtlich, durch <?“ eingelei”
tet, beinhaltet den Elementnamen xml“ und wird anschließend mit ?>“
”
”
beendet und muss nicht durch separates, schließendes Tag beendet werden.
Optional können der XML-Deklaration zusätzlich 3 Attribute zugewiesen
werden:
version Die verwendete Versionsnummer der XML-Spezifikation. Das Attribut kann derzeit die Werte 1.0 oder 1.1 annehmen.
encoding Definiert die Zeichenkodierung des XML-Dokuments. Falls keine Zeichenkodierung angegeben ist, wird als Zeichenkodierung UTF-8
angenommen.
standalone Der Wert des Attributs ist entweder yes oder no. Der Wert yes
zeigt an, dass das XML-Dokument keine weiteren externen Referenzen,
wie zum Beispiel eine externe DTD, einbindet. Der Vorgabewert ist no,
was bedeutet, das externe Referenzen eingebunden werden können.
Listing 1.7: Beispiel einer XML-Deklaration
<? xml version="1.0" e n c o d i n g="ISO -8859 -1" standalone="yes" ?>
1.1.4
Wohlgeformtheit
Wohlgeformtheit ist ein Zustand eines XML-Dokuments, der für die Verarbeitung von XML-Daten unabdingbar ist. Ein XML-Dokument gilt als
wohlgeformt, wenn es sämtliche Wohlgeformtheitsbeschränkungen der XML
Spezifikation einhält. Exemplarisch dafür die wichtigsten Wohlgeformtheitsbeschränkungen (ohne Anspruch auf Vollständigkeit):
• Das Dokument enthält genau ein (1) Wurzelelement,
HTL Salzburg
9
Diplomarbeit
XML und Datenbanken
• Alle Elemente besitzen ein öffnendes und ein schließendes Tag bzw.
sind, wenn sie leer sind, in sich geschlossen.
• Alle Elemente müssen auf der selben hierarchischen Ebene geschlossen
werden, auf der sie auch geöffnet wurden.
• Alle Elemente müssen im selben Element geschlossen werden, in dem
sie geöffnet wurden.
• Die Attributnamen in einem Element müssen eindeutig sein.
(vgl. Bray, Paoli, Sperberg-McQueen, Maler 2000)
Damit ergeben sich folgende Beispielfälle:
Listing 1.8: Beispiel einer XML-Deklaration
<c d k a t a l o g>
<cd v e r l i e h e n="nein">
<j a h r>2099
</ cd>
</ j a h r>
<c d k a t a l o g>
<cd v e r l i e h e n="nein" v e r l i e h e n="ja">
< t i t e l>Ein weiterer Albumtitel</ t i t e l>
<k u e n s t l e r>Ein weiterer Kuenstler</ k u e n s t l e r>
<j a h r>2017</ j a h r>
</ cd>
Dieses XML-Dokument ist aus folgenden Gründen eindeutig nicht wohlgeformt:
• Das Dokument enthält 2 Wurzelelemente.
• Im ersten CD Element wird das Tag jahr“ geöffnet, jedoch erst nach
”
dem Schließen des <cd> Tags geschlossen.
• Im zweiten CD Element wird das Attribut verliehen“ doppelt verwen”
det, der Attributname ist nicht mehr eindeutig.
Korrekt müsste das XML-Dokument wie in Listing 1.1 lauten.
HTL Salzburg
10
Diplomarbeit
1.1.5
XML und Datenbanken
Gültigkeit
Um XML-Daten zwischen verschiedenen Anwendungen austauschen zu können,
muss zuvor eine, für den Zweck einheitliche Struktur des XML-Dokuments
definiert werden. Entspricht ein XML-Dokument dieser, ihm zugewiesenen,
Definition und ist es zusätzlich wohlgeformt, spricht man von einem gültigen
XML-Dokument.
Strukturen für XML-Dokumente können auf verschiedene Weise definiert
werden. Die gebräuchlichsten sind:
• Dokumenttypdefinition (engl. Document-Type-Definition, DTD)
• XML Schema (XML-Schema-Definition, XSD)
Ich werde in dieser Arbeit nur auf die Möglichkeit der Definition per XML
Schema eingehen, da Varianten sehr umfangreich sind und XSD von den
beiden aufgeführten die modernere, selbst auf XML basierende Lösung ist.
1.2
XSD (XML Schema Definition)
XSD (XML Schema Definition) ist eine, auf XML basierende, Sprache um
die Struktur eines XML-Dokuments zu definieren. XML Schema ist als Nachfolger des älteren, aber immer noch häufig verwendeten, DTD-Standards gedacht und ersetzt diesen, auf Grund vieler Vorteile, langsam, aber sicher
(XML-basiert, leistungsfähiger, Namensraumunterstützung, ...).
XSD definiert, welche Elemente und Attribute und in welcher Anzahl in
einem XML-Dokument vorkommen dürfen, die hierarchische Struktur dieser
Elemente untereinander und welche Werte ein solches Element enthalten darf.
XML-Dokumente können, zusätzlich zur Überprüfung auf Wohlgeformtheit,
auch auf die Gültigkeit gegen das entsprechende XSD geprüft werden.
Mittels XSD können so auch eigene, von XML abgeleitete, aber eigenständige,
Auszeichnungssprachen definiert werden (z.B. RSS, XHTML, etc.).
1.2.1
Syntax
Da XSD ein XML-Format ist, muss auch jedes XSD-Dokument mit einer
XML-Deklaration beginnen.
HTL Salzburg
11
Diplomarbeit
XML und Datenbanken
Listing 1.9: Eine XML-Deklaration für XSD
<? xml ?>
Das Root-Element, das alle anderen Elemente in einer Schema Definition
umschließt, ist das xs:schema-Element. Die im Dokument zu verwendenden
Namensräume, können in diesem Element als Attribute angegeben werden.
Listing 1.10: Das xs:schema-Element
<? xml version="1.0" ?>
<x s : s c h e m a x m l n s : x s=" http: // www.w3.org /2001/ XMLSchema ">
...
</ x s : s c h e m a>
Innerhalb des xs:schema-Elements können alle benötigten Elemente definiert
werden. Hier unterscheidet man zwischen
• einfachen Typen (simpleType)
• komplexen Typen (complexType)
simpleType-Elemente Ein simpleType-Element kann nur Werte direkt
enthalten, nicht aber Attribute oder weitere Unterelemente. Zusätzlich zu
dem Namen des Elements, muss hier noch der Datentyp angegeben werden,
den dieses Element enthalten soll. Die gebräuchlichsten sind
xs:string Eine Zeichenkette
xs:decimal Eine Dezimalzahl
xs:integer Eine Ganzzahl
xs:boolean Ein boolscher Werte, repräsentiert über 0/1 bzw. true/false
xs:date Eine Datumsangabe
xs:time Eine Zeitangabe
Zusätzlich können noch Standardwerte eingetragen werden, die angenommen
werden, falls kein anderer Wert angegeben wird.
Listing 1.11: XSD - simpleType
<x s : e l e m e n t name=" Beispiel " type=" xs:string " default="
Standardwert "/>
HTL Salzburg
12
Diplomarbeit
XML und Datenbanken
complexType-Elemente Ein complexType-Element enthält weitere Unterelemente und/oder Attribute.
Um ein Element als komplexen Typen zu definieren, wird ihm ein Kindelement namens xs:complexType zugewiesen, in den wiederum weitere Elemente definiert werden können. Die Reihenfolge der eingeschlossenen Elemente
kann hier wiederum entweder strikt, über die Verwendung des Unterelements
xs:sequence (die Elemente müssen in der angegebenen Reihenfolge vorkommen), oder locker über die Verwendung von xs:group (die Reihenfolge der Elemente ist nebensächlich) definiert werden. Da ein complexType keine Werte
direkt enthalten kann, muss hier auch kein Datentyp oder ein Standardwert
angegeben werden.
Zusätzlich können für ein komplexes Element auch Attribute definiert werden. Die Attributdefinition erfolgt im Grund genommen gleich wie eine Definition eines einfachen Typs, nur wird anstatt des xs:element-Tags ein xs:attributeTag verwendet.
Listing 1.12: XSD - complexType
<x s : e l e m e n t name=" Ueberelement ">
<xs:complexType>
<x s : s e q u e n c e>
< x s : a t t r i b u t e name=" Attribut1 " type=" xs:string "/>
<x s : e l e m e n t name=" Beispiel " type=" xs:string " default="
Standardwert "/>
...
</ x s : s e q u e n c e>
</ xs:complexType>
</ x s : e l e m e n t>
Einschränkungen (Restrictions) Um dies zu akzeptierenden Werte eines simplen Typs genauer zu definieren, können Einschränkungen auf Basis eines der Standardtypen definiert werden. Der Werte der simpleTypeElements wird hierbei nicht direkt, über das type=”X”-Attribut angegeben,
sonder, ähnlich dem complexType-Elements, über ein weiteres Unterelement
namens xs:simpleType.
In diesem xs:simpleType-Element können nur die Einschränkungen definiert
werden. Unter anderem sind möglich:
<xs:enumeration value=”XXX”> Ein oder mehrere solcher Elemente
definieren die zu akzeptierenden Werte direkt. Nur angegebene Werte
sind zulässig.
HTL Salzburg
13
Diplomarbeit
XML und Datenbanken
<xs:length value=”XXX”> Definiert die genaue Anzahl an Zeichen, die
dieses Element enthalten darf/muss.
<xs:minLength value=”XXX”> Definiert die minimale Anzahl an Zeichen, die dieses Element enthalten muss.
<xs:maxLength value=”XXX”> Definiert die maximale Anzahl an Zeichen, die dieses Element enthalten darf.
<xs:maxInclusive value=”XXX”> Definiert den maximalen Zahlenwert,
die dieses Element enthalten darf.
<xs:minInclusive value=”XXX”> Definiert den minimalen Zahlenwert,
die dieses Element enthalten darf.
<xs:maxExclusive value=”XXX”> Definiert den maximalen Zahlenwert
(exklusive der angegebenen Zahl), die dieses Element enthalten darf
(Der Wert muss also kleiner sein, als die angegebene Zahl).
<xs:minExclusive value=”XXX”> Definiert den minimalen Zahlenwert
(exklusive der angegebenen Zahl), die dieses Element enthalten darf
(Der Wert muss also größer sein, als die angegebene Zahl).
<xs:pattern value=”XXX”> Definiert einen regulären Ausdruck, der das
exakte Muster der akzeptierten Daten spezifiziert.
Das folgende Beispiel akzeptiert nur Ganzzahlen von 1 (inklusive) bis 10
(inklusive).
Listing 1.13: XSD - Einschränkungen des Datentyps
<x s : e l e m e n t name=" Beispiel1 ">
<x s : s i m p l e T y p e>
< x s : r e s t r i c t i o n b a s e=" xs:integer ">
<x s : m i n I n c l u s i v e v a l u e="1">
<x s : m a x I n c l u s i v e v a l u e="10">
</ x s : r e s t r i c t i o n>
</ x s : s i m p l e T y p e>
</ x s : e l e m e n t>
Die Häufigkeit, in denen die angegebenen Elemente vorkommen dürfen, kann
über folgende Attribute, direkt in der Elementdefinition definiert werden.
minOccurs Bestimmt wie oft ein Element vorkommen muss. Der Standardwert ist 1.
HTL Salzburg
14
Diplomarbeit
XML und Datenbanken
maxOccurs Bestimmt wie oft ein Element vorkommen darf. Durch die Angabe des Strings ”unbounded”, sind beliebig viele Elemente erlaubt.
Der Standardwert ist 1.
Listing 1.14: XSD - Angabe der Häufigkeit
<x s : e l e m e n t name=" Beispiel " type=" xs:string " minOccurs="0"
maxOccurs=" unbounded "/>
Referenzen Um häufig verwendete Elemente nicht bei jedem Vorkommen wieder neu definieren zu müssen, können diese auch direkt unterhalb
des xs:schema-Elements definiert, und von einer beliebigen Stelle, mittels
<xs:element ref=”[name]”>, darauf referenziert werden.
Listing 1.15: XSD - Referenzen
<? xml version="1.0" ?>
<x s : s c h e m a x m l n s : x s=" http: // www.w3.org /2001/ XMLSchema ">
<x s : e l e m e n t name=" Ueberelement ">
<xs:complexType>
<x s : s e q u e n c e>
< x s : a t t r i b u t e name=" Attribut1 " type=" xs:string "/>
<x s : e l e m e n t r e f=" Beispiel1 "/>
</ x s : s e q u e n c e>
</ xs:complexType>
</ x s : e l e m e n t>
<x s : e l e m e n t name=" Beispiel1 ">
<x s : s i m p l e T y p e>
< x s : r e s t r i c t i o n b a s e=" xs:integer ">
<x s : m i n I n c l u s i v e v a l u e="1">
<x s : m a x I n c l u s i v e v a l u e="10">
</ x s : r e s t r i c t i o n>
</ x s : s i m p l e T y p e>
</ x s : e l e m e n t>
</ x s : s c h e m a>
Aufgrund der Komplexität von XSD, wird hier nicht weiter darauf eingegangen. Die gezeigten Grundlagen sollten ausreichend sein, um dem restlichen
Dokument folgen zu können. Weiterführende Informationen zur XML Schema Definition sind auf den Website des W3C (http://www.w3.org/XML/
Schema) oder in der Einführung der W3Schools (http://www.w3schools.
com/schema/default.asp) verfügbar.
HTL Salzburg
15
Diplomarbeit
1.3
XML und Datenbanken
XPath
XPath (XML Path Language) ist eine Abfragesprachen um auf bestimmte
Bereiche oder Elemente eines XML-Dokumentes zugreifen zu können. XPath
benutzt einen sehr URL-ähnlichen Syntax um einen oder mehrere Knoten zu
selektieren, das Ergebnis mittels eingebauten Funktionen, je nach Wunsch,
einzuschränken und auf Daten innerhalb der Selektion zuzugreifen.
XPath wurde vom W3C (World Wide Web Konsortium) entwickelt und am
16. November 1999 als Empfehlung veröffentlicht.
1.3.1
XPath Syntax
Ein XPath-Ausdruck besteht aus einem oder mehreren Lokalisierungsschritt(en),
wobei jeder Lokalisierungsschritt vom jeweils nächsten durch ein /“-Zeichen
”
getrennt ist.
Ein Lokalisierungsschritt besteht aus:
• einer Achse
• einem Knotentest
• null oder mehrere Prädikate
Achsen beschreiben die Beziehung zwischen dem Kontextknoten (dem gerade aktiven Knoten) und dem zu selektierenden Knoten.
Knotentests definieren den gesuchten Knoten bzw. die gesuchte Knotenmenge genauer.
Prädikate verfeinern die Suche noch weiter.
1.3.2
Achsen
Anhand des folgenden Beispiels werden XPath-Achsen erklärt.
Listing 1.16: Beispiel zur Erklärung von XPath-Achsen
<a>
<b>
<c />
<c />
[ a1 ]
[ b1 ]
[ c1 ]
[ c2 ]
HTL Salzburg
16
Diplomarbeit
<c />
<c />
</b>
<b>
<d>
<e
<e
</d>
<d>
<e
<e
</d>
</b>
</a>
XML und Datenbanken
[ c3 ]
[ c4 ]
/>
/>
[ b2 ]
[ d1 ]
[ e1 ]
[ e2 ]
/>
/>
[ d2 ]
[ e3 ]
[ e4 ]
(vgl. Winkler 2008, Kap. Achsen“)
”
Xpath definiert folgende wichtige Achsen:
HTL Salzburg
17
Diplomarbeit
Achsenname
child
auch: . oder weglassen
descendant
parent
auch: ..
ancestor
following-sibling
precedingsibling
following
preceding
attribute
auch: @
self
auch: .
descendant-orself
auch: //
ancestor-or-self
XML und Datenbanken
Beschreibung
Liefert alle Kindknoten, d.h. alle Knoten die eine hierarchische
Ebene unterhalb des Kontextknotens.
Liefert alle Nachkommen, d.h. alle Knoten die hierarchisch unterhalb des Kontextknotens sind.
Liefert, sofern vorhanden, den Elternknoten, d.h. den Knoten eine
Ebene oberhalb des Kontextknotens.
Liefert alle Vorfahren, d.h. alle
vorhergehenden Knoten, jeweils
um eine Ebene weiter nach oben.
Liefert alle nachfolgenden Geschwisterknoten, d.h. alle nachfolgenden Knoten auf der selben
Ebene, falls vorhanden.
Liefert alle vorhergehenden Geschwisterknoten, d.h. alle vorhergehenden Knoten auf der selben
Ebene, falls vorhanden.
Liefert alle nachfolgenden Geschwisterknoten inkl. deren Nachkommen, falls vorhanden.
Liefert alle Knoten die hierarchisch über dem Kontextknoten
liegen, aber nicht dessen eigene
Vorfahren sind.
Liefert alle Attribute des aktuellen Knotens.
Liefert den aktuellen Knoten
zurück.
Liefert alle descendant-Knoten
inkl. dem Kontextknoten.
Beispiel
Für [b2] sind das hier
die Knoten [d1] und
[d2].
Für [b2] sind das hier
[d1], [e1], [e2], [d2],
[e3] und [e4].
Für [b2] ist das der
Knoten [a1].
Für [d2] sind das hier
[b2] und [a1].
Für [b1] ist das [b2].
Für [b2] ist das [b1].
Für [b1] sind das [b2],
[d1], [e1], [e2], [d2],
[e3] und [e4].
Für [e4] sind das [e3],
[d1], [e1], [e2], [b1],
[c1], [c2], [c3] und [c4].
Für [d2] sind das [d2],
[e3] und [e4].
Liefert alle ancestor-Knoten inkl. Für [d2] sind das [d2],
dem Kontextknoten.
[b2] und [a1].
HTL Salzburg
18
Diplomarbeit
XML und Datenbanken
(vgl. Winkler 2008, Kap. Achsen“)
”
1.3.3
Knotentests
Durch zwei Doppelpunkte getrennt ( ::“), kann nach einer Achse noch ein
”
Knotentest angehängt werden, der der XPath-Ausdruck noch genauer spezifiziert.
Knotentests können z.B. sein:
Knotennamen Es werden nur Knoten mit dem angegebenen Namen selektiert.
* Es werden alle Knoten selektiert, egal mit welchem Namen.
text() Wählt alle Textknoten aus.
comment() Wählt alle Kommentarknoten aus.
node() Wählt alle Knoten beliebigen Typs aus.
Beispiele:
child::abc Wählt alle Kindknoten mit dem Namen abc“ aus.
”
following::* Wählt alle folgenden Knoten aus.
@id Wählt das Attribut id“ aus. Hier muss wegen den Kurzform kein ::“
”
”
angegeben werden.
1.3.4
Prädikate
Um die XPath-Anweisungen noch genauer zu definieren, können optional
noch beliebig viele Prädikate an die Anweisung angehängt werden. Prädikate
stehen werden nach den Achsen und den Knotentests in eckigen Klammern
( [ und ]“) angehängt.
””
”
Die eckigen Klammern können jede Art von XPath-Ausdruck oder Funktion
enthalten, die ein auswertbares Ergebnis zurückliefert.
Beispiele:
HTL Salzburg
19
Diplomarbeit
XML und Datenbanken
child::a[@id ] Liefert jeden Kindknoten mit dem Namen a“ zurück, der
”
ein Attribut id“ enthält.
”
child::b[starts-with(., A“) ] Liefert jeden Knoten mit dem Namen b“
”
”
zurück, dessen Inhalt mit A“ beginnt.
”
Die oben benutzte Funktion starts-with() ist nur ein Beispiel der vielen in
XPath integrierten Funktionen, auf die ich, aufgrund der enormen Anzahl,
nicht näher eingehen möchte und verweise nur auf die ausführliche XPathFunktions-Referenz von w3schools.org (http://www.w3schools.com/xpath/
xpath_functions.asp).
1.3.5
XPath Beispiele
Durch die Anwendung einiger XPath-Beispiele auf das folgende XML-Dokument,
soll die Verwendung von XPath veranschaulicht werden.
Listing 1.17: XML-Dokument zur Veranschaulichung von XPath
<c d k a t a l o g>
<cd v e r l i e h e n="nein">
<j a h r>2099</ j a h r>
< l i e d e r>
< l i e d p o s i t i o n="1">
< t i t e l>Ich bin ein Lied .</ t i t e l>
</ l i e d>
< t i t e l>I’m a song .</titel >
</lied >
</lieder >
</cd >
<cd verliehen =" ja">
<titel >Ein weiterer Albumtitel </ titel >
<kuenstler >Ein weiterer Kuenstler </ kuenstler >
<jahr >2017 </ jahr >
<lieder >
<lied position ="1" >
<titel >Ich bin ein Lied .</titel >
</lied >
<titel >I’m a song .</ t i t e l>
</ l i e d>
</ l i e d e r>
HTL Salzburg
20
Diplomarbeit
XML und Datenbanken
</ cd>
In den folgenden Beispielen werden die Achsen nur angegeben, falls sie wirklich notwendig sind. Ansonsten wird die gekürzte Version verwendet, um die
Beispiele übersichtlicher zu halten.
/cdkatalog/cd Wählt alle cd-Elemente aus, die ein cdkatalog-Elternelement
besitzen.
//cd Wählt alle cd-Elemente aus, egal wo sie sich im Dokument befinden.
//cd[@verliehen = ’nein’ ] Wählt alle cd-Elemente im Dokument bei denen das verliehen-Attribut auf nein“ gesetzt ist.
”
/cdkatalog/cd[count(./lieder/lied) ¿= 2 ] Wählt alle cd-Elemente, die
ein cdkatalog-Elternelement besitzen und mindestens 2 Lieder beinhalten.
//lied[@position = 1, starts-with(./titel, Jon“), ../../jahr ¡ 2000 /titel]
”
Wählt alle Titel von Liedern aus, die an erster Position im Album stehen, deren Titel mit Jon“ beginnt und wo das Album, auf dem das
”
Lieb vorhanden ist, vor 2000 erschienen ist.
XPath-Ausdrücke wie der Letzte der Beispiele zeigen deutlich, dass die Komplexität der Ausdrücke selbst viel schneller steigt, als die Komplexität der
Abfrage selbst und die Ausdrücke dann nur mehr schwer zu verstehen sind.
Um diesem Effekt bei umfassenden Abfragen entgegenzuwirken, wurde vom
W3C der XQuery-Standard auf Basis von XPath entwickelt.
1.4
XQuery
XQuery ist eine, auf XPath aufbauende, Abfragesprache für XML-Dokumente.
Aufgrund dieser Tatsache ist jeder gültige XPath-Ausdruck gleichzeitig ein
gültiger XQuery-Ausdruck.
HTL Salzburg
21
Diplomarbeit
1.4.1
XML und Datenbanken
FLWOR
FLWOR-Ausdrücke (gesprochen: flower“) sind eine Möglichkeit in XQuery
”
um komplexe Abfragen gegliedert und strukturiert zu definieren. FLWORAusdrücke erinnern sehr stark an die SQL-Statements von relationalen Datenbanken, mit der Ausnahme, dass die Daten nicht aus Tabellen, Zeilen und
Spalten, sondern aus XML-Dokumenten abgefragt werden.
FLWOR steht für FOR, LET, WHERE, ORDER BY und RETURN.
Ein simpler FLWOR-Ausdruck, um vom Beispiel-XML-Dokument weiter oben
alle cd-Elemente abzufragen, die nach dem Jahr 2000 erschienen sind, lautet:
Listing 1.18: Simpler FLWOR-Ausdruck
for $c in doc ( " cdkatalog .xml" ) // cd
where $c/ jahr > "2000"
return $c
FOR bindet die Ergebnisse des angegebenen Pfads an eine Variable.
LET definiert eine Variable und weist ihr einen Wert zu.
WHERE dient zur Einschränkung der Abfrage. Hier können eine oder mehrere Bedingung(en) angegeben werden, um die Abfrage auf diese zu
prüfen.
ORDER BY sortiert die Ergebnisse nach dem Ergebnis des angegebenen
Pfads.
RETURN definiert, welche Information von der Abfrage zurückgeliefert
werden soll.
Ein weiteres Beispiel, um vom Beispiel-XML-Dokument weiter oben, unter
Verwendung aller möglichen FLWOR-Ausdrücke, Informationen abzufragen.
Listing 1.19: Komplexer FLWOR-Ausdruck
let $ doc := doc ( " cdkatalog .xml" )
for $c in $ doc // cd
where $c/ jahr > "2000"
order by $ jahr
return $c
HTL Salzburg
22
Diplomarbeit
XML und Datenbanken
Die Abfrage selektiert wieder, wie im oberen Beispiel bereits gezeigt, alle cdElemente, die nach dem Jahr 2000 erschienen sind, jedoch sortier nach deren
Jahreszahlen.
Weiterführende Informationen zu finden sich unter anderem auf http://www.
w3schools.com/xquery/default.asp.
HTL Salzburg
23
Diplomarbeit
XML und Datenbanken
Kapitel 2
Datenbanken
2.1
Warum ist XML keine (gute) Datenbank?
Aufgrund dessen, dass das hierarchische Modell einer XML-Datei sowie die
Unicode-Unterstützung und das, auch von Menschen gut lesbare, Textformat
sehr gut dazu geeignet ist ein Vielzahl verschiedener Daten zu speichern, wird
oft die Meinung vertreten, ein XML-Dokument sei ein gutes Format für eine
Datenbank. Es gibt jedoch zahlreiche Gründe die gegen die Verwendung von
XML als eine Datenbank sprechen.
Das reine Textformat eines XML-Dokumentes ist zwar ein guter Kompromiss,
um die Daten für beide, Menschen und EDV-Systeme, lesbar zu machen,
aber gerade für Computersysteme erhöht es den Aufwand, um an bestimmte
Daten zu kommen, enorm, da das Dokument bei jedem Zugriff erneut geparst
werden muss.
Weiteres fehlen essenzielle Features einer richtigen Datenbank, wie z.B. Indizierung, zur schnellen Suche innerhalb der Datenbank, Mehrbenutzerunterstützung, da eine XML-Datei nicht ohne Weiteres von mehreren Benutzern gleichzeitig benutzt werden kann, (Ausfall-)Sicherheit, um die Konsistenz der Daten zu gewährleisten oder Protokollierung der ausgeführten
Änderungen/Abfragen.
XML-Dokumente können also nur bedingt, in Fällen in denen die oben genannten Punkte keine tragende Rolle spielen (Konfigurationsdateien, Adressdatenbank, etc.) sinnvoll als Datenbank eingesetzt werden.
HTL Salzburg
24
Diplomarbeit
2.2
XML und Datenbanken
XML Verwendung mit Datenbanken
XML-Dokumente können auf 2 verschiedene Arten mit Datenbanken verwendet werden. Entweder als reines Datenaustauschformat oder die Struktur des
Dokuments wird wirklich in der Datenbank gespeichert.
2.2.1
Verwendung von XML als Datenaustauschformat
Sind von einem XML-Dokument wirklich nur die Daten, nicht aber die Struktur des XML-Dokuments von Bedeutung, können die Daten aus dem Dokument gefiltert werden und in normalen Spalten einer Tabelle gespeichert
werden. Diesen Vorgang nennt man auch Shredding. Der umgekehrte Vorgang, die in den Spalten der Tabelle gespeicherten Daten wieder zu einem
XML-Dokuments zusammenzufügen, nennt man publishing.
Abbildung 2.1: Shredding / Publishing
(Steegmans, Bourret, Cline, Guyennet, Kulkarni, Priestley, Sylenko, Wahli
2004, S.7)
Als Beispiel soll das folgende Dokument mittels Shredding in einer relationalen Datenbank gespeichert werden.
<c d s>
<cd>
HTL Salzburg
25
Diplomarbeit
XML und Datenbanken
<j a h r>2099</ j a h r>
< l i e d e r>
</ l i e d>
</lied >
</lieder >
</cd >
<cd >
...
</cd >
</cds >
Infolge dessen müssen 2 Tabellen angelegt werden, nämlich cds und lieder.
Die Daten jeder CD werden in einer Zeile der Tabelle cds gespeichert.
CDNummer Titel
Kuenstler
1
Ein Albumtitel Ein Kuenstler
...
...
...
Jahr
2099
...
Tabelle 2.1: CDs-Tabelle
Die einzelnen Lieder der CD werden von der zweiten Tabelle, lieder, durch
den Primärschlüssel in der Tabelle cds, auf die jeweilige CD bezogen.
CDNummer
1
1
...
Position
1
2
...
Titel
Ich bin ein Lied.
I’m a song.
...
Tabelle 2.2: Lieder-Tabelle
Bei dieser Art der Verwendung von XML-Dokumenten mit Datenbanken ist
die XML-Struktur selbst ist in der Datenbank nicht ersichtlich. Datenbanken
die diese Art der Speicherung verwenden, nennt man XML-enabled Datenbanken.
HTL Salzburg
26
Diplomarbeit
2.2.2
XML und Datenbanken
Direktes Speichern der XML-Dokumente
Eine weitere Möglichkeit der Speicherung in Datenbanken, ist die direkte
Speicherung des XML-Dokumentes in eine Reihe von Tabellen. Im Beispiel
des XML-Dokumentes weiter oben, wäre das zum Beispiel:
Jedem hinzugefügten Dokument wird eine eindeutige Identifikationsnummer
und ein eindeutiger Name zugewiesen. Diese Daten werden in der DokumenteTabelle abgelegt.
ID
1
2
...
Name
sampleProduct.xml
product2211.xml
...
Tabelle 2.3: Dokumente-Tabelle
Durch Bezugnahme auf die Document-ID, die ParentID des Dokumentes bzw.
(in tieferen Ebenen des Dokumentes) auf die sonst jeweilige ParentID des
übergeordneten Elements, kann nun die komplette hierarchische Struktur
eines XML-Dokumentes in weiteren Tabellen abgebildet werden.
ElementID
1
2
3
4
5
6
7
8
9
...
DocumentID
1
1
1
1
1
1
1
1
1
...
ParentID
NULL
1
1
2
2
2
2
7
8
...
Name
cds
cd
cd
titel
kuenstler
jahr
lieder
lied
titel
...
OrderInParent
1
1
2
1
2
3
4
1
1
...
Tabelle 2.4: Elemente-Tabelle
HTL Salzburg
27
Diplomarbeit
XML und Datenbanken
AttributeID DocumentID ParentID Name
Value
1
1
8
position 1
...
...
...
...
...
Tabelle 2.5: Attribute-Tabelle
TextID
1
2
3
4
...
DocumentID
1
1
1
1
...
ParentID
4
5
6
9
...
Value
Ein Albumtitel
Ein Kuenstler
2099
Ich bin ein Lied.
...
Value
1
1
1
1
...
Tabelle 2.6: Text-Tabelle
Die Struktur des XML-Dokumentes wird also 1:1 in der Datenbank abgebildet, dass Informationen über Attribute oder Elementtypen erhalten bleiben. Datenbanken die diese Variante der Speicherung verwenden, nennt man
XML-native Datenbanken.
Abbildung 2.2: Direktes Speichern der XML Dokumente in der Datenbank
2004, S.8)
HTL Salzburg
28
Diplomarbeit
2.3
XML und Datenbanken
XML-enabled Datenbanken
Wie weiter oben schon erwähnt, ist das Datenmodell bei XML-enabled Datenbank nicht gleich dem des XML-Dokumentes und dient meist nur zur
Speicherung der Daten und nicht der Struktur. Solche Datenbanken bestehen meist nur aus einer Software, die einer relationalen Datenbank vorgeschaltet wird, um die XML-Daten von der XML-Struktur in die Struktur der
Datenbank zu konvertieren - und vice versa.
Aufgrund der Einschränkungen von relationalen Datenbanken, können durch
dieses Verfahren eine Eigenschaften von XML-Dokumenten nicht abgebildet
werden, zum Beispiel Gemischter Inhalt, Referenzen, Kommentare, Reihenfolge der Elemente etc.
XML wird in diesem Anwendungsfall nur als Datenaustauschformat verwendet. Das XML-Dokument besteht nur temporär und kann nicht eindeutig
identifiziert werden. Auch ein 100
Die Verwendung von XML-enabled Datenbanken ist also ausschließlich für
Anwendungen verwendbar, bei denen nur die in den XML-Dokumenten gespeicherten Daten von Belang sind, nicht aber die Struktur des Dokuments.
Es ist auch ein Weg um bestehende Daten aus einer relationalen Datenbank
in XML-Anwendungen weiterzuverwenden.
2.3.1
Mapping
Um die XML-Daten an der richtigen Stelle in der Datenbank ablegen zu
können, müssen die Zugehörigkeiten der XML-Elemente zu deren entsprechenden Datenbanktabellen festgelegt werden, dies geschieht durch das sogenannten Mapping. Der Vorteil eines solchen Mapping besteht darin, dass vorhandene Daten in der Datenbank durch verschiedene Mappings für verschiedene XML-Dokumente verwendet werden können. Es bestehen 3 Möglichkeiten
dieser Zuordnung:
• table-based mapping
• object-relational mapping
• query languages
Zu Beachten ist hierbei, dass table-based mapping und object-relational mapping bidirektionale Mappingvarianten darstellen, sie erlauben also den Datentransfer von und zur Datenbank. Query languages (Abfragesprachen) bieten
zur Zeit nur den Transfer von der Datenbank zur Applikation.
HTL Salzburg
29
Diplomarbeit
XML und Datenbanken
Table-Based Mapping
Für die Verwendung von XML-Dokumenten mit einem table-based mapping,
muss das XML-Dokument die selbe logische Struktur wie die Tabelle aufweisen, auf die die Daten abgebildet werden.
<d a t a b a s e>
<c d s>
<cd>
<nummer>1</nummer>
<j a h r>2099</ j a h r>
</ cd>
<cd>
...
</ cd>
</ c d s>
< l i e d e r>
< l i e d>
<cdnummer>1</cdnummer>
<p o s i t i o n>1</ p o s i t i o n>
</ l i e d>
< l i e d>
<cdnummer>1</cdnummer>
<p o s i t i o n>1</ p o s i t i o n>
</lied >
</lieder >
</database >
Durch die Einschränkungen durch die relationale Datenbank ist im XMLDokument nur eine hierarchische Ebene möglich. Unter- bzw. übergeordnete
Elemente müssen sowohl im XML-Dokument als auch in der Datenbank über
eindeutige IDs verknüpft werden. Diese IDs erzeugen, einem entsprechend
großen Datensatz vorausgesetzt, einen nicht zu unterschätzenden Overhead,
der auf jeden Fall berücksichtigt werden muss, da die IDs immer mindestens
zweimal angegeben werden müssen.
Auch eine weitere Verschachtelung der von der Datenbank erzeugten XMLDokumente ist höchstens später über eine zusätzliche XSL-Transformation
möglich.
HTL Salzburg
30
Diplomarbeit
XML und Datenbanken
Abbildung 2.3: XSLT Transformation bei Table-Based Mapping
2004, S.585)
Trotz der anscheinend großen Nachteile dieser Mappingvariante wird sie dennoch häufig verwendet, da die Software zur Transformation der Daten zwischen XML-Dokument und Datenbank sehr simpel zu realisieren ist und das
Einfügen von Daten in die Datenbank sehr effizient von Statten geht (z.B.
beim Replizieren einer Datenbank).
Object-Relational Mapping
Mittel des Object-Relational Mappings können auch tief verschachtelte XMLDokumente direkt behandelt werden. Das XML-Dokument wird hierzu als
ein serialisierter Baum von Objekten und deren Eigenschaften betrachtet
werden, die die Beziehungen der Elemente widerspiegeln.
Die Struktur wird dann wie folgt auf Datenbank abgebildet:
Objekte auf Tabellen (XML: Komplexe Typen)
Eigenschaften auf die Spalten der Tabellen (XML: Einfache Typen, Attribute)
Beziehungen auf Primär- bzw. Fremdschlüssel (XML: Referenzen)
<c d s>
<cd>
<j a h r>2099</ j a h r>
< l i e d e r>
HTL Salzburg
31
Diplomarbeit
XML und Datenbanken
Abbildung 2.4: Object-Relational Mapping
2004, S.586)
</ l i e d>
</lied >
</lieder >
</cd >
<cd >
...
</cd >
</cds >
Im Fall des obigen Beispiel-XML-Dokuments lassen sich 2 Objekte sowie
deren Eigenschaften identifizieren:
• Objekt cd
– Eigenschaft ”titel”
– Eigenschaft ”kuenstler”
– Eigenschaft ”jahr”
• Objekt lied
HTL Salzburg
32
Diplomarbeit
XML und Datenbanken
– Eigenschaft ”position”
– Eigenschaft ”titel”
Diese 2 Objekte könnten wie folgt auf die Tabellen abgebildet werden:
ID
1
...
titel
kuenstler
Ein Albumtitel Ein Kuenstler
...
...
jahr
2099
...
ID
1
2
...
cdID
1
1
...
position
1
2
...
titel
Ich bin ein Lied.
I’m a song.
...
Tabelle 2.8: Lieder-Tabelle
Query Languages
Query Languages (Abfragesprachen) eliminieren den Bedarf einer engen Bindung zwischen den Schemata von XML-Dokument und Datenbank, und bieten somit mehr Spielraum beim Erzeugen von XML-Dokumenten aus Datenbanken. Die zwei wichtigsten Vertreter solcher Abfragesprachen sind:
• SQL/XML
• XQuery
SQL/XML SQL/XML stellt eine Erweiterung von SQL dar und ist für
dein Einsatz mit XML-enabled relationalen Datenbanken konzipiert worden.
Die Hauptunterschiede zu SQL sind die Einführung eines XML-Datentyps
und Funktionen zur Erzeugung von XML-Dokumenten (Elemente, Attribute,
...).
HTL Salzburg
33
Diplomarbeit
XML und Datenbanken
XML Der XML-Datentyp. Kann entweder NULL, Text oder ein XML-Dokument
enthalten.
XMLAgg() Eine Funktion, um XML-Daten bei ”GROUP BYAbfragen in
Gruppen zusammenzufassen.
XMLAttributes() Eine Funktion, um XML-Attribute in XML-Elemente
einzufügen.
XMLConcat() Eine Funktion, um zwei oder mehrere XML-Werte zu verknüpfen.
XMLElement() Eine Funktion, um ein XML-Element in der Ausgabe zu
erzeugen.
XMLForest() Eine Funktion, um eine Liste (”Forest”) von XML-Elementen
aus einer Liste relationaler Daten zu erzeugen.
XMLNamespaces() Eine Funktion, um Namensräume in einem XML-Dokument
zu erzeugen.
XMLSerialize() Eine Funktion, um einen XML-Wert in eine Zeichenkette
zu serialisieren.
(vgl. Gennick 2003, Abschnitt ”The SQL/XML Standard”)
Als Beispiel werden nun aus folgenden Tabellen einer relationalen Datenbank
Daten mittels SQL/XML abgefragt und daraus ein XML-Dokument erzeugt.
CDNummer
1
2
...
Titel
Ein Albumtitel
Noch ein Albumtitel
...
Kuenstler
Ein Kuenstler
Noch ein Kuenstler
...
Jahr
2099
3099
...
Die SQL/XML-Anweisung, um aus der Datenbank alle Alben abzufragen,
lautet:
HTL Salzburg
34
Diplomarbeit
XML und Datenbanken
Listing 2.4: SQL/XML Beispiel
SELECT XMLELEMENT ( NAME cd , XMLATTRIBUTES ( CDs . CDNummer AS
cdnummer ) ,
XMLELEMENT ( NAME titel , CDs . Titel ) ,
XMLELEMENT ( NAME kuenstler , CDs . Kuenstler ) ,
XMLELEMENT ( NAME jahr , CDs . Jahr ) )
AS
cdxml
FROM
CDs
Für jeden Datensatz in der CDs Tabelle der Datenbank wird ein XMLDokument erstellt, zum Beispiel:
Listing 2.5: SQL/XML Beispiel
<cd cdnummer="1">
<j a h r>2099</ j a h r>
</ cd>
XQuery XQuery ist eine vom W3C (World Wide Web Consortium) definierte Abfragesprache zur Abfrage von Daten aus XML-Dokumenten. Da
Daten eben nur aus XML-Dokumenten abgefragt werden können, muss zur
Verwendung von XQuery mit relationalen Datenbanken, zuerst ein virtuelles
XML-Dokument erzeugt werden (z.B. mittels einem Table-Based Mapping).
Die Syntax von XQuery wurde in diesem Dokument schon näher erläutert.
Siehe dazu Abschnitt 1.4, ”XQuery”.
2.4
Native XML-Datenbanken
Native XML-Datenbanken benutzen das XML-Modell direkt und können so
beliebige XML-Dokumente speichern. Sie sind daher bestens für Anwendungen mit sehr komplex und tief verschachtelten oder semistrukturierten Daten,
deren Speicherung in traditionellen relationalen Datenbanken ein Problem
darstellt.
Da bei nativen XML-Datenbanken jedes beliebige XML-Dokument, ohne vorheriges Mapping und/oder Konfigurieren der Datenbank, gespeichert werden
kann, sind sie auch hervorragend für Anwendungen einsetzbar, in denen die
endgültige XML- bzw. Datenstruktur noch nicht endgültig festgelegt ist.
HTL Salzburg
35
Diplomarbeit
XML und Datenbanken
Abbildung 2.5: XQuery Abfrage einer relationalen Datenbank
2004, S.16)
Prädestinierte Einsatzgebiete für native XML-Datenbanken sind somit:
• Archivierung von (XML-)Dokumenten
• Speicherung von semistrukturierten Daten, also Daten deren Struktur
nicht immer die selbe ist.
Laut http://www.xmldb.org ist eine native XML-Datenbank eine die:
• ein Datenmodell für XML definiert.
• ein XML-Dokument als kleinste logische Einheit zur Speicherung verwendet.
• eine beliebige physische Speichermöglichkeit verwendet.
(vgl. http://www.xmldb.org)
HTL Salzburg
36
Diplomarbeit
XML und Datenbanken
XML-Datenmodell Das XML-Datenmodell einer nativen XML-Datenbank
definiert, welche logischen Einheiten eines XML-Dokuments signifikant sind.
Das minimale Modell enthält Elemente, Attribute, Text und die Reihenfolge
von Dokumenten. Je nach Anwendung sind zusätzliche Dinge definiert, z.B.
Referenzen, CDATA-Bereiche1 , etc.
Heutzutage ist das XPath-Datenmodell bei nativen XML-Datenbanken sehr
verbreitet. Dieses wird jedoch zunehmend vom XQuery-Datenmodell verdrängt. Mehr Informationen über dieses standardisierte Datenmodell finden
Sie auf der Website des W3C (http://www.w3.org/TR/xpath-datamodel/)
Kleinste logische Einheit Die kleinste, zusammenhängende Speichereinheit einer relationalen Datenbank sind die Reihen (Zeilen) einer Tabelle.
Genauso besitzt eine XML-Datenbank ein XML-Dokument als kleinste, zusammenhängende Speichereinheit. Jedes XML-Fragment, das nur von einem
einzelnen Element umschlossen wird, gilt hierbei als XML-Dokument.
Beliebige physische Speichermöglichkeit / Implementation Laut
Definition darf eine native XML-Datenbank jede Art der Implementation
nutzen, z.B.:
• Speicherung der XML-Dokumente in CLOBs (Character Large OBject)
einer relationalen Datenbank und Indizierung der einzelnen Elemente
und Attribute.
• Speicherung der geparsten XML-Dokumente in mehreren einzelnen Tabellen (Elemente, Attribute, Text, ...).
• Speicherung der geparsten XML-Dokumente als DOM-Tree in einer
objektorientierten Datenbank.
• Speicherung der geparsten XML-Dokumente in indizierten Hash-Tabellen.
• Speicherung XML-Dokumente als XML-Dateien und zusätzliche Indizierung durch Hash-Tabellen.
(vgl Steegmans, Bourret, Cline, Guyennet, Kulkarni, Priestley, Sylenko,
Wahli 2004, S.20)
Character Data (Zeichendaten) definieren in XML einen Bereich, der nur Text enthält
und nicht interpretiert werden soll.
1
HTL Salzburg
37
Diplomarbeit
XML und Datenbanken
Das Einfügen und Abfragen von Daten aus einer nativen XML-Datenbank
erfolgt meist über Anfragesprachen wie XQuery bzw. XUpdate in Verbindung
mit produktspezifischen Schnittstellen / Bibliotheken.
2.5
Berkeley DB XML
Unter Verwendung der Berkeley DB XML von Oracle, soll nun die Verwendung einer XML-Datenbank anhand einiger praktischer Beispiele erläutert
werden.
Berkeley DB XML (BDB XML) ist eine, in Anwendungen, einbettbare (embeddable) Datenbankengine. Es wird zur Benutzung also kein eigener Datenbankserver benötigt, sondern die betreffende Anwendung kommuniziert
direkt - über eine entsprechende Bibliothek - mit der Datenbank. Berkeley
DB XML enthält aber auch ein Kommandozeilenprogramm, um die Funktionen auch ohne eine eigene Anwendung testen und mit XML-Daten arbeiten
zu können.
2.5.1
Einführung in Berkeley DB XML
Im folgenden Abschnitt soll der grundlegende Umgang mit der Berkeley DB
XML (Einfügen/Abfragen von Daten, Erzeugen von Containern, Sortierung,
etc.) mittels dem beigelegten Kommandozeilenprogramm erläutert werden.
Container
Berkeley DB XML verwendet sogenannte Container um jegliche Art von
XML-Daten zu speichern. Container enthalten eine Sammlung von XMLDokumenten und Metadaten über diese Daten (z.B. Indizes). Die XMLDokumente können hierbei entweder als komplette Dokumente in dem Container abgespeichert werden oder zuerst in die einzelnen Knoten aufgeteilt
und dann als mehrere Teildokumente gespeichert werden. Da die Variante
der Speicherung der einzelnen Knoten meist performanter arbeitet als die
Speicherung des kompletten Dokuments, ist dies auch die Standardeinstellung.
Die folgenden Befehle werden alle im Kommandozeilentool dbxml(.exe) ausgeführt, das sich im Ordner [Pfad der Berkeley DB XML Installation]/bin/dbxml/
befindet.
HTL Salzburg
38
Diplomarbeit
XML und Datenbanken
Beim Starten des Programms sollte die folgende Eingabeaufforderung erscheinen.
Listing 2.6: BDB XML Kommandozeile
dbxml>
Das Programm erwartet ab sofort die Eingabe von Befehlen.
Um mit der Berkeley DB XML experimentieren zu können, benötigen wir
zuerst einen Container. Wir erzeugen hier einen neuen Container mit dem
folgenden Befehl.
Listing 2.7: Erzeugen eines neuen Containers
dbxml> createContainer cds . dbxml
Der Befehl erzeugt einen leeren Container mit dem Namen cds.dbxml im
Arbeitsverzeichnis. Der Name des Containers kann frei gewählt werden, es
empfiehlt sich jedoch auch Leerzeichen, Sonderzeichen und sonstige potentielle Hürden zu verzichten. Die Dateiendung .dbxml dient nur zur Identifikation
der Datei als BDB XML-Container und ist nicht zwingend vorgeschrieben.
Nach dem erzeugen eines neuen Containers wird dieser automatisch als aktiven Container geöffnet. Soll mit einem bestehenden Container gearbeitet
werden, muss dieser erst mit dem Befehl
Listing 2.8: Erzeugen eines neuen Containers
dbxml> openContainer [ dateiname ]
geladen werden. In unserem fall wäre also der Befehl
Listing 2.9: Öffnen eines bestehenden Containers
dbxml> openContainer cds . dbxml
nötig.
Arbeiten mit Daten
Für das Einfügen von XML-Dokumenten zur Datenbank besteht der Befehl
Listing 2.10: Öffnen eines bestehenden Containers - Beispiel
dbxml> putDocument [ name ] [ wert ] [ f | s | q ]
HTL Salzburg
39
Diplomarbeit
XML und Datenbanken
[name ] ist ein eindeutiger Name für das Dokument, der es in der Datenbank
identifiziert.
[f—s—q ] gibt an, in welcher Form die Daten eingefügt werden. f importiert
die Daten von einer Datei. s fügt die, als Zeichenkette, übergebenen Daten in die Datenbank ein. q fügt das Ergebnis des übergebenen XQueryAusdrucks in die Datenbank ein.
[wert ] ist ein Parameter, dessen Inhalt von dem Wert des letzen Parameters abhängig ist. Ist der dritte Parameter f, dann wird hier der Dateiname der XML-Datei angegeben, die in die Datenbank importiert
werden soll. Ist er s wird hier das Dokument direkt, von 2 einfachen
Anführungszeichen abgegrenzt, übergeben. Wird der wird des letzen
Parameters auf q gesetzt, muss hier ein XQuery-Ausdruck angegeben
werden, der die einzufügenden Daten erzeugt.
Wir fügen nun ein paar Dokumente zur Datenbank hinzu, um darauf Abfragen ausführen zu können.
Listing 2.11: Hinzufügen von Dokumenten - Beispiel
dbxml> putDocument cd1 ’<cd >
<titel >Ein Albumtitel </ titel >
<kuenstler >Ein Kuenstler </ kuenstler >
<jahr >2099 </ jahr >
<lieder >
<titel >Ich bin ein Lied .</titel >
</lied >
<titel >I am a song .</titel >
</lied >
</lieder >
</cd >’ s
dbxml> putDocument cd2 ’<cd >
<titel >An Album Title </ titel >
<kuenstler >An Artist </ kuenstler >
<jahr >3054 </ jahr >
<lieder >
<titel >Ich bin auch ein Lied .</titel >
</lied >
<titel >I am another song .</titel >
</lied >
</lieder >
HTL Salzburg
40
Diplomarbeit
XML und Datenbanken
</cd >’ s
Der Container beinhaltet nun ein paar CD-Einträge, aus denen wir Daten
über XQuery-Ausdrücke abfragen können. Abfragen können über den Befehl
Listing 2.12: Abfrage von Daten
dbxml> query ’[ Abfrage ]’
ausgeführt werden. Zum Abfragen aller Albumtitel benötigen wir also zum
Beispiel:
Listing 2.13: Abfrage von Daten - Beispiel
dbxml> query ’collection (" cds. dbxml ")/cd/ titel / string () ’
2 objects returned for eager expression ’collection (" cds. dbxml ")
/cd/ titel / string () ’
Wie zu sehen ist, werden 2 Objekte als Ergebnis gefunden. Um diese anzuzeigen benutzen wir den Befehl
Listing 2.14: Anzeigen der Ergebnisse
dbxml> print
An Album Title
Ein Albumtitel
Mit solch einer Abfrage an die BDB XML werden, wie bei einem SELECTStatement bei einer relationalen Datenbank, Daten von der Datenbank abgefragt. Mittel der Funktion colletion() wird der Container bekanntgegeben,
von dem abgefragt werden soll (äquivalent zum SELECT ... FROM ... bei
relationalen Datenbanken). Durch die logische Verknüpfung von mehreren
collection()-Aufrufen, können auch Daten von mehreren Containern gleichzeitig abgefragt werden, genau so wie einzelne, hinzugefügte Dokumente über
die von XPath bekannte Funktion doc().
Als nächster Schritt können komplexere XQuery-Ausdrücke zum Abfragen
bzw. Einfügen von Daten benutzt werden. Um z.B. 10 CD-Einträge automatisiert in die Datenbank einzufügen, wäre folgender XQuery-Ausdruck denkbar:
Listing 2.15: XQuery-Ausdrücke in BDB XML
dbxml> putDocument "" ’
for $i in (0 to 19)
return
HTL Salzburg
41
Diplomarbeit
XML und Datenbanken
<cd >
<titel > Titel {$i}</titel >
<kuenstler > Kuenstler {$i}</ kuenstler >
<jahr >{$i}{$i}{$i}{$i}</jahr >
<lieder >
<titel >Lied {$i}</titel >
</lied >
<titel >Song {$i}</titel >
</lied >
</lieder >
</cd >’ q
Die Einträge werden anhand der Laufvariable i benannt und bekommen,
durch die Angabe eines leeren Namens, automatisch einen eindeutigen Namen
zugewiesen.
Unter Verwendung aller in XPath bzw. XQuery verfügbaren Ausdrücke, können
beliebig komplexe Abfragen erstellt werden. Auf dies wird jedoch nicht weiter eingegangen. Weitere Informationen zur Abfrage über XQuery-Ausdrücke
finden Sie im Kapitel 1.4, ”XQuery”, und auf den dort und im Literaturverzeichnis angegebenen Links.
2.5.2
Berkeley DB XML API
Das Kommandozeilentool, das im letzten Kapitel verwendet wurde, ist eigentlich nur ein Programm um die Fahigkeiten der Berkeley DB XML auszuprobieren und kennenzulernen bzw. um einzelne Datensätze manuell zu
editieren. Die BDB XML ist als ëmbedded”Datenbank konzipiert und wird
in den meisten Anwendungsfällen direkt in ein Programm eingebettet. Die
dazu vorhandenen Schnittstellen werden im folgenden Kapitel erläutert.
Es existiert ein Berkeley DB XML API mit Bindings für mehrere Programmiersprachen (u.a. Python, Java, C++). Die zur Verfügung stehenden Objekte und Methoden sind in allen Sprachen die selben.
Klassen und Methoden
XmlManager XmlManager ist eines der wichtigsten Interfaces der Datenbank. Der Manager verwaltet die Container, bereitet Abfragen vor und führt
diese aus, kümmert sich um benötigte FileStreams, etc, etc.
HTL Salzburg
42
Diplomarbeit
XML und Datenbanken
XmlContainer XmlContainer kapselt einen Dokumenten-Container inklusive dessen Indizes und Statistiken. Er bietet außerdem Methoden, um die
gespeicherten Dokumente zu verwalten (einfügen, löschen, indizieren).
XmlUpdateContext XmlUpdateContext bietet ein Objekt, um UpdateAnfragen auf einen XmlContainer auszuführen (einfügen bzw. ändern von
Daten).
XmlQueryContext XmlQueryContext bietet ein Objekt, um Abfragen
auf einen XmlContainer auszuführen. Er bietet außerdem Variablen- und Namespacebindung sowie Parameter, wie die Ergebnisse zurückgeliefert werden
sollen.
XmlResults XMLResults fasst alle Ergebnisse einer Abfrage zusammen
und besteht aus einer Sammlung von XmlValue-Objecten.
XmlValue XmlValue kapselt den Wert eines Knotens in einem XML-Dokument.
Der Wert kann von einem jedem beliebigen Typ sein, der in der XmlValue::Type Enumeration definiert ist (u.a. NONE, STRING, DOUBLE, BOOLEAN, NODE).
XmlException XmlException ist repräsentiert den Ausnahmetyp, der geworfen wird, sollte ein Fehler in der Abarbeitung des Programms auftreten.
Das Programm muss diese Ausnahme abfangen können.
Mittel dieser kleinen Auswahl der in der API verfügbaren Klassen und Methoden, lässt sich bereits ein Programm erstellen, das die Berkeley DB XML
verwendet.
C++ Beispielprogramm
Die im vorhergehenden Kapitel erwähnten Teile der BDB XML API werden
nun zu einem simplen Beispielprogramm in C++ zusammengefügt. Der Ablauf des Programms wird einen Container anlegen, ihn mit Daten füllen und
anschließend wieder Daten aus ihm abfragen.
Um die Bibliothek verwenden zu können, muss die Headerdatei eingebunden
werden:
HTL Salzburg
43
Diplomarbeit
XML und Datenbanken
Listing 2.16: Einbinden der Headerdatei
# include <dbxml/DbXml . hpp>
Optional kann noch der Namensraum definiert werden, der verwendet werden
soll.
Listing 2.17: Namensraum definieren
using namespace DbXml ;
Der wichtigste Teil der Anwendung ist der XmlManager, der fast alle Abläufe
in der Datenbank verwaltet. Es muss vor der Verwendung der Datenbank
erzeugt werden.
Listing 2.18: XmlManager erzeugen
XmlManager mgr ;
Um einen Container und einen Kontext darauf zu erzeugen, muss die Methode .createContainer des XmlManager s aufgerufen werden und einem XmlContainer zugewiesen werden.
Listing 2.19: XmlManager erzeugen
XmlContainer cont = mgr . createContainer ( "cds. dbxml " ) ;
Um Daten in den gerade erzeugen Container einzufügen, benötigen wird einen
XmlUpdateContext, der wieder über eine Methode der XmlManager s erzeugt
werden kann.
Listing 2.20: XmlUpdateContext erzeugen
XmlUpdateContext uc = mgr . createUpdateContext ( ) ;
Mit Hilfe des XmlUpdateContexts können nun Daten in den Container eingefügt werden.
Listing 2.21: Einfügen von Daten
cont . putDocument ( "cd1" , "<cd ><titel >Ein Albumtitel </ titel ><
kuenstler >Ein Kuenstler </ kuenstler ><jahr >2099 </ jahr ><lieder ><
lied position ="1"><titel >Ich bin ein Lied .</titel ></lied ><
lied position ="2"><titel >I am a song .</titel ></lied ></ lieder
></cd >" , uc ) ;
cont . putDocument ( "cd2" , "<cd ><titel >An Album Title </ titel ><
kuenstler >An Artist </ kuenstler ><jahr >3054 </ jahr ><lieder ><lied
position ="1"><titel >Ich bin auch ein Lied .</titel ></lied ><
lied position ="2"><titel >I am another song .</titel ></lied ></
lieder ></cd >" , uc ) ;
HTL Salzburg
44
Diplomarbeit
XML und Datenbanken
Zur Abfrage von Informationan aus den hinzugefügten Daten, wird nun ein
XmlQueryContext benötigt.
Listing 2.22: XmlQueryContext erzeugen
XmlQueryContext qc = mgr . createQueryContext ( ) ;
Mit Hilfe des XmlQueryContexts können nun Daten aus dem Container abgefragt und in einem XmlResults-Objekt gespeichert werden.
Listing 2.23: Daten abfragen
XmlResults res = mgr . query ( " collection (’cds. dbxml ’)/cd/ titel /
string ()" , qc ) ;
Um die Daten aus dem XmlResults auszulesen, muss ein XmlValue-Objekt
angelegt werden. In dieses XmlValue-Objekt können nun die einzelnen XmlValues innerhalb des XmlResult-Objektes geschrieben und ausgegeben werden.
Listing 2.24: Ergebnisse auslesen und ausgeben
XmlValue value ;
while ( res . next ( value ) )
cout << "Wert: " << value . asString ( ) << endl ;
Um die Fehler, die während des Ablaufs des Programms auftreten können,
abzufangen, muss der gesamte Ablauf von einem try-catch-Block umschlossen, und die XmlException abgefangen werden.
Listing 2.25: Abfangen der XmlException
try {
<<Programmcode>>
} catch ( XmlException &e ) {
cout << " Fehler : " << e . what ( ) << endl ;
}
Das komplette, lauffähige C++ Beispielprogramm:
Listing 2.26: Komplettes C++ Beispielprogramm
# include <s t r i n g >
# include <f s t r e a m >
# include " dbxml / DbXml .hpp"
using namespace std ;
using namespace DbXml ;
HTL Salzburg
45
Diplomarbeit
XML und Datenbanken
int main ( int argc , char ∗∗ argv )
{
try {
XmlManager mgr ;
XmlContainer cont = mgr . createContainer ( "cds. dbxml " ) ;
XmlUpdateContext uc = mgr . createUpdateContext ( ) ;
cont . putDocument ( "cd1" , "<cd ><titel >Ein Albumtitel </ titel ><
kuenstler >Ein Kuenstler </ kuenstler ><jahr >2099 </ jahr ><
lieder ><lied position ="1"><titel >Ich bin ein Lied .</titel
></lied ><lied position ="2"><titel >I am a song .</titel ></
lied ></ lieder ></cd >" , uc ) ;
cont . putDocument ( "cd2" , "<cd ><titel >An Album Title </ titel ><
kuenstler >An Artist </ kuenstler ><jahr >3054 </ jahr ><lieder ><
lied position ="1"><titel >Ich bin auch ein Lied .</titel ></
lied ><lied position ="2"><titel >I am another song .</titel
></lied ></ lieder ></cd >" , uc ) ;
XmlQueryContext qc = mgr . createQueryContext ( ) ;
XmlResults res = mgr . query ( " collection (’cds. dbxml ’)/cd/ titel
/ string ()" , qc ) ;
XmlValue value ;
while ( res . next ( value ) )
cout << "Wert: " << value . asString ( ) << endl ;
} catch ( XmlException &e ) {
std : : cout << " Fehler : " << e . what ( ) << std : : endl ;
}
return 0 ;
}
(vgl. Oracle 2008[1], S.32)
HTL Salzburg
46
Diplomarbeit
XML und Datenbanken
Literaturverzeichnis
Powell 2007: Gavin Powell, Beginning XML Databases. (Indianapolis
2007)
Williams 2000: Kevin Williams, Professional XML Databases. (Birmingham 2000)
Schmidt, Tomczyk 2002: Andreas Schmidt, Peter Tomczyk, Datenbanken und XML: Konzepte, Anwendungen, Systeme. (Heidelberg 2002)
Boag, Chamberlin, Fernández, Florescu, Robie, Siméon 2007: Scott
Boag, Don Chamberlin, Mary Fernández, Daniela Florescu, Jonathan
Robie, Jérôme Siméon, XQuery 1.0: An XML Query Language. Internet: http://www.w3.org/TR/xquery/ (28.01.2008 19:45:37)
Bray, Paoli, Sperberg-McQueen, Maler 2000: Tim Bray, Jean Paoli,
C. M. Sperberg-McQueen, Eve Maler, Extensible Markup Language
(XML) 1.0 (Zweite Auflage). Internet: http://edition-w3c.de/TR/
2000/REC-xml-20001006/ (12.02.2008 21:09:23)
Clark, DeRose 1999: James Clark, Steve DeRose, XML Path Language (XPath) Version 1.0. Internet: http://www.obqo.de/w3c-trans/
xpath-de-20020226 (21.02.2008 18:59:07)
Jänicke 2007: Christian Jänicke, XML, DTD und XML-Schema. Internet: http://www.bitworld.de/grundlagen_xml.html (12.02.2008
21:14:29)
Klein 2001: Klein Oliver, Datenbanken und XML. Internet: http://
www.urz.uni-heidelberg.de/imperia/md/content/urz/programme/
db_und_xml.pdf (03.02.2008 10:08:12)
Obasanjo 2001: Dare Obasanjo, An Exploration Of Xml In Database
Management Systems. Internet: http://www.25hoursaday.com/StoringAndQueryingXML.
html (05.02.2008 17:16:29)
HTL Salzburg
47
Diplomarbeit
XML und Datenbanken
Steegmans, Bourret, Cline, Guyennet, Kulkarni, Priestley, Sylenko, Wahli
2004: Bart Steegmans, Ronald Bourret, Owen Cline, Olivier Guyennet,
Shrinivas Kulkarni, Stephen Priestley, Valeriy Sylenko, Ueli Wahli, XML
for DB2 Information Integration. Internet: http://www.redbooks.ibm.
com/redbooks/pdfs/sg246994.pdf (05.02.2008 17:38:52)
Bourret 2005: Ronald Bourret, XML and Databases. Internet: http://
www.rpbourret.com/xml/XMLAndDatabases.htm (14.02.2008 19:12:26)
Oracle 2008[1]: Oracle, Introduction to Berkeley DB XML. Internet:
http://www.oracle.com/technology/documentation/berkeley-db/
xml/intro_xml/BerkeleyDBXML-Intro.pdf (07.03.2008 20:47:34)
Oracle 2008[2]: Oracle, Getting Started with Berkeley DB XML for
C++. Internet: http://www.oracle.com/technology/documentation/
berkeley-db/xml/gsg_xml/cxx/BerkeleyDBXML-CXX-GSG.pdf (07.03.2008
21:03:19)
Oracle 2008[3]: Oracle, Berkeley DB XML: C++ API. Internet: http:
//www.oracle.com/technology/documentation/berkeley-db/xml/api_
cxx/frame.html (07.03.2008 21:17:49)
Winkler 2008: Jan Winkler, XPath: Pfade bestimmen. Internet: http:
//www.html-world.de/program/xpath_3.php (21.02.2008 18:43:15)
Refsnes Data 2008: Refsnes Data, XPath Tutorial. Internet: http://
www.w3schools.com/xpath/ (21.02.2008 19:11:59)
Gennick 2003: Jonathan Gennick, SQL in, XML out. Internet: http://
www.oracle.com/technology/oramag/oracle/03-may/o33xml.html (17.03.2008
15:32:19)
Fernández Malhotra, Marsh, Nagy, Walsh 2007: Mary Fernández, Ashok Malhotra, Jonathan Marsh, Marton Nagy, Norman Walsh, XQuery
1.0 and XPath 2.0 Data Model (XDM). Internet: http://www.w3.org/
TR/xpath-datamodel/ (21.02.2008 19:02:19)
HTL Salzburg
48
Diplomarbeit
XML und Datenbanken
2.1
Shredding / Publishing . . . . . . . . . . . . . . . . . . . . . . 25
2.2
Direktes Speichern der XML Dokumente in der Datenbank . . 28
2.3
XSLT Transformation bei Table-Based Mapping . . . . . . . . 31
2.4
Object-Relational Mapping . . . . . . . . . . . . . . . . . . . . 32
2.5
XQuery Abfrage einer relationalen Datenbank . . . . . . . . . 36
HTL Salzburg
49
Diplomarbeit
XML und Datenbanken
Tabellenverzeichnis
2.1
CDs-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2
Lieder-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3
Dokumente-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4
Elemente-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5
Attribute-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6
Text-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7
CDs-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8
Lieder-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.9
CDs-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
HTL Salzburg
50
Diplomarbeit
XML und Datenbanken
Listings
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Ein simples Beispiel-XML . . . . . . . . . . . . . .
Ein öffnendes XML-Tag . . . . . . . . . . . . . . .
Ein schließendes XML-Tag . . . . . . . . . . . . . .
Ein leeres, geschlossenes XML-Element . . . . . . .
Ein XML-Attribut . . . . . . . . . . . . . . . . . .
Eine XML-Deklaration . . . . . . . . . . . . . . . .
Beispiel einer XML-Deklaration . . . . . . . . . . .
Beispiel einer XML-Deklaration . . . . . . . . . . .
Eine XML-Deklaration für XSD . . . . . . . . . . .
Das xs:schema-Element . . . . . . . . . . . . . . . .
XSD - simpleType . . . . . . . . . . . . . . . . . .
XSD - complexType . . . . . . . . . . . . . . . . .
XSD - Einschränkungen des Datentyps . . . . . . .
XSD - Angabe der Häufigkeit . . . . . . . . . . . .
XSD - Referenzen . . . . . . . . . . . . . . . . . . .
Beispiel zur Erklärung von XPath-Achsen . . . . .
XML-Dokument zur Veranschaulichung von XPath
Simpler FLWOR-Ausdruck . . . . . . . . . . . . . .
Komplexer FLWOR-Ausdruck . . . . . . . . . . . .
SQL/XML Beispiel . . . . . . . . . . . . . . . . . .
SQL/XML Beispiel . . . . . . . . . . . . . . . . . .
BDB XML Kommandozeile . . . . . . . . . . . . .
Erzeugen eines neuen Containers . . . . . . . . . .
Erzeugen eines neuen Containers . . . . . . . . . .
Öffnen eines bestehenden Containers . . . . . . . .
Öffnen eines bestehenden Containers - Beispiel . . .
Hinzufügen von Dokumenten - Beispiel . . . . . . .
Abfrage von Daten . . . . . . . . . . . . . . . . . .
HTL Salzburg
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
8
8
8
9
9
10
12
12
12
13
14
15
15
16
20
22
22
25
30
31
35
35
39
39
39
39
39
40
41
51
Diplomarbeit
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
XML und Datenbanken
Abfrage von Daten - Beispiel . . . .
Anzeigen der Ergebnisse . . . . . .
XQuery-Ausdrücke in BDB XML .
Einbinden der Headerdatei . . . . .
Namensraum definieren . . . . . . .
XmlManager erzeugen . . . . . . .
XmlManager erzeugen . . . . . . .
XmlUpdateContext erzeugen . . . .
Einfügen von Daten . . . . . . . . .
XmlQueryContext erzeugen . . . .
Daten abfragen . . . . . . . . . . .
Ergebnisse auslesen und ausgeben .
Abfangen der XmlException . . . .
Komplettes C++ Beispielprogramm
HTL Salzburg
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
44
44
44
44
44
44
45
45
45
45
45
52

XML Editing Tool

Transcrição

Documentos relacionados

XSL, XSLT, FO - Einstieg für XML

java script xsl zaehler

Installation und Testen des JCreator Pro 4.5

Ansuchen um Ratenzahlung

Ein XML-, XPath-, XSLT-Crashkurs

Gay Marketing Seminar in Salzburg

Aktueller Kursflyer - Food

diplomarbeit - Virtual Vehicle

WINTER SOMMER Araber Russen Russen Wok nächtigenk diek

Migration Release 2015.05 nach 2016.06

Fortschrittsbericht 2006