What Are X-Forms and Why Should I Use them?
In a typical HTML form, what data the form produces is generally determined by how the form itself is designed. That is, the presentation of the form is tied to the data being produced by it. In the following example we have a simple xhtml form that submits a data payload.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> <title>Software Projects - Home</title> </head> <body> <form action="process_results.cgi" method="post"> <table> <tr> <td>First Name</td> <td> <input name="firstName" id="firstName" maxlength="20" value="Anthony"/> </td> </tr> <tr> <td>Surname</td> <td> <input name="surname" id="surname" maxlength="20" value="Marendy"/> </td> </tr> <tr> <td>Company</td> <td> <input name="company" id="company" maxlength="20" value="Software Projects"/> </td> </tr> <tr> <td/> <td> <input name="commit" type="submit" value="Save" /> </td> </tr> </table> </form> </body> </html>There are a few things to note here.
- The data produced by the form is tied very tightly to the way that the form definition is structured. In the example above, the first name is pre-populated with the text ‘Anthony’. If you wanted to pre-populate it with the text ‘Stephen’, then you would need to generate the form with this data value instead.
- There is typically, little or no structure to the data that is produced by the form.
- Validation of the form is done on the server and always requires a round trip.
- The underlying object that you are trying to maintain has no concrete representation until it’s actually written to the database. For example if you are using a wizard style interface to maintain data across a number of forms, then data needs to be persisted somehow in the meantime. This is typically done through cookie data, session information or hidden variables on the client side. All of these approaches have their inherent risks.
- The presentation of the form is quite tightly coupled to the application which consumes the data payload. Take the case where you are maintaining user details in a multi-page wizard. Changing the way the way in which the data is captured (e.g. or the number of pages in the wizard) requires a server side change even though the actual data that is being captured has not changd.
XForms is the internet community’s attempt at resolving these issues. With XForms, you separate the data that is being maintained from the way the data is captured and from the way that it is presented.
The following example shows a valid XForm inside some XHMTL. Note that XForms is expected to included in XHTML2.0, and so will remove the need for the xforms namespace used in this example.
<html xmlns:xf="http://www.w3.org/2002/xforms"> <head> <xf:model> <xf:instance> <person> <name> <first>Anthony</first> <last>Marendy</last> </name> <employment> <company>Software Projects</company> </employment> </person> </xf:instance> <xf:submission id="form1" method="get" action="submit.cgi"/> </xf:model> <body> <xf:input ref="name/first"> <xf:label>First Name</xf:label> </xf:input> <br />
<xf:input ref="name/last"> <xf:label>Last Name</xf:label> </xf:input> <br /><br />
<xf:submit submission="form1"> <xf:label>save</xf:label> </xf:submit>
</body>
</html>
Additionally, standard xml schema data types and validation can be applied to the instance data in an Xform. This leads the way to simple client side validation. Additionally, the instance data can easily be serialized on either the client or server.
Additionally, when the form is submitted, the client will submit the instance data. What this means is that the server doesn’t really care about how the data was produced. All it cares about is that the submitted instance data is compliant. There are many techniques and tools (such as xml schema validation) that can be used to ensure instance data compliance. This separation of concerns has many benefits for application design. For example, assuming the structure of the instance data does not change, then the way the data is captured can be varied without requiring server side changes. i.e. you can change the xform without having to change the server that handles the XForm submission.
Generally, decoupling of application components is a good thing, and often leads to systems that can be more easily tested, integrated and provide much better deployment models.
The current state of XForms technology is that no browsers currently support XForms natively. However, there are a number of browser plugins such as the Firfox XForms extension and formsPlayer for I.E. which provide browser support for XForms. Additionally, there are a number of server side implementations (such as Chiba and Orbeon which are server based solutions which serve XForms to users using current technology browsers by converting the XForm definition into standard HTML, Ajax and JavaScript.
The Scriptura eForms implementation is a best of breed approach using server-side XForms, and is (currently) based upon the Chiba product.
Users can author XForms directly from within Scriptura Designer as illustrated below. Scriptura Designer also allows for the Integration of Web Service calls to the XForm.
Additionally, form flows can be defined which can be used to route instance data between eForms as illustrated below.
This approach is consistent with an MVC based approach where the eForm instance data becomes the Model, the eForm becomes the view, and the Form Flow definition becomes the Controller.
The advantage of this approach is that, provided the structure of the instance data doesn’t change, you can change the presentation of the eForms, add or remove eForms, and change the overall document flow without writing a line of code. As changes to the eForm do not directly impact the application and so can be deployed using a much shorter lifecycle leading to much better business agility.
For more information please contact us.