xForms
xForms
xForms
xForms
xForms
xForms
xForms
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.
Bisher werden Eingabedaten von Webseiten über den <form>-Tag (form = Formular) definiert und per Mail an betreffende Empfänger versendet, oder aber durch den Aufruf eines Programms auf dem Server-Rechner übertragen und dort durch dieses weiterverarbeitet. Man kann bei dem betreffenden action-Attribut allerdings auch eine HTML-Datei angeben, welche bei Absenden des Formulars aufgerufen wird und dann die Formulardaten z.B. mit JavaScript weiterverarbeitet. Das ist beispielsweise für mehrseitige Formulare interessant. Diese Daten, es können Eingabefelder, Auswahllisten oder Buttons sein, werden bisher durch HTML − Elemente formatiert, wie Blindtabellen, verschiedene Beschreibungstexte mit wiederum eigenen < code >-Tags, > div <-Elementen usw. Man hat also innerhalb des Form-Containers alle Freiheiten. Leider würden die meisten neueren Endgeräte mit dieser Komplexität nur sehr schwierig bzw. überhaupt nicht arbeiten können. Ebenso fehlt die Möglichkeit der clientseitigen Validierung, welche maximal durch JavaScript gelöst werden kann.
An dieser Stelle greift die Neuentwicklung “XForms” des W3C. XForms ist nicht rückwärtskompatibel zu früheren HTML, dafür allerdings geräteunabhängig, so dass es egal ist, ob Maus oder Tastatur die Befehle übergibt. Weiterhin werden Inhalt und Form streng voneinander getrennt, und so verschiedene Ansichten auf ein Formular ermöglicht. Man kann universell auf XForms-Formulare zugreifen und standardisierte Mechanismen für einen bidirektionalen Datenaustausch sowie die Unterstützung von verschiedenartigen Datenaustauschen nutzen. Ebenfalls sollen Eingabefehler ohne Serveranfragen früh erkannt werden, und dies ohne schwierig zu interpretierenden JavaScript-Quellcode.
Dennoch werden mit wenig Aufwand Formulare erschaffen, z.B.: mit einem einfachen Text Editor, einfacher Syntax, und einem besseren Umgang mit non-western Zeichencodes und unicode. Einfache Berechnungen sowie Ausdrücke basieren auf den Formulardaten und Abhängigkeiten zwischen Datenwerten sind ausdrückbar. Man stelle sich ein Datenfeld vor, welches nur aktiviert wird, wenn ein anderes ausgefüllt wurde. Letztendlich können Formulare an mehrere Benutzer und Ziele gleichzeitig gesendet werden. Zur Erklärung dieser Techniken dient das folgende Beispiel:
Head-Teil
<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" <br /> required="true()"
type="xsd:integer"/>
<xforms:bind calculate="string-length(/sms/text)" <br /> ref="/sms/length/current"/>
<xforms:bind calculate="../maximum - ../current" <br /> constraint="/sms/length/left > -1"
ref="/sms/length/left"/>
<xforms:submission id="submitsms" <br /> localfile="smsdata.xml"/>
</xforms:model>
Body-Teil
<xforms:input ref="/sms/number">
<xforms:label>Telefonnummer</xforms:label>
</xforms:input>
<xforms:output ref="/sms/length/left">
<xforms:label>Verbleibende Zeichen</xforms:label>
</xforms:output>
<xforms:textarea incremental="true" ref="/sms/text">
<xforms:label>Nachricht</xforms:label>
</xforms:textarea>
<xforms:trigger>
<xforms:label>Duplizieren</xforms:label>
<xforms:setvalue ev:event="DOMActivate" ref="/sms/text" value="concat(.,.)"/>
</xforms:trigger>
<xforms:submit submission="submitsms">
<xforms:label>Absenden</xforms:label>
</xforms:submit>
clientseitige Formularvalidierung
Im Gegensatz zu HTML-Formularen sind die Angaben zum XML-basierten Formular zweigeteilt. Innerhalb des Dokumentenrumpfes können Webautoren die eigentlichen Eingabeelemente an beliebiger Stelle platzieren und müssen sie nicht mehr, wie bei HTML üblich, in <form>-Tags einschließen. Im Kopf des Dokuments findet sich das Modell des Eingabeformulars, eingeleitet durch <xforms:model>. Es beschreibt u.a. die Struktur der Daten (Instance Data), zusätzliche Informationen zu ihnen wie Typ und Abhängigkeiten (Bindings). Dabei erlaubt das schema-Attribut des model-Start-Tags die Angabe eines XML-Schema-Dokuments, gegen das der XForms-Prozessor die Daten prüfen soll.
SMS Message
Eingeleitet durch < xforms:instance > zeigen die Instanzdaten, wie die durch das Formular zu erfassenden Daten auszusehen haben. Außerdem müssen nicht alle hier definierten Datenelemente tatsächlich im Formular vorkommen. Informationen zu Datentypen, Validierungsregeln, Berechnungen und Events zu den Daten /sms/length/current ist beispielsweise kein Eingabefeld, sondern nimmt die aktuelle Länge des eingegebenen 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
strenge Trennung Inhalt/Layout
Die in XForms definierten Eingabeelemente definieren nur die Art der Eingabe, nicht aber ihr Aussehen und die genaue Implementierung. Es gibt somit kein eigenes Element für Select-Boxen und Radiobuttons wie in HTML, sondern nur ein <select>. 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 „Calendar-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 etc.) angemessen darzustellen.
Geräteunabhängigkeit
Um die Ausgabe auf unterschiedlichen Medien noch mehr zu erleichtern, können Informationen, die in Beziehung zum Eingabeelement stehen, als Unterelement in das Eingabeelement integriert sein. Vorgesehen sind hier Label, Hinweistext, Accesskey usw. Im obigen Beispiel 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 Maschine und Browser, einem Voice-Browser beispielsweise, 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.
Bidirektionaler Datenaustausch
Standardisierte Mechanismen für einen bidirektionalen Datenaustausch und die Unterstützung von verschiedenartigen Datenaustauschen sind in XForms implementiert. So können nach jedem Halt Daten beispielsweise aus einer externen xml-Datei in das Formular nachgeladen werden. Dies eröffnet die Möglichkeit, Formulare weiter auszufüllen, was beliebig oft wiederholbar ist.
Multitasking
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.