language-icon Old Web
English
Sign In

XForms

XForms is an XML format used for collecting inputs from web forms. XForms was designed to be the next generation of HTML / XHTML forms, but is generic enough that it can also be used in a standalone manner or with presentation languages other than XHTML to describe a user interface and a set of common data manipulation tasks. XForms is an XML format used for collecting inputs from web forms. XForms was designed to be the next generation of HTML / XHTML forms, but is generic enough that it can also be used in a standalone manner or with presentation languages other than XHTML to describe a user interface and a set of common data manipulation tasks. XForms 1.0 (Third Edition) was published on 29 October 2007. The original XForms specification became an official W3C Recommendation on 14 October 2003, while XForms 1.1, which introduced a number of improvements, reached the same status on 20 October 2009. In contrast to the original web forms (originally defined in HTML), the creators of XForms have used a model–view–controller (MVC) approach. The model consists of one or more XForms models describing form data, constraints upon that data, and submissions. The view describes what controls appear in the form, how they are grouped together, and what data they are bound to. CSS can be used to describe a form's appearance. An XForms document can be as simple as a web form (by only specifying the submission element in the model section, and placing the controls in the body), but XForms includes many advanced features. For example, new data can be requested and used to update the form while it is running, much like using XMLHttpRequest/AJAX except without scripting. The form author can validate user data against XML Schema data types, require certain data, disable input controls or change sections of the form depending on circumstances, enforce particular relationships between data, input variable length arrays of data, output calculated values derived from form data, prefill entries using an XML document, respond to actions in real time (versus at submission time), and modify the style of each control depending on the device they are displayed on (desktop browser versus mobile versus text only, etc.). There is often no need for any scripting with languages such as JavaScript. However, XForms does include an event model and actions for implementing more complex form behaviors. Actions and event handling are specified using the XForms XML dialect rather than more common scripting languages like JavaScript. Like web forms, XForms can use various non-XML submission protocols (multipart/form-data, application/x-www-form-urlencoded), but a new feature is that XForms can send data to a server in XML format. XML documents can also be used to prefill data in the form. Because XML is a standard, many tools exist that can parse and modify data upon submission. Similar tools for legacy forms also exist. XForms is itself an XML dialect, and therefore can create and be created from other XML documents using XSLT. Using transformations, XForms can be automatically created from XML schemas, and XForms can be converted to XHTML forms. At the time of this writing, no widely used web browser supports XForms natively. However, various browser plugins, client-side extensions and server/client solutions exist. The following lists some implementations: FormFaces, AJAXForms, XSLTForms, betterFORM, Chiba, Orbeon and Smartsite Forms are based on Ajax technology. The amount of server-side and client-side processing varies between these implementations. For example, Ubiquity XForms, FormFaces and XSLTForms provide 100% XForms client-side processing and data model updates via pure Ajax processing on the XForms standard. The others use server-side Java/.NET XForms processing transcoding to Ajax markup prior to delivering the content to the browser. Both techniques can work across browsers. Each implementation is significantly different with respect to dependencies, scalability, performance, licensing, maturity, network traffic, offline capability, and cross browser compatibility. System architects should evaluate these constraints against their needs to determine potential risks and objectives.

[ "Performance report", "Plan (drawing)", "XML Events" ]
Parent Topic
Child Topic
    No Parent Topic