Formulare sehen auf den ersten Blick eigentlich einfach aus.
Doch auf den zweiten Blick stellen sich einige Probleme heraus, die man nicht so einfach lösen kann ohne das man nicht vorher einige Überlegungen investiert.
Besonderes interessant wird die Frage, wie man Formulare so gestaltet, daß man diese leicht auf andere Websites übertragen kann und wie man auch die Erstellung so standardisiert, daß gleichzeitig zur Übertragbarkeit auch technisch unerfahrene Personen komplexe Formulare erstellen können.
Ein komplexes Formular wiederum ist nicht nur deswegen komplex, weil es mehr als 2 Formularelemente enthält oder komische Verknüpfungen aus Fieldsets innerhalb Checkboxes, sondern auch durch bedingte Eingabefelder.
Zum Beispiel, daß eine Auswahlliste für Schuhgrößen abhängig davon ist, ob man bei vorherigen Fragen angegeben hat, ob man eine Frau oder ein Mann ist.
Die obere Grafik versucht, die Problemkreise einzuteilen in verschiedene von einander abhängige Prozesse, wie man es im Idealfall aufbauen könnte.
Die Fragen sind: Wie könnten die einzelnen Prozesse aussehen und wie müsste man die jeweiligen Ergebnisse und Schnittstellen definieren?
Sollte nicht genau diese Problematik mit XForms angegangen werden?
Also mir gefällt der Model-View-Control-Ansatz sehr gut:
In einer Daten-Klasse modeliert man die Eigenschaften und Abhängigkeiten, sowie die Zugriffs- und Speichermethoden.
Als Views dienen Formulare und Templats.
Ein Show-, ein List- und ein Edit-Control beinhalten jeweils die logischen Abläufe und verbinden Model und View.
Nur teilweise.
XFroms bestimmt zwar welche Elemente in ein HTML-Dokument existieren und wie drauf reagiert wird, allerdings behandelt es nicht, wie diese Formulare überhaupt erstellt werden.
Zudem behandelt es nicht die Reihenfolge in der Semantik der möglichen Elemente.
Ein anderer Punkt ist aber auch, daß XForms inzwischen ein Wackelkandidat ist – es gibt konkrete Hinweise, daß Webforms sich eher durchsetzen wird als Standard.
Aber auch Webforms beschreiben nicht alles.