Background

Often a single form can be developed to collect standard sets of data from many different sources. A single one-size-fits-all form for a specific data collection purpose is ideal because it can constrain data input values for data integrity and allow for easy correlation and summarization of data across a wide variety of sources. XForms is a good choice for this kind of data-driven form because it is an open standard that can run on a variety of Web-enabled platforms.

In order for the data to be collected, the XForms document must have a submission target, or someplace for the data to be sent or stored when the input is complete and the user clicks a submit button. However, each form filling location may have unique submission requirements, such as saving a local copy of the form submitted, or submitting a form to a write-only location or "vault" for recording each submission for auditing and logging purposes. These unique submission requirements can erode the value of a single form since a single form cannot encapsulate each form filling location's unique submission requirements. The ability to decouple the submission requirements from the standard form so that each form filling site can have as many specific unique submission targets as needed can be achieved by using JavaScript for Document Object Model (DOM) programming and joining the submission targets with the XForms document at runtime in the browser.

See the Downloads section to download the complete XForms, schemas, XML data instances, and stylesheet used in the article.

Sample XForms document

Consider a scenario like a long-term medical study, where study participants are interviewed periodically and asked about a specific set of symptoms that they may be experiencing. A simple form for recording a single subject instance response to a periodic check-up interview might look like the XForms document in Figure 1.

In this simple example form, only three input fields are being collected: a string for Subject ID, a date using xs:date type with an XForms rendered date picker to constrain the input, and an enumerated set of symptoms (none, fever, muscle pain, joint stiffness, and nausea). The schema definition for instances submitted by this XForms document is shown in Listing 1.

      
...            
<xs:simpleType name="incidentType">
  <xs:restriction base="xs:string">
    <xs:enumeration value="none" />	  
    <xs:enumeration value="fever" />
    <xs:enumeration value="muscle pain" />
    <xs:enumeration value="joint stiffness" />
    <xs:enumeration value="nausea" />	    	    
  </xs:restriction>
</xs:simpleType>

<xs:complexType name="incidentReportType">
	<xs:sequence>
		<xs:element name="theSubjectID" type="xs:string" maxOccurs="1" />
		<xs:element name="theDate" type="xs:date" maxOccurs="1" />
    	<xs:element name="theSymptom" type="incidentType" maxOccurs="1" /> 
	</xs:sequence>
</xs:complexType>

<xs:element name="theIncident" type="incidentReportType"/>
...
      

Since each input field is backed by a schema definition that explicitly defines its type, XForms can prohibit submission of the input data until all data is valid against the schema that enforces homogeneity of the data across all the submission sites. In this schema, theDate is constrained to the type xs:date and theSymptom is constrained to the type incidentType. Additionally, the maxOccurs attribute further constrains the data so that each input field will occur only once in the submitted data instance. A sample submitted instance for this form instance looks like what is shown in Listing 2.

       
...      
<theIncident xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="theIncident.xsd">
     	<theSubjectID>7D</theSubjectID>
     	<theDate>2006-10-13</theDate>
     	<theSymptom>none</theSymptom>
</theIncident>  
...    
      

Back to top

Static XForms submit

The XForms document shown in Figure 1 has a submit button presented to the user of the form to be able to submit the data when input is complete. This submit button activation can be associated with XForms data model-specific submission actions. In this case the data model is an instance like Listing 2 based on the schema in Listing 1. In the XForms document the submission action or actions are defined with the model and instance that the actions apply to. For example, in Listing 3, two submissions are defined: a remoteSave submission that will submit the XML instance theIncidentInstance to an xformstest.org echo service, and a localSave submission that will save a copy of the theIncidentInstance on the local disk.

       
...
<xforms:model id="theIncidentModel" schema="theIncident.xsd">
  <xforms:instance id="theIncidentInstance" src="theIncident.xml"/>
  <xforms:submission id="remoteSave" 
  action="http://xformstest.org/cgi-bin/showinstance.sh"
      method="post"/>
  <xforms:submission id="localSave" action="./local_save.xml"
      method="put"/>                              
</xforms:model>
...
      

A simple XForms trigger is used to create the submit button that upon activation will invoke the two (or more if defined and invoked) submission actions, as shown Listing 4.

      
...        
<xforms:trigger>
 <xforms:label>Submit</xforms:label>    
	<xforms:action ev:event="DOMActivate">
		<xforms:send submission="remoteSave"/>
		<xforms:send submission="localSave"/>
	</xforms:action>
</xforms:trigger> 
...        
        

This is a valid and useful form, but it requires the form author to know about the local submission requirements (like the local disk save) of the form filler site, which is not a scalable option for a form being used by many sites. What is needed is a way to allow local form filler sites to define local submission requirements separate from the form and the submitted instance definition.

Back to top

Dynamic XForms submit

The XForms data model mechanism and JavaScript programming against the Document Object Model (DOM) presents a scalable solution that allows the form to remain unchanged, but provides each site with the flexibility to define as many unique submission requirements as needed. The first piece of the solution is a separate data model for defining and holding the submission actions, which XForms supports easily. A simple schema can be defined to hold submit action information such as the target of the submission, an identifier to identify the submission action uniquely, and an invocation method (such as put or post), as shown in Listing 5.

       
...             
<xs:simpleType name="methodType">
  <xs:restriction base="xs:string">
      <xs:enumeration value="put" />
          <xs:enumeration value="post" />
            </xs:restriction>
</xs:simpleType>

 <xs:complexType name="actionType">
  <xs:simpleContent>
     	<xs:extension base="xs:string">
  <xs:attribute name="theMethod" type="methodType" />
  <xs:attribute name="theId" type="xs:string" />		   		    	    	
   		</xs:extension>
   	</xs:simpleContent>
   </xs:complexType>
           
<xs:complexType name="submitListType" >
   <xs:sequenceminOccurs="0"maxOccurs="unbounded">
   <xs:element name="theAction" type="actionType" />
  </xs:sequence>
</xs:complexType> 
...	                        
       

This schema will allow instances to be created with multiple submissions populating a separate data model. A primer data model with default submission settings could be sent with the form and then edited at each site. An instance example with the two submissions options from the previous "hardcoded" XForms document submissions from Listing 3 are shown in a separate XML instance that can be used as a XForms data model in Listing 6.

       
...      
<theSubmitList>
	<theAction theMethod="post" theId="remoteSave">
	http://xformstest.org/cgi-bin/showinstance.s</theAction>
	<theAction theMethod="put" theId="localSave">./local_save.xml</theAction>
</theSubmitList>      
...
      

Once a separate data model for the submissions is available, then JavaScript can be used to write into the DOM at runtime and associate the instance model to be submitted with the local submission targets. The JavaScript and the two models along with an "empty" trigger are shown in Listing 7. Note that the theIncidentModel no longer has submissions defined with the model like in the static, hard-coded submissions in Listing 3.

       
...
    <xforms:model id="theSubmitModel" schema="theSubmits.xsd">
    	<xforms:instance id="theSubmitInstance" src="theSubmits.xml"/>
    </xforms:model>
    
    <xforms:model id="theIncidentModel" schema="theIncident.xsd">
      <xforms:instance id="theIncidentInstance" src="theIncident.xml"/>
    </xforms:model>

	<script type="">
	function buildSubmits()
	{
	  var oModel = document.getElementById("theSubmitModel");
	  var oInstance = oModel.getInstanceDocument("theSubmitInstance");

	  var pModel = document.getElementById("theIncidentModel");
	  var pInstance = pModel.getInstanceDocument("theIncidentInstance");
 	
	  var theSubmits = oInstance.getElementsByTagName("theSubmits");
	  var theSubmitList = theSubmits[0].getElementsByTagName("theSubmitList");
	  var theAction = theSubmitList[0].getElementsByTagName("theAction");

   	  var submitTrigger = document.getElementById("dynamicSubmit");

	  for(var i = 0; i < theAction.length ;i++) {
	n = document.createElementNS("http://www.w3.org/2002/xforms", "xforms:submission");
	n.setAttribute("id" , theAction[i].getAttribute("theId"));
	n.setAttribute("method" , theAction[i].getAttribute("theMethod"));		
	n.setAttribute("action" , theAction[i].textContent);
	pModel.appendChild(n);

	m = document.createElementNS("http://www.w3.org/2002/xforms", "xforms:send");
	  m.setAttribute("submission" , theAction[i].getAttribute("theId")) ;
		submitTrigger.appendChild(m);
	  }
	}
	</script>    
...
    <xforms:trigger>
	    <xforms:label>Submit</xforms:label>    
    	<xforms:action ev:event="DOMActivate" id="dynamicSubmit">
    	</xforms:action>
    </xforms:trigger>
    
  	<script type="">
		buildSubmits();
  	</script>   
...
      

The JavaScript sets up two model and instance variables for the two XForms data models, the theSubmitModel and the theIncidentModel, respectively, and then iterates through the theSubmitModel instance and adds the submissions to the theIncidentModel instance's XForms model definition in the DOM as well as adding the submission actions to the XForms submit button trigger in the DOM. The trigger to be updated does have to be uniquely identified, and in this case the trigger has an ID of dynamicSubmit to uniquely identify it. These updates happen in memory in the DOM and are never written in the XForms code itself on disk, but may been seen inline in the DOM with a DOM Inspector, as shown in Figure 2.

Back to top

Submission editing form

Since the submissions are now being kept in a separate data model and file on disk, this separate instance of submits now becomes a candidate for its own XForms document, which can be easily generated from the XML instance and backing schema itself with the XML Forms Generator (see the Resources section for a link to the XML Forms Generator Eclipse plugin). The resultant XForms documents are shown in Figure 3.

Back to top

Conclusion

XForms is an excellent technology choice for creating data-driven forms capable of applying schema-driven constraints to XML instance data submissions where homogenous data is being collected from many sources that needs to be correlated and summarized quickly and efficiently. By decoupling the form filler site unique data submission requirements from the logical form itself and the submitted instance you get the control of a single form and a single set of data entry constraints with the flexibility of mutliple, site-unique submission options. This decoupled approach with a runtime joining in the DOM of the form and the mutliple, site-specific submission requirements can be done with JavaScript programming by reading mutliple submissions option from a separate model and writing those options to the XForms submitted instance model and XForms submit button trigger in the DOM.

XForms 1.0 requires the use of JavaScript programming against the DOM to support this kind of dynamic mutliple submission target scenario, but there is a declarative solution being considered by the W3C XForms Working Group for the XForms 1.1 Working Draft. Specifically, a resource child element for the XForms submission element that will allow a URI to be used for dynamically calculating the submission based on instance data.

Back to top

Download

Information about download methods

Resources

Learn

• XForms basics (developerWorks, Oct 2006) Learn the essentials for creating the next generation of forms.
  
  
• Introduction to XForms, Part 1: (developerWorks, Sep 2006) The new Web standard for forms.
  
  
• Introduction to XForms, Part 2: (developerWorks, Sep 2006) Forms, models, controls, and submission actions.
  
  
• Introduction to XForms, Part 3: (developerWorks, Sep 2006) Using actions and events.
  
  
• Model-driven XML forms generation, Part 1: (developerWorks, Aug 2005) Start using the XML Forms Generator.
  
  
• Develop forms using the Visual XForms Designer (developerWorks, Jun 2006) Use free tooling to accelerate the development of standard-compliant forms.
  
  
• In the XML area on developerWorks, get the resources you need to advance your skills in the XML arena.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Get the W3C DOM Specifications.
  
  
• Get the W3C XForms 1.0 2Ed Specification.
  
  
• Get the W3C XForms 1.1 Public Working Draft Specification.
  
  
• Get the Firefox XForms extension.
  
  
• Get the Firefox Firebug extension.
  
  
• Get the alphaWorks XML Forms Generator.
  
  
• Get the alphaWorks Visual XForms Designer.
  
  

Discuss

• Participate in the discussion forum.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Background
• Sample XForms document
• Static XForms submit
• Dynamic XForms submit
• Submission editing form
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into XML on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers