Am 14.10.2003 wurde XForms 1.0 in den Stand einer W3C Recommendation erhoben und hat auch schon einen Rekord zu verbuchen: Noch nie zuvor standen bei Verabschiedung eines W3C-Standards so viele Implementierungen zur Verfügung. Das in diesem Artikel vorgestellte EU-Projekt Consensus verwendet serverseitiges XForms-Processing neben weiteren W3C-Standards, um geräteunabhängige Webanwendungen zu ermöglichen und liefert damit auch einen beeindruckenden Beweis für die Einsatzfähigkeit von XForms.
Das Consensus-Projekt [1] hat den Anspruch, das geräteunabhängige Erstellen von Inhalten mit den neuesten W3C-Standards bzw. Erweiterungen dieser Standards zu ermöglichen. Da das Projekt vornehmlich die Unterstützung von Geschäftsanwendungen zum Ziel hat, kommt der Unterstützung von interaktiven Webanwendungen, d.h. der Formularverarbeitung, besondere Bedeutung zu. In diesem Zusammenhang erwies sich XForms als zukünftiger Standard für die geräteunabhängige Definition von Webformularen als sehr hilfreich. Da bisher nur wenige Browser XForms unterstützen, konvertiert der Consensus-Prototyp die vom Autor erstellten Formulare so, dass gängige Browser (HTML, WML, XHTML MP, VoiceXML) die Formulare dem Benutzer präsentieren können. Wir nennen das server-side XForms processing, also serverseitige XForms-Verarbeitung. Ein XForms-Prozessor ist von nicht-trivialer Komplexität. Glücklicherweise gibt es schon einige Open Source-Komponenten [2, 3], die die serverseitige Verarbeitung von XForms implementieren. Im Consensus-Projekt kam der in der letzten Ausgabe dieses Magazins [4] vorgestellte XForms-Prozessor Chiba zum Einsatz. Da der Consensus-Prototyp der Öffentlichkeit unter einer Open Source-Lizenz zur Verfügung gestellt werden soll (Projektziel), war ein serverseitiger XForms-Prozessor notwendig, der ebenfalls unter einer Open Source-Lizenz steht. Chiba war der einzige weitgehend Standard-kompatible XForms-Prozessor, der unter einer entsprechenden Lizenz zur Verfügung stand.
Die serverseitige Verarbeitung von XForms-Dokumenten kann immer nur einen Teil des Standards umsetzen, weil die eng damit verbundene Verarbeitung von XML-Events über die HTTP-Verbindung nur eingeschränkt möglich ist. Wie der Prototyp beweist, kann trotz dieser Einschränkungen eine beeindruckende Vielfalt von Browsern bedient werden.
In der aktuellen Chiba-Version, die Consensus noch nicht zur Verfügung stand, simuliert ein Adapter die Benutzeraktionen und kann so nahezu alle DOM-Events und -Actions auch serverseitig ausführen. Die verbleibenden Lücken können durch das Einfügen entsprechender Skriptanteile in das Zieldokument geschlossen werden. Gegenwärtig sind die Grenzen des serverzentrierten Ansatzes sicher noch nicht erreicht.
Das Consensus Projekt
CONSENSUS (
Context
Sensitive Adaptability -
User Friendly Mobile Work Place for
Seamless Enterprise Applications) ist ein von der Europäischen Union gefördertes Projekt, das im April 2002 begann. Ziel ist die Erforschung von Mechanismen und Methoden zur Erstellung und Verarbeitung von Internetinhalten für mobile Geräte, ohne dass diese Inhalte
n-Mal (einmal pro Gerätetyp) vorgehalten werden müssen. Die Ermöglichung des so genannten Single-Source Authoring, d.h. die Erstellung einer Webanwendung in einer geräteunabhängigen Markup-Sprache, ist dazu ebenso notwendig wie die Schaffung einer serverseitigen Komponente, die die geräteunabhängige Sprache in eine vom jeweiligen Endgerät unterstützte umsetzt. Durch Single-Source Authoring sollen eine Reduzierung der Kosten zur Entwicklung und Wartung von Anwendungen für mobile Endgeräte und damit eine schnellere Verbreitung von Internet-Anwendungen auf mobilen Geräten ermöglicht werden.
Bisherige Ergebnisse sind:
a) ein detailliertes Pflichtenheft für die Darstellung von Internetinhalten auf mobilen Geräten,
b) ein Sprachenprofil mit dem Namen RIML (Renderer-Independent Markup Language), bestehend aus XHTML 2.0 + XForms 1.0 + Ergänzungen,
c) die Architektur und Implementierung einer so genannten Adaptation Engine, die die notwendigen Transformationen zur Laufzeit vornimmt.
d) eine Reihe von Tools zur Vereinfachung der Anwendungsentwicklung, die als Plug-ins für das Eclipse-Framework realisiert wurden.
Die Ergebnisse des Projekts befinden sich zurzeit im Feldversuch. Durchgeführt wird das Projekt von einem Konsortium europäischer Firmen. Mehr Information ist erhältlich über die Web-Seite des Projekts: www.consensus-online.org/.
Paginierungsprobleme
Der Schwerpunkt des Consensus-Projekts ist allerdings nicht die Formularverarbeitung an sich, sondern die ganzheitliche Unterstützung von Entwicklern bei der Erstellung geräteunabhängiger Webinhalte. Dazu wurden zum einen eine eigene Markup-Sprache, die so genannte Renderer Independent Markup Language (RIML), entwickelt und zum anderen eine entsprechende Implementierung einer serverseitigen Adaptionskomponente geschaffen, die RIML in gerätespezifische Formate wie WML, XHTML MP u.a. umwandelt. RIML vereint die vielversprechendsten Konzepte vorhandener und zukünftiger Webstandards wie XHTML 2.0, XForms und SMIL in einem so genannten XHTML Language-Profil. Bisher fehlende Konzepte für die Unterstützung des geräteunabhängigen Erstellens von Webinhalten wurden im Rahmen des Consensus-Projekts entwickelt und ebenfalls mit in das RIML Language Profile übernommen. Weiterhin wurde eine Softwarekomponente, die so genannte Adaptation Engine, geschaffen, die die Umwandlung der RIML in eine gerätespezifische Markup-Sprache zur Laufzeit erlaubt.
Eines der Probleme, das insbesondere bei mobilen Geräten mit relativ kleinen Bildschirmen auftaucht, ist die aus Benutzersicht optimale Aufteilung von Inhalten. Dies ist immer dann notwendig, wenn der vom Autor erstellte Inhalt nicht auf den Bildschirm des Gerätes passt, was z.B. bei Mobiltelefonen häufig der Fall ist. Natürlich könnte der Autor seine Inhalte von vornherein so erstellen, dass sie auf dem kleinsten zu unterstützenden Bildschirm darstellbar sind. Um nun auch die größeren Bildschirme ausnutzen zu können, ist ein Aggregationsmechanismus notwendig. Diesen Ansatz verfolgen jedoch nur wenige Projekte. Die meisten Projekte/Produkte implementieren mehr oder weniger elegante Paginier-Algorithmen [5]. Die dabei zu lösende Aufgabenstellung ist ähnlich der eines Druckertreibers, der berechnen muss, wie viel Inhalt auf eine Seite passt. Nur dass dies bei geräteunabhängiger Erstellung von Inhalten ungleich schwieriger ist. Außerdem müssen auf jeder Seite bzw. jedem Bildschirm noch Navigationselemente hinzugefügt werden, die, ähnlich einer Druckvorschau, das Vor- und Zurückblättern ermöglichen. Dies verdeutlicht Abbildung 1: Ein Formular kann auf einem PC-Bildschirm vollständig dargestellt werden (links), muss jedoch für die Darstellung auf einem Smartphone in drei Seiten aufgeteilt werden (rechts).
Abb.1: Paginierung von Formularen
XForms und Paginierung
Was hat dies nun mit XForms zu tun? Auch Formulare können zu groß werden für kleine Bildschirme, z.B. wenn die Anzahl der Eingabefelder sich aus einer Datenbankabfrage ergibt und damit stark variiert. Dann müssen die Eingabefelder auf verschiedene Bildschirmseiten verteilt werden. Wobei XForms nicht nur auf Eingabefelder beschränkt ist, sondern auch Selektionslisten erzeugen kann. Für solche Listen, aus denen der Benutzer einen oder mehrere Einträge auswählt, gibt es für verschiedene Geräte unterschiedlich optimale Darstellungsmöglichkeiten, z.B. Listbox, Combobox bzw. Radio Buttons, wenn die Anzahl des Listenelemente gering ist. Der Consensus-Prototyp wählt die jeweils passendste Darstellung aus auf Basis der aktuellen Geräteeigenschaften.
Seitenumbruch und Validierung
Eine vom verwendeten Browser abhängige Größenabschätzung des Formulars ist hier notwendig. Zusätzlich kann der Autor noch Direktiven geben, z.B. durch Verwendung von Elementen wie z. B.
xforms:group oder
xhtml:tbody andeuten, dass innerhalb einer Gruppe nicht gesplittet werden sollte.
Schwierig ist hier nicht nur die Abwägung, in welchem Maße der Seitenumbruch des Inhalts vom Autor bestimmt werden sollte im Vergleich zur automatischen Aufteilung mittels Heuristiken; auch das Layout einer Webseite muss für verschiedene Geräte neu komponiert werden. Zu diesem Zwecke definiert der Autor Tabellen-ähnliche Container, denen zur Laufzeit Inhalt zugewiesen wird. Attribute, die diesen Containern beigefügt werden können, steuern die Platzierung derselben: z.B. soll der Header und Footer einer Seite wiederholt und nicht umgebrochen werden, im Gegensatz zum Mittelteil. Ein häufig vorgenommener Kompromiss ist die Definition mehrerer alternativer Layouts für verschiedene Geräteklassen, aus denen das Adaptionssystem dann zur Laufzeit auswählt.
Eine spezielle Problematik ergibt sich bei der Verarbeitung der Eingabewerte durch den XForms-Prozessor. Im Normalfall enthält ein Prozessor eine Validierungskomponente, die die Vollständigkeit und Gültigkeit der vom Benutzer eingegebenen Daten bzw. Selektionen prüft und nur im positiven Fall die Eingabedaten an die Anwendung weiterleitet. Wird dem Benutzer nun aber das Formular auf mehreren aufeinander folgenden Seiten präsentiert, kann die Validierung erst erfolgen, wenn alle Seiten ausgefüllt sind, da ja sonst noch Eingaben fehlen. Eine schlichte Implementierung kann dann dazu führen, dass der Benutzer nach Ausfüllen der sechsten und letzten Seite erfährt, dass auf der ersten Seite ein Fehler ist. Man kennt dies aus schlecht programmierten Webapplikationen.
Zur Vermeidung dieses Verhaltens ist eine Teilvalidierung jeder Seite wünschenswert. Diese kann allerdings nur unvollständig sein, weil es unter Umständen wechselseitige Abhängigkeiten von Daten gibt, die auf verschiedenen Seiten einzugeben sind. Damit könnte man noch leben. Problematischer ist die dazu notwendige Fragmentierung des Datenmodells, das dem Formular zugrunde liegt. XForms kann nur das vollständige Model validieren. Jede Seite müsste daher genau auf ein Model abgebildet werden. Alternativ kann man die Validierung für bestimmte Teile des Datenmodells temporär ausschalten oder zwei XForms-Prozessoren hintereinander schalten. Einer wäre für Teilformulare zuständig, der zweite für das Gesamtformular. Diese Probleme werden die XForms Working Group sicher noch während der Entwicklung der Version 1.1 beschäftigen.
Navigation
Nachdem dieses Problemfeld gelöst ist, ist noch einiges bei der Navigation zu beachten. Bei Seiten, die keine Eingaben erwarten, wird die vom System erzeugte Navigation zwischen Teilseiten üblicherweise durch Hyperlinks dargestellt. Dies ist bei Formularen jedoch unzureichend, weil die Eingabedaten ja zum XForms-Prozessor übermittelt werden müssen, was mit einem einfachen Hyperlink nicht möglich ist. Also muss ein als Link getarnter Submit-Button her, der zur nächsten Seite führt, aber nicht den XForms-Prozessor veranlasst, Daten an die Applikation zu schicken - außer wenn der Benutzer sich auf der letzten Seite befindet.
Abgesehen von diesen nur angerissenen Problemen gibt es dann noch die Behandlung von unrichtigen Eingaben des Benutzers. Das entsprechende Teilformular muss hier erneut präsentiert werden, angereichert um eine aussagekräftige Fehlermeldung.
XForms bietet zwar die geräteunabhängige Verarbeitung von Formularen, lässt aber die Probleme der Paginierung der Inhalte bewusst außen vor. Für eine praxisgerechte Umsetzung sind diese Probleme zusätzlich zu lösen. Der Consensus-Prototyp ist eine der wenigen Implementierungen, die sich dieser Herausforderungen annehmen.
Grenzen von XForms und Spracherweiterungen
XForms stellt einen großen Schritt in Richtung geräteunabhängigen Markups - und damit die ideale Ergänzung von XHTML 2.0 - dar. Letztendlich müssen die Inhalte dem Benutzer jedoch ansprechend präsentiert werden. Mit XForms verlagert der Autor die detaillierte Kontrolle über das Aussehen eines Formulars auf den XForms-Prozessor, unabhängig davon, ob der Prozessor auf Server- oder Clientseite sitzt. Natürlich kann man als Autor mit Mitteln wie CSS das Look & Feel beeinflussen. Viele Browser der heutigen mobilen Gerätegeneration unterstützen jedoch gar kein CSS. Das bedeutet, dass der Autor eines XForms-Formulars nur eine vage Vorstellung davon hat, wie die Interaktion mit dem Benutzer letztendlich aussehen wird, und sich von der bisherigen Arbeitsweise (hier eine Combobox, hier eine Listbox, hier ein Eingabefeld) verabschieden muss.
Die Migration in Richtung geräteunabhängiger Webcontent-Erstellung wird erleichtert durch entsprechende Autorenwerkzeuge. Solche Werkzeuge bieten Vorschau-Funktionalität für verschiedene Geräteklassen, sodass der Autor sich ein Bild davon machen kann, was mit seinem Formular auf verschiedenen Geräten passiert. Nur gibt die Vorschau lediglich eine Annäherung an, keine Garantie, wie der Inhalt tatsächlich präsentiert wird.
Layout in RIML
Um dem Autor zu ermöglichen, für verschiedene Klassen von Geräten das Layout unterschiedlich zu gestalten, hat das Consensus-Projekt ein Layout-Modul innerhalb der RIML definiert, das an XFrames [6] angelehnt ist, jedoch einige neue Konzepte enthält (z. B. Behandlung von Abhängigkeiten zwischen Layout und Fragmentierung). Damit definiert der Autor das Layout (gegebenenfalls für verschiedene Geräte unterschiedlich) in Form von geschachtelten Containern. Jeder Container wird dann zur Laufzeit dynamisch mit Inhalten gefüllt. Welche Inhalte in welche Container gefüllt werden, gibt der Autor durch Referenzen an. Vorteil dieses Ansatzes ist, dass bei einer Änderung des Layouts die Inhalte nicht verändert werden müssen. SMIL [7] verfolgt einen ähnlichen Ansatz für die Darstellung von Medien.
Um für verschiedene Geräteklassen verschiedene Layouts definieren zu können, führt das Consensus-Projekt eine an SMIL angelehnte Content Selection Language ein, mit der der Autor Bedingungen angeben kann, die erfüllt sein müssen, damit ein bestimmter Markup ausgewählt wird - ähnlich wie
<xsl:if> oder
<xsl:choice>. Beide Spracherweiterungen hat das Projekt der W3C Device Independence Group [8] vorgeschlagen, um die Geräteunabhängigkeit von XHTML und XForms weiterzuentwickeln.
Listing 1 <html>
<head>
<riml:layout>
<riml:column>
<riml:frame frameId="Logo">
<include-section section-id="s1"/>
</frame>
<riml:row>
<riml:frame frameId=" FrameA">
<include-section keywords="frameA"/>
</frame>
<riml:frame frameId=" FrameB">
<include-section section-id="s4"/>
</frame>
</riml:row>
</riml:column>
<riml:layout>
</head>
<body>
<section id="s1">
<!-- section content -->
</section>
<section id="s2" keywords="frameA">
<!-- section content -->
</section>
<section id="s3" keywords="frameA">
<!-- section content -->
</section>
<section id="s4">
<!-- section content -->
</section>
</body>
</html>
Abb.2: Layout in der RIML
Listing 1 zeigt ein Beispiel für die Definition eines bestimmten Layouts in RIML. Das Beispiel definiert drei Bereiche für die Platzierung des Inhalts (Frames). Die Referenz zwischen diesen Bereichen und dem eigentlichen Inhalt wird über das Element include-section hergestellt. Frames können dann in so genannten Layout-Containern angeordnet werden, die deren Anordnung auf dem Bildschirm bestimmen. Im Beispiel soll das Logo über den Frames
A und
B angeordnet werden, wozu eine Spalte (
column) definiert wird. Da die beiden Frames
A und
B nebeneinander dargestellt werden sollen, umschließt sie ein
row-Container. Die RIML definiert weitere Arten von Containern sowie das Verhalten dieser Container im Falle der Paginierung.
Fazit
Der XForms-Standard offeriert bereits eine Reihe geeigneter Konzepte, die die Erstellung geräteunabhängiger Webanwendungen unterstützen, zum Beispiel die Darstellung endgeräteunabhängiger Eingabeelemente oder die strikte Trennung von Formulardaten und ihrer Präsentation im User Interface. XHTML 2.0 besitzt ebenfalls einige solche Konzepte. Im Rahmen der Arbeiten zum Consensus-Projekt hat sich jedoch gezeigt, dass diese in ihrer Summe noch unzureichend für eine ganzheitliche Unterstützung der Erstellung geräteunabhängiger Webanwendungen sind. Dementsprechend wurden die in diesem Artikel vorgestellten Konzepte entwickelt und in der vom Consensus-Projekt definierten Sprache RIML zusammengefasst. Die RIML bildet dabei ein so genanntes Profil bestehend aus XForms 1.0, XHTML 2.0 und Erweiterungen. In welcher Form diese Erweiterungen in die W3C-Standards übernommen werden, bleibt abzuwarten. Aber es kann kein Zweifel daran bestehen, dass XForms trotz erheblicher Komplexität nicht nur clientseitig implementierbar ist, sondern auch in anspruchsvolleren Umgebungen, die Paginierung erfordern, auf seinen Einsatz wartet.
Jörn Turner ist Gründer des Projekts Chiba und Geschäftsführer von Chibacon. Schwerpunkt seiner Arbeit sind XForms, XML- und Java Enterprise-Applikationen. Michael Wasmund, Projektleiter bei der IBM Deutschland Entwicklung GmbH, beschäftigt sich seit Jahren mit XML-Technologien, insbesondere im Zusammenhang mit Portalen. Thomas Ziegert ist Senior Researcher bei der SAP AG, Corporate Research und arbeitet im Bereich Device Independent Application Engineering. Er ist Projektleiter des Consensus-Projekts.Links und Literatur
Hat Ihnen dieser Artikel gefallen? Dann abonnieren Sie das Entwickler Magazin direkt über unser
