XML Forms, Web Services and Apache Cocoon
Server side business logic is often invariant with regard to client devices. An email client supports the same basic operations whether it's used from a cellular phone, PDA, or a PC. To address the needs of web developers who build applications for a variety of devices, the W3C has formed the XForms working group. According to the XForms specification,
"XForms" is W3C's name for a specification of Web forms that can be used with a wide variety of platforms including desktop computers, hand helds, information appliances, and even paper. Part of the HTML Activity, XForms started life as a subgroup of the HTML Working Group, but has now been spun off as an independent Working Group.
XForms are comprised of separate sections that describe what the form does and how it looks. This allows for flexible presentation options, including classic XHTML forms, to be attached to an XML form definition. The following illustrates how a single device-independent XML form definition, called the XForms Model, has the capability to work with a variety of standard or proprietary user interfaces:
 |
| Figure 1. XForms Conceptual Model |
In this article we discuss the Cocoon XMLForm framework's separation of the purpose from the presentation of a form, maximizing its reusability for a variety of client devices. We also explain how this technology allows us to extend web applications to Web Services.
Apache Cocoon XMLForm is aligned to a large extent with the W3C XForms standard. While XForms requires that client devices understand the XForms markup, XMLForm can be used with any browser for any client device. The trade-off for this convenience is that XMLForm lacks some of the client side features of XForms, such as events and actions.
XMLForm basics
XMLForm is a middle-tier framework based on the MVC (Model-View-Controller) design, which combines the best from Jakarta Struts, W3C XForms, and Schematron.
Its goals include the following:
- Ease the development of interactive web applications utilizing complex data types and multi-page transactions
- Provide an automated 2 way mapping between HTML Forms <-> XML <-> JavaBeans (and XML DOM objects)
- Use standard XML schema languages like XML Schema, Relax-NG and Schematron for data validation
- Promote reuse of Cocoon Actions for:
- Workflow control of UI centric web applications - HTML, WML, UXL, VoiceXML, etc.
- Web Services (based on the REST paradigm)
- Remote Portal Forms. An interactive extension of RSS for Web syndication of portal functionality.
- Utilize XPath tools like Apache Jakarta Commons JXPath for read/write access to JavaBeans, DOM nodes and mixed objects.
- Allow maximum utilization of XML functional testing frameworks like AntEater
XMLForm allows developers to build and edit an XML document, called the form model or instance -- subject to constraints from some schema: WXS, Schematron, and so on -- by interacting with a series of form pages. The instance is either a DOM-document or a Java bean-structure or a mix. XMLForm consists of three main components:
- Form -- responsible for the instance and its validation. Form objects are stored in request attributes for one page forms and session attributes for wizards (multipage forms). A Form can be populated from the request parameters. This is the "model" in MVC terms.
- Transformer (XMLFormTransformer) -- takes a form descriptor document, (similar to XForms) as input and fills it with data and error messages from a Form object that is referred to in the document. This is the "view" in MVC terms.
- Action (AbstractXMLFormAction) -- creates the Form object if necessary and populates it with data based on the request parameters. It can also take care of workflow handling and special controls like checkbox states. This is the "controller" in MVC terms.
The following data flow diagram is an overview of the XMLForm components interaction.
 |
| Figure 2. XForms Dataflow Diagram |
To set the stage for future discussion, we will show a snippet of a
typical Cocoon sitemap for an application which uses XMLForm
components:
Example 1. Web Application Utilizing XMLForm
<map:pipeline>
<map:match pattern="wizard*">
<map:act type="WizardAction">
<!-- XMLForm parameters -->
<map:parameter name="xmlform-validator-schema-ns"
value="http://www.ascc.net/xml/schematron"/>
<map:parameter name="xmlform-validator-schema"
value="schematron/wizard-xmlform-sch-report.xml"/>
<map:parameter name="xmlform-id" value="form-feedback"/>
<map:parameter name="xmlform-scope" value="session"/>
<map:parameter name="xmlform-model"
value="org.apache.cocoon.samples.xmlform.UserBean"/>
<!-- Content transformation logic -->
<!-- original XMLForm document -->
<map:generate src="wizard/{page}.xml"/>
<!-- populating the document with model instance data -->
<map:transform type="xmlform" label="debug, xml"/>
<!-- personalizing the look and feel of the form controls -->
<map:transform src="stylesheets/wizard2html.xsl"/>
<!-- Transforming the XMLForm controls to HTML controls -->
<map:transform src="context://samples/stylesheets/xmlform/xmlform2html.xsl"/>
<!-- sending the HTML back to the browser -->
<map:serialize type="html"/>
</map:act>
</map:match>
</map:pipeline>
With the Cocoon 2.1 distribution, you can see XMLForm in action by visiting the url: http://localhost:8080/cocoon/samples/xmlform/.
Form and Model
The form is a key concept in XMLForm. A form is always associated with an underlying domain model, which is either a JavaBean or an XML DOM object. A form serves two roles: It describes how the user should enter a certain piece of data, either through a text field, drop down select, check box, radio button or another input control. It also specifies what part of the underlying model does the input data update.
What is the purpose of the Form and the Model?
Let's consider the following web form which collects personal information:
 |
| Figure 3. Sample web form |
This web form is rendered in HTML, which was derived from the following XMLForm document.
<xf:form id="form-feedback" view="userIdentity" action="wizard">
<xf:caption>Personal Information</xf:caption>
<error>
<xf:violations class="error"/>
</error>
<xf:textbox ref="firstName">
<xf:caption>First Name</xf:caption>
<xf:violations class="error"/>
</xf:textbox>
. . .
<xf:selectMany ref="role" selectUIType="listbox">
<xf:caption>Professional roles</xf:caption>
<xf:item>
<xf:caption>Geek</xf:caption>
<xf:value>Geek</xf:value>
</xf:item>
<xf:item>
<xf:caption>Hacker</xf:caption>
<xf:value>Hacker</xf:value>
</xf:item>
. . .
</xf:selectMany>
<xf:submit id="next" class="button">
<xf:caption>Next</xf:caption>
</xf:submit>
</xf:form>
XMLForm, borrowing from W3C XForms, defines a device-neutral,
platform-independent set of form controls suitable for general-purpose
use. The controls are bound to the XMLForm model via the XMLForm binding
mechanism, in this case using the ref attribute on the
controls. This markup would be transformed by XSLT to HTML or WML,
VoiceXML or another client device markup.
The Form model for this example can be an XML DOM object or a JavaBean. XMLForm uses the Apache Commons JXPath library for its binding mechanism, which in turn relies on JavaBeans introspection.
Notice the following features of the XMLForm design:
- The user interface is not hard-coded to use HTML check boxes or a select list. Different devices (such as voice browsers) can render the concept of "select many" as appropriate.
- Form controls always have labels directly associated with them as child elements - this is a key feature designed to enhance accessibility.
- Markup for specifying form controls has been simplified in comparison with HTML forms.
The fact that you can bind form controls to the model like this simplifies integrating XMLForms into other host languages, since any form control markup may be used to bind to the model.
