XML Forms, Web Services and Apache Cocoon

"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.

Example 2. 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.