Neu formuliert
HTML-Formulare bestimmen derzeit viele Webpräsenzen, aber was die nächste Generation, die XML-basierten XForms, zu bieten hat, könnte das Herz vieler Webautoren höher schlagen lassen.
- Gerald Richter
Im Oktober 2003 hat die nächste Generation der Webformulare, XForms (siehe Kasten „Online-Ressourcen“), den Status einer W3C-Recommendation erreicht. Ziel dieser neuen Formulare ist es, die traditionellen Webformulare, wie sie in HTML und XHTML definiert sind, abzulösen. Sie sind in zwei Teile aufgeteilt: das Modell und die Benutzerschnittstelle, was die Trennung zwischen Inhalt und Layout, die Wiederbenutzung in verschiedenen Kontexten sowie auf unterschiedlichen Ausgabegeräten erlaubt. Durch die Integration von Events, Eingabevalidierung und einen größeren Funktionsumfang in den Standard kann schon der Client viele Aufgaben erledigen. Das verringert die Zahl der Serverzugriffe und verbessert das Antwortverhalten. Nicht zuletzt sind Formulardaten XML, was eine bessere Strukturierung ermöglicht. XForms stellt kein eigenständiges Dokument dar, sondern Webautoren betten sie in andere Dokumente (XHTML oder SVG) ein.
| Online-Ressourcen | |
| XForms-Homepage beim W3C | www.w3.org/MarkUp/Forms |
| XForms-Spezifikation | www.w3.org/TR/xforms/ |
| Steven Pembertons XForms for HTML Authors | www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html |
| Micah Dubinkos Ten Favorite XForms Engines | www.xml.com/pub/a/2003/09/10/xforms.html |
| DOM2 Events | www.w3.org/TR/DOM-Level-2-Events/) |
| XML Events | www.w3.org/TR/xml-events/ |
| Browser X-Smiles | www.xsmiles.org/ |
Weder der Internet Explorer noch Mozilla/Netscape oder Opera beherrschen bislang XML-Sprachen wie XForms. Allerdings liegen eine Reihe anderer Implementierungen der neuen Formularsprache vor (siehe „Online-Ressourcen“).
Zur Erläuterung der Struktur von XForms soll Listing 1 dienen. Es ermöglicht, Daten zum Versenden einer SMS einzugeben. Als Eingaben verlangt das Formular eine Telefonnummer und Text. Das Eingabefeld für die Telefonnummer akzeptiert nur Zahlen, und die Eingabe ist unbedingt notwendig. Außerdem zeigt das Formular ständig die Anzahl der verbleibenden Zeichen für die Nachricht an. Mit einem Browser wie X-Smiles sieht es wie in Abbildung 1 aus. Füllt man das Formular aus und verschickt es, wird ein XML-Dokument zum Server geschickt, dessen Inhalt in Listing 2 zu sehen ist.
Listing 1: Formular fĂĽr SMS-Eingabe
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<head>
<style type="text/css">
textarea {height: 140pt;width: 240pt;
background-color: rgb(200,200,240);}
input {width: 240pt; background-color:
rgb(200,200,240);}
submit {background-color: rgb(200,200,200);}
trigger {background-color: rgb(200,200,200);}
</style>
<xforms:model id="form1">
<xforms:instance xmlns="" id="instance1">
<sms xmlns:my="http://www.ecos.de/XForms/SMS">
<number>55555</number>
<text/>
<length>
<current>0</current>
<left/>
<maximum>160</maximum>
</length>
</sms>
</xforms:instance>
<xforms:bind nodeset="/sms/number"
required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)"
ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current"
constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" localfile="smsdata.xml"/>
</xforms:model>
</head>
<body>
<p>
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
</p>
<p>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
</p>
<p>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
</p>
<p>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
</p>
<p>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
</p>
</body>
</html>
Listing 2: Ergebnis
<?xml version="1.0" encoding="ISO-8859-1"?>
<sms xmlns:my="http://www.ecos.de/XForms/SMS">
<number>55555</number>
<text>XForms SMS Testformular</text>
<length>
<current>23</current>
<left>137</left>
<maximum>160</maximum>
</length>
</sms>
Modulare Aufteilung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Im Kopf des Dokuments findet sich zunächst das Modell, eingeleitet durch <xforms:model>. Es beschreibt die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings) sowie wohin die Daten gesendet werden sollen (Submission). Weiterhin erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
Eingeleitet durch <xforms:instance> zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Es handelt sich um ein XML-Dokument, das beliebig strukturiert und verschachtelt sein kann. Ebenso kann man hier Initialisierungsdaten angeben, mit denen das Formular zu füllen ist, wie in Listing 1 die Telefonnummer <number>55555</number>. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Es ist durchaus möglich und beabsichtigt, zusätzliche Daten unterzubringen. Dieser Mechanismus löst das von HTML-Formularen bekannte <input type="hidden"> ab und kann dazu dienen, Eingabedaten über mehrere Eingabeformulare hinweg zu transportieren.
Nach den Instanzdaten folgen Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten. Listing 1 legt fest, dass die Telefonnummer eingegeben werden muss und vom Typ Integer ist; dies erledigt <xforms:bind>, und das Attribut nodeset legt durch einen XPath-Ausdruck fest, auf welche Daten bind sich bezieht. required gibt an, dass die Eingabe erforderlich ist und type definiert den Datentyp. Die Datentypen sind XML Schema entnommen und geringfĂĽgig erweitert.
/sms/length/current ist kein Eingabefeld, sondern nimmt die aktuelle Länge des eingebenen Texts auf. Das dritte bind sorgt schließlich für die Berechnung der verbleibende Anzahl an Zeichen (calculate) und definiert eine Randbedingung für dieses Feld (constraint): Die Anzahl verbleibender Zeichen darf nicht < 0 werden. In beiden Fällen gibt das ref-Attribut an, wohin das Ergebnis der Berechnung wandern soll. Als weitere, hier nicht gezeigte Möglichkeit, kann ein relevant-Attribut festlegen, dass der Server die Angaben bei constraint oder calculate nur beachten soll, wenn der in relevant angegebene XPath-Ausdruck wahr ist, etwa der Anwender eine Auswahl innerhalb des Formulars getroffen hat.
Als Drittes kommt im Modell das Ziel der Daten vor - durch das <xforms:submission>-Element, das beliebig oft vorkommen kann. Im Formular lässt sich jedem Element, das das Absenden des Formulars bewirkt, ein Submission-Element zuweisen, was dafür sorgt, ein Formular an unterschiedliche Ziele schicken zu können. Neben dem eigentlichen Ziel, hier eine lokale Datei, angegeben durch das Attribut localfile, bestimmt <xforms:submission> außerdem die Übertragungsmethode (PUT, POST, GET), das Datenformat (XML oder die von aktuellen Browsern benutzten Formate) und das Encoding. Darüber hinaus kann es innerhalb eines Dokuments nicht nur ein Modell, sondern beliebig viele geben.
Eingabelemente beliebig platzieren
Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr in <form>-Tags einschließen wie bei HTML. Eine Liste der in XForms definierten Eingabeelemente findet sich in der Tabelle auf Seite 132. Sie definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>.
| Eingabeelemente | ||
| XForms-Eingabeelement | Ähnlichstes XHTML-Äquivalent | Beschreibung |
| <input> | <input type="text"> | Eingabe kleiner Textmengen |
| <textarea> | <textarea> | Eingabe groĂźer Textmengen |
| <secret> | <input type="password"> | Eingabe sensibler Informationen |
| <output> | - | Anzeigen von Instanzdaten |
| <range> | - | Schieberegler zur Wertauswahl |
| <upload> | <input type="file"> | Upload von Dateien |
| <trigger> | <button> | AnstoĂźen von Ereignissen |
| <submit> | <input type="submit"> | Absenden der Formulardaten |
| <select> | <select multiple="multiple"> oder mehrere <input type="checkbox"> | Auswahl keiner, einer oder mehreren Optionen |
| <select1> | <select> oder mehrere <input type="radio"> | Auswahl genau einer Option |
Außerdem hängt die Darstellung des Eingabeelements vom Datentyp ab. So kann der Browser ein <input>-Element für eine Zeichenkette wie vom HTML-Browser gewohnt darstellen, während er zur Eingabe eines Datums ein Kalender-Control benutzt. CSS und das appearance-Attribute können das Aussehen beeinflussen. Diese Trennung von Semantik der Eingabe und deren exakter Implementierung beziehungsweise Aussehen ermöglicht es, XForms auf unterschiedlichen Ausgabegeräten (XHTML-Browser, WAP-Browser, Voice-Browser et cetera) angemessen darzustellen.
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Kindelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey et cetera. In Listing 1 etwa ist jedem Eingabeelement eine Beschriftung durch <xforms:label> zugewiesen. Die Vorteile gegenüber HTML, wo die Beschriftung lediglich ein Text in der Nähe des Eingabeelements ist, liegt bei der Interpretation durch einen Voice-Browser auf der Hand. Das ref-Attribut bestimmt für jedes Eingabeelement, welche der Instanzdaten mit ihm verknüpft sind. Die Angabe des zusätzlichen model-Attributs erlaubt es, eins von mehreren Modellen auszuwählen.
Nicht Notwendiges ausblenden
Nicht immer sind alle Eingabeelementes eines Formulars relevant. Es kann beispielsweise die Übersicht erhöhen, wenn nicht benötigte Eingabefelder ausgeblendet sind, oder nur Teile eines Formulars zur Anzeige kommen sollen, wie in Dialogen mit Karteikartenreitern. Bei heutigen Browsern kann man dies nur durch eine meist browserspezifische Kombination aus CSS und Javascript erreichen. XForms hingegen integriert diese Funktion. Sie lässt sich mit <xforms:switch> realisieren.
Listing 3 zeigt zwei durch <xforms:case> .. </xforms:case> eingegrenzte Bereiche. Im ersten kann der Benutzer seinen Namen eingeben, in zweiten wird der angezeigt und der Anwender kann ihn abschicken oder noch mal editieren. Das <xforms:toggle>-Element sorgt in diesem Zusammenhang für das Auslösen des Ereignisses. Insgesamt sind in XForms eine ganze Reihe von Ereignissen definiert, auf die man mit unterschiedlichen Aktionen reagieren kann, um Eingaben zu validieren, Meldungen auszugeben oder das Aussehen des Formulars zu verändern. XForms nutzt dazu ein Ereignissystem, wie es in DOM2 und XML Events (siehe „Online-Ressourcen“) definiert ist.
Listing 3: Auswahl
<xforms:switch>
<xforms:case id="in" selected="true">
<xforms:input ref="yourname" >
<xforms:label>Bitte geben Sie Ihren Namen ein</xforms:label>
<xforms:toggle ev:event="DOMActivate" case="out"/>
</xforms:input>
</xforms:case>
<xforms:case id="out" selected="false">
<p>Hallo <xforms:output ref="yourname" /></p>
<p>
<xforms:trigger id="editButton">
<xforms:label>Bearbeiten</xforms:label>
<xforms:toggle ev:event="DOMActivate" case="in"/>
</xforms:trigger>
<xforms:submit submission="submitswitch">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
</p>
</xforms:case>
</xforms:switch>
Wiederholende Strukturen zu definieren und diese dynamisch zu verändern, erlaubt XForms ebenfalls. Man kann so etwa eine Tabelle anzeigen, in die der Benutzer Daten eingeben, Tabellenzeilen hinzufügen oder entfernen kann.
Wer des öfteren komplexe Formulare fürs WWW zu erstellen hat, dürfte die Eigenschaften von XForms schnell zu schätzen lernen. Webformulare kommen damit einem nativen Client von seiner Leistungsfähigkeit und Performance recht nahe. Vorbei die Zeit, in der man sich die Unabhängigkeit vom Betriebssystem und Hardware durch Implementierung als Webapplikation mit teilweise umständlicher und langsamer Bedienbarkeit erkauft hat. Nun kann man sich Formulare sogar am Telefon vorlesen lassen oder Sehbehinderten zugänglich machen. Zudem ist die Verwendung derselben Formulare auf PC, PDA und Handy möglich (auf weniger leistungsfähigen Geräten unter Umständen mit eingeschränkten Funktionsumfang).
Alles bestens? Leider nein. Erst wenn die Mainstream-Webbrowser mit den neuen Formularen - etwa als Modul in XHTML - zurechtkommen, werden die sich weltweit durchsetzen. Da die Spezifikation recht umfangreich ist, dürfte es allerdings noch einige Zeit dauern, bis XForms genügend Verbreitung gefunden haben, um tatsächlich zum Einsatz zu kommen. Bis dahin bleibt der Ärger mit HTML-Spaghetti-Code-Formularen. Wer einen Blick in die Zukunft werfen möchte, findet bei XML.com eine Auswahl von Werkzeugen, die schon heute XForms verarbeiteten.
Gerald Richter
ist Geschäftsführer für den Bereich Technik der Firma Ecos Eletronic Communication Services GmbH. Sein Schwerpunkt liegt auf der Entwicklung von Intra- und Internetapplikationen.
iX-TRACT
- XForms, die XML-basierten Formulare, sollen die aus HTML bekannten <form>-Elemente ersetzen und Entwicklern wesentlich mehr Möglichkeiten bieten.
- Die Trennung zwischen Inhalt und Layout, die Wiederbenutzung von Teilen in unterschiedlichen Zusammenhängen sowie die Ausgabe auf unterschiedlichen Geräten sprechen für die neuen Formulare.
- Zwar existiert schon eine Reihe von Implementierungen, aber der Durchbruch dürfte erst dann kommen, wenn die Mainstream-Browser XML-Sprachen wie XForms verarbeiten können.