Forms are ubiquitous in today’s software applications, and the user input they facilitate is key to business processes. As such, automation of form generation is highly desirable, as the development of practically any software system requires the creation of one or more forms to gather user input.

A standardized, data-driven approach to forms technology facilitates the building of form-generation technology. A standardized format for forms permits the creation of well-understood, portable forms, while a data-driven approach makes it easier to generate forms based on a representation of the data to be collected, especially if accompanied by metadata that describes characteristics of that data.

The Eclipse Modeling Framework (EMF) provides a representation of such metadata, and ties it into actual instance data, while providing APIs and tooling for the introspection of those structures. An EMF representation of data serves as an ideal starting point from which to generate a form for the collection of instance data.

Therefore, given a description of data to be collected (such as an XML document) and an EMF model of that data, it is possible to generate rich, working forms almost immediately. This article describes tooling that does exactly that.

The solution presented in this article also provides for generation of forms from WSDL documents. Part 2 of the series covers that process.

The tools described here are seamlessly integrated into the open source Eclipse tools platform, and are freely available on IBM alphaWorks as the XML Forms Generator.

XForms

The World Wide Web Consortium (W3C) has developed the XForms standard for the presentation and collection of form data. As stated in the W3C Recommendation, XForms is intended to be "the next generation of forms for the Web." XForms provides a number of advantages over existing HTML forms technology. As the Recommendation itself declares, "By splitting traditional XHTML forms into three parts -- XForms model, instance data, and user interface -- it separates presentation from content, allows reuse, gives strong typing -- reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting."

The instance data driving an XForm is an XML document, optionally backed by a descriptive XML Schema that permits validation of the data. This mechanism is well-suited to the use of EMF, which provides tools for the conversion of XML Schema documents to EMF models, and also for the serialization and deserialization of XML instance documents that conform to those models.

Furthermore, as pure XML, an XForms document can be backed by an EMF model, and you can create and serialize XForms documents that are guaranteed to conform to that model. EMF models also easily handle cross-namespace references, which is critical because, as is stated in the XForms 1.0 Recommendation, "XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML." XForms also uses markup defined in the XML Events specification to drive eventing within XForms documents, in place of the more-complex scripting used for the same purpose in HTML forms.

In other words, an XForms document will always be a compound document, as defined in the developerWorks article "Model-driven compound document development." As such, the XML Forms Generator leverages many of the core technologies underlying the Compound XML Document Editor, including the use of EMF, discovery of models, and renderer-ready serialization.

The technology stack in Figure 1 illustrates how the XML Forms Generator and the Compound XML Document Editor share a common foundation.

Back to top

The XML Forms Generator

The XML Forms Generator Eclipse plug-in takes a model-driven approach to forms generation. As a starting point, it uses either WSDL documents or XML instance documents that have EMF backing models. The generated forms adhere to the XHTML and XForms 1.0 standards, and can be viewed in popular XHTML/XForms renderers.

When generating from an XML instance document, the XML Forms Generator has access to the models of the data domain to which the XML instance document belongs. Therefore, for each data item in the instance document, the Generator automatically creates the appropriate forms constructs. Those constructs include type constraints, length constraints, control types (drop-down list, text input, range), and iterative structures.

The XML Forms Generator can also generate XHTML/XForms documents from source WSDL documents. Tooling is also included for the generation and testing of JavaServer Pages (JSP) Web service response templates.

Working forms, right away

The XML Forms Generator can generate valid, working forms with only a few mouse-clicks. This contrasts with other approaches to form creation, the most naïve of which is creating a form by hand in a text editor. A context-sensitive editor such as the Compound XML Document Editor -- with its context-sensitive menus that provide cues and guarantee construction of a valid document -- improves greatly on free-form text editing, but does not provide anything that could be called automation of form generation.

Another possible technique provides some automation by offering an editor that populates palettes of appropriate controls based on an analysis of an XML Schema that describes as-yet-unspecified instance data for the form. However, while this scheme provides for better context-sensitive, data-centric form construction, it is still up to the end user to actually put together a working form from the constructs that have been made available.

The XML Forms Generator, by contrast, allows for the creation of a fully-functioning form almost immediately. By using an XML data instance as the starting point, the Generator knows which specific data must be collected by any generated form, and, therefore, knows which form fields to create. Similarly, when starting from a WSDL document, the selection of an operation permits examination of the specific message parts for which form inputs must be generated.

The XML Forms Generator provides a sampling of customization options for the generated form -- including settings for when an input field should be generated as a textarea control to accommodate more textual input, and the submission target of the form -- but requires minimal user input for the generation of a fully-functioning form. After such a form has been generated and tested, any visual or other changes will most likely be made in the developer’s favorite editor.

By generating a fully-functioning form -- one that can immediately be tested to ensure that the proper data is gathered and submitted -- the XML Forms Generator accelerates development of standards-conforming forms in ways that other approaches to forms creation do not.

Back to top

Generation from data

XForms require an XML instance to which form controls can refer, so an instance document is a natural starting point for XForms generation.

Furthermore, the XML Forms Generator benefits from the separation of concerns that XForms encourage between the creation data instances and the creation of presentable forms. In a typical development process, a data domain expert would create the XML instances and their corresponding models and deliver them to a more UI-focused forms developer. The forms developer could then use the XML Forms Generator to very quickly generate a working, testable form from the instance data provided.

This section demonstrates how the XML Forms Generator uses model information to create forms from XML instance documents.

A simple form: postal address

Here is a brief example that shows several key features of the XML Forms Generator. Listing 1 is a fairly small XML document that represents a postal address:

<PostalAddress type="streetAddress" 
               xmlns="http://ns.hr-xml.org/2004-08-02">
    <CountryCode>US</CountryCode>
    <PostalCode>61043</PostalCode>
    <Region>IL</Region>
    <Municipality>OAKWOOD</Municipality>
    <DeliveryAddress>
        <AddressLine>143 MAIN ST.</AddressLine>
        <AddressLine/>
        <AddressLine/>
    </DeliveryAddress>
</PostalAddress>

Listing 2 is a Schema for this XML:

<xsd:complexType name="PostalAddressType">
    <xsd:sequence>
        <xsd:element name="CountryCode" type="xsd:string"/>
        <xsd:element name="PostalCode" type="xsd:string"/>
        <xsd:element name="Region" type="xsd:string"
                     maxOccurs="unbounded"/>
        <xsd:element name="Municipality" type="xsd:string"
                     minOccurs="0"/>
        <xsd:element name="DeliveryAddress" minOccurs="0">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="AddressLine" type="xsd:string"
                                 minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:element>
    </xsd:sequence>
    <xsd:attribute name="type" default="undefined">
        <xsd:simpleType>
            <xsd:restriction base="xsd:string">
                <xsd:enumeration value="postOfficeBoxAddress"/>
                <xsd:enumeration value="streetAddress"/>
                <xsd:enumeration value="militaryAddress"/>
                <xsd:enumeration value="undefined"/>
            <xsd:restriction>
        </xsd:simpleType>
    </xsd:attribute>
</xsd:complexType>
<xsd:element name="PostalAddress" type="PostalAddressType"/>

The XML Forms Generator examines both the data instance and its underlying model in order to generate appropriate XForms constructs. Put simply, the instance document determines what fields will be generated, while the model definition determines what those fields will look like and how they will behave. The current example contains several cues that the XML Forms Generator will use:

1. The type attribute of the PostalAddress element is actually an enumerated type, allowing a choice of one of four strings. Enumerated types such as this are good candidates for visual form constructs such as a drop-down list, which permits the selection of one option among a finite list of possibilities.
2. The instance document contains more than one AddressLine element as a direct descendant of the DeliveryAddress element. This reveals a one-to-many relationship between DeliveryAddress and AddressLine that is confirmed in the Schema’s definition of the AddressLine element, with its maxOccurs value of "unbounded". When a one-to-many relationship exists, the desirable behavior in a generated form is to show all current subelements of the one parent element, while allowing the addition and removal of individual subelements.
3. The instance document contains only one Region element. Therefore, from the instance document alone, it is not possible to infer that a one-to-many relationship exists between PostalAddress and Region. However, upon examining the Schema’s definition of Region, with its maxOccurs of "unbounded", you can see that a one-to-many relationship in fact does exist between PostalAddress and Region.

At run time, the actual incarnation of the model is not XML Schema; it is an XMI-based EMF ECore model definition that contains the same sort of information (data types, relationship cardinalities) that's given in XML Schema. EMF provides utilities to generate ECore representations of metadata from several types of sources, including XML Schemas and UML class models created in IBM Rational Rose®. For example, Figure 3 shows a representation of the PostalAddress metadata in an IBM Rational Rose class diagram:

After the metadata is encoded in ECore and made available to the XML Forms Generator, the Generator can construct forms based on any valid XML instance document that conforms to that model. In the PostalAddress example, the resulting XHTML/XForms document surfaces the model features mentioned above by:

1. Surfacing the control for the type attribute of the PostalAddress element as an XForms select1 control by generating the following markup within the generated form:
   
   Listing 3. Markup for an XForms select1 control
   

   <xforms:select1 ref="/hrxml:PostalAddress/@type" model="model_PostalAddress"> <xforms:label>Type</xforms:label> <xforms:item> <xforms:label>Post Office Box Address</xforms:label> <xforms:value>postOfficeBoxAddress</xforms:value> </xforms:item> <xforms:item> <xforms:label>Street Address</xforms:label> <xforms:value>streetAddress</xforms:value> </xforms:item> <xforms:item> <xforms:label>Military Address</xforms:label> <xforms:value>militaryAddress</xforms:value> </xforms:item> <xforms:item> <xforms:label>Undefined</xforms:label> <xforms:value>undefined</xforms:value> </xforms:item> </xforms:select1>

   
   
2. Generating an XForms repeat control for both the Region and AddressLine elements, allowing multiples of each. The document also generates triggers that permit the insertion and deletion of individual entries, as shown in this snippet from the generated form:
   
   Listing 4. Snippet from the generated form
   

   <xforms:repeat model="model_PostalAddress" id="repeat_Region_model_PostalAddress" nodeset="/hrxml:PostalAddress/hrxml:Region"> <div> <xforms:input ref="." model="model_PostalAddress"> <xforms:label>Region</xforms:label> </xforms:input> </div> </xforms:repeat> <xforms:trigger> <xforms:label>Add Region</xforms:label> <xforms:insert ev:event="DOMActivate" at="index('repeat_Region_model_PostalAddress')" position="after" nodeset="/hrxml:PostalAddress/hrxml:Region"/> </xforms:trigger> <xforms:trigger> <xforms:label>Delete Region</xforms:label> <xforms:delete ev:event="DOMActivate" at="index('repeat_Region_model_PostalAddress')" nodeset="/hrxml:PostalAddress/hrxml:Region"/> </xforms:trigger>

   
   

Some constructs in the generated form, such as the use of XHTML div tags to separate content, are not required in an XHTML/XForms document, but are inserted by the XML Forms Generator to provide clearer separation and more cues for styling.

Figure 4 shows what the generated form looks like in an XHTML/XForms-capable renderer (in this case, X-Smiles 0.93).

The PostalAddress example you see here is one of several samples provided with the XML Forms Generator distribution. A backing model also is provided, so you can generate working forms from any of those samples as soon as you have installed the Generator.

Deeper model analysis

Other information available in a model is relevant to form generation. XForms provides for validation based on type constraints and other properties, including minimum and maximum allowed string length (in fact, the XForms specification permits such validation constructs based on any boolean XPath expression). In addition, you can reasonably infer the need for some other type of form control, such as the XForms range control, from information available in the model.

Type information is particularly important to XForms renderers, which render different types of controls based on the data type of the corresponding instance element or attribute.

The XML Forms Generator detects the data types of elements and attributes for which it generates form fields. If the type is found to be a primitive other than a string -- such as a float, double, integer, boolean, or date -- the Generator inserts an XForms bind element in order to ensure strong typing of that field in the form.

Renderers use type information, such as that provided in a bind element, to determine the best visual representation of a corresponding form field. In the rendering shown in Figure 5 (in X-Smiles 0.93), the three input fields all have as their markup source an XForms input element. The renderer takes the type information for each element or attribute referenced -- in this example, the types are boolean, string, and date, respectively -- and renders an appropriate control (here, a checkbox, a text field, and a date-chooser, respectively).

The type binding alone provides cues to the renderer, as seen in the markup in Listing 5, which results in the rendering in Figure 5:

...
<xforms:model id="model_SARSNotificationInformation">
    <xforms:instance id="instance_model_SARSNotificationInformation"
                     src="SARSForm.xml"/>
    <xforms:submission id="submit_model_SARSNotificationInformation"
               action=http://xformstest.org/cgi-bin/showinstance.sh
               method="put"/>
    <xforms:bind nodeset="//cct:Given" type="xsd:boolean"/>
    <xforms:bind nodeset="//cct:StartDate" type="xsd:date"/>
</xforms:model>
...
<xforms:input ref="//cct:Given"
              model="model_SARSNotificationInformation">
    <xforms:label>Given</xforms:label>
</xforms:input>
<xforms:input ref="//cct:Description"
              model="model_SARSNotificationInformation">
    <xforms:label>Description</xforms:label>
</xforms:input>
<xforms:input ref="//cct:StartDate"
              model="model_SARSNotificationInformation">
    <xforms:label>Start Date</xforms:label>
</xforms:input>

Similarly, you can also apply constraints to indicate limits on the length of a string entry. In XML Schema, these limits would be specified in minLength and maxLength attributes. In the binding example below, both the minimum and maximum length are 2, allowing the XML Forms Generator to optimize the expression to an equivalence comparison:

<xforms:bind nodeset="//cct:Code" constraint="string-length(.)=2"/>

XForms also permits the specification of particular elements or attributes as required for successful submission of the form. The XML Forms Generator detects required attributes, and adds a bind element that marks such attributes as required:

<xforms:bind nodeset="//hrxml:Name/@role" required="true()"/>

Other information garnered from the model can show a need for the XForms range control. In Listing 6, the instance element is discovered to be of a numeric type that has a minValue of 0 and a maxValue of 200:

<xforms:range ref="cct:Age" model="model_SARSNotificationInformation"
              start="0" end="200" step="1">
    <xforms:label>Age</xforms:label>
</xforms:range>
<xforms:output ref="cct:Age"
               model="model_SARSNotificationInformation"/>

Finally, an enumerated type may, in a Schema, be part of a union with a primitive type. The ideal data-entry construct in such a situation would be a control in which the user could select from among the available values as defined in the enumeration, while retaining the ability to enter free-form data that might not correspond to an enumerated value. XForms provides such a control in the form of an "open" selection:

<xforms:select1 ref="./@employerOrgType" model="model_Resume"
                selection="open">
...

The XML Forms Generator detects the need for an open selection through the use of a custom ECore annotation on an element or attribute that has an enumerated type. This results in the addition of the selection="open" attribute to the select1 control that's generated for the enumerated type.

Back to top

Conclusion

The XML Forms Generator utilizes Model Driven Development concepts with EMF to permit generation of forms from XML instance data. The Generator is a standards-based, model-driven tool that enables the immediate generation of working forms, providing a head start in forms development.

WSDL is another common description mechanism for data that must be gathered. Part 2 will cover the XML Forms Generator’s generation of forms from WSDL documents in more detail.

Acknowledgements: Thanks to Kelvin Lawrence and Henry Tran of IBM.

Resources

Learn

• Learn more about Eclipse and the Eclipse Modeling Framework at eclipse.org.
  
  
• Read "Model-driven compound document development" (developerWorks, July 2005) to find out how to build compound XML documents in Eclipse.
  
  
• Visit the W3C to learn more about the XForms 1.0, XHTML 1.0, and XML Events Recommendations.
  
  
• Get more information on the HR-XML consortium, including the HR-XML schemas used as examples in this article.
  
  
• Some examples in this article were generated from U.S. Centers for Disease Control and Prevention schemas.
  
  
• Find more XML resources on the developerWorks XML zone.
  
  
• Learn how you can become an IBM Certified Developer in XML and related technologies.
  
  

Get products and technologies

• Visit IBM alphaWorks to find out more about the following technologies mentioned in this article:
  • XML Forms Generator
  • IBM XML Forms Package
  • IBM Forms for Mobile Technologies
  • Compound XML Document Editor
  
  
• Check out X-Smiles, a Java language-based XML browser.
  
  
• Download the Novell XForms Explorer beta, a plug-in for Microsoft Internet Explorer 6.0 and above.
  
  
• Download the FormsPlayer plug-in for Microsoft Internet Explorer 6.
  
  
• Download the XForms implementation (evaluation only) for Mozilla and Firefox.
  
  

About the authors

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• XForms
• The XML Forms Generator
• Generation from data
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
• Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
• Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
• Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Open source on developerWorks

Cloud computing for developers

Virtual workshop: Learn how to build a cloud infrastructure and develop/deploy cloud-based applications. (6-8 Apr 2010)

Special offers