The W3C 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."
XForms documents feature a data model that contains one or more XML instance documents. The form manipulates such an instance document and provides for the submission of that XML to a back-end system.
XForms achieved a significant milestone with the release of the second edition of the XForms 1.0 specification on 14 Mar 2006. The Visual XForms Designer became available on alphaWorks shortly thereafter.
Where do you get the Visual XForms Designer?
You can find installation instructions on IBM alphaWorks (see Resources). To access the detailed instructions for using Eclipse's own install/update mechanism to get the Visual XForms Designer, click the Download tab.
The Visual XForms Designer requires Eclipse 3.1, with Eclipse Web Tools 1.0 (see Resources), running against a 1.5-level Java™ Runtime Environment (JRE).
Creating a new XForms document
Let's build a form using the Visual XForms Designer. To create a new XForms document, access the New XForms Document menu item in Eclipse's standard New wizard (see Figure 1).
Figure 1. Creating a new XForms Document

After you select a location for the new document, the Visual XForms Designer's editor will open on the new, blank document. If you're not in the Visual XForms Designer perspective already, the editor will prompt you to switch. Once you're in that perspective, you'll see an Eclipse layout like the one in Figure 2.
Figure 2. The Visual XForms Designer perspective

Now you're ready to build a form. Building an XForms document generally comprises at least three phases:
- Define the instance data
- Create input controls and bind them to the instance data
- Provide for submission of the form to a back-end system
You'll see how the Visual XForms Designer helps you perform each of these tasks in the next three sections of this article. Finally, you'll learn how to test your form in a rendering environment.
When you build an XForms document, you're likely to first define a data model. This data model contains instance data that you'll later bind to user interface controls.
An instance document within an XForms model is just an XML document. Like any XML document, the instance might or might not be backed by an XML Schema, which defines its allowable structure.
In the Visual XForms Designer, you can define instance data for your form in several ways. First, you can create an XML instance document from an XML Schema definition. In the Visual XForms Designer, a view known as the Enclosures view (see Figure 3) permits you to import external documents, including XML Schema documents. After selecting the Enclose Schema File menu option, you can browse to an XML Schema file of your choice and make it accessible to the Visual XForms Designer.
Figure 3. The Enclosures view

You use the Visual XForms Designer's Instance view (see Figure 4) to create and manipulate instance documents. Once you enclose a Schema file, to create an instance document that conforms to that Schema, press the second button from the left in the Instance view's menu bar. The resulting instance document has an element and attribute for each element and attribute declared in the schema.
Figure 4. The Instance view

A second way to create instance data for your form is to use an XML document you already have somewhere on your file system. Once again, the Enclosures view (see Figure 3) provides this functionality. To enclose an instance, right-click on a model under the XForms Instance category, and select Enclose XML File. Once you enclose an instance, the elements and attributes will become available in the Instance view, and you can go there to adjust the instance document any way you like.
A third way to create instance data is to do it the old-fashioned way: Create a blank instance, and build it yourself. The Instance view lets you create a new instance, add and delete elements and attributes, change element and attribute names, move element and attribute nodes, rename them, and assign values to them. All these options are available when you right-click on the node or nodes you wish to work with (see Figure 5).
Figure 5. Options for manipulating instance data in the Instance view

If you need to flesh out your form's data model with more-advanced XForms constructs such as data bindings, you can do so in a view named, simply, XForms. You'll see more of the XForms view later in this article, during the discussion of how to define a submission for your form.
By defining instance data, you've taken a crucial first step in creating your form. However, a form isn't really a form until it has controls -- such as buttons, input fields, and drop-down select boxes -- into which a user can enter data.
Just as the Visual XForms Designer provides more than one way to define instance data, it gives you more than one way to create input controls. The most obvious way to create a control is to select a control from the editor's design palette (see Figure 6) and then drop it onto the canvas.
Figure 6. The design canvas and palette

The palette contains a rich set of options for creating XForms controls, ranging from flow constructs such as switch and repeat, to simple controls such as an XForms input or text area. However, once you place a control onto the canvas in this way, one task remains: to associate the input control with data in your instance document. You can do this in the Properties view by providing a value for the ref property. As an alternative, you can select a node in your Instance view and simply drag it onto the control. Once you drop the data node onto the control, it will become associated with that data.
An even easier way to create a control is to select a node in your instance data and drag it onto an empty area in the design canvas. When you drop it, the Visual XForms Designer will create an input control automatically bound to the data node you had selected, all in one step.
Once you define your instance data, create input fields, and bind them to that data, at least one task remains: to provide for submission of the form data to your back-end system. By now, you won't be surprised to find out that the Visual XForms Designer provides a couple of ways to define a submission and create a button for the user to initiate the submission.
In XForms, the concept of a submission is abstract and reusable. That is, a submission defines what will be submitted, where it will be submitted, and how. Then, you can tie the submission to a control such as a button (a trigger in XForms), so that it will be initiated according to a particular user action.
Creating a submission that a user can trigger is a two-step process: You must declare the submission and define its parameters, and then you must tie it to a user action.
In the Visual XForms Designer, the XForms view allows you to associate a submission with your data model. After you do so, you can use the standard Eclipse Properties view to define the where, what, and how of your submission, as shown in Figure 7.
Figure 7. Defining properties of a submission

Once you create your submission, you can simply drag the submission node onto the canvas. When you drop the submission, the Visual XForms Designer will create an XForms Submit control, which, when a user presses it, will activate the associated submission (see Figure 8).
Figure 8. A complete form with a Submit control

The Visual XForms Designer also makes the XForms Submit control available on the palette. You can add a Submit control to the canvas using the palette item, but you must later associate that control with a submission object. To create this association, specify the submission's unique identifier in the Submit control's id property.
Once you complete your form, the final step is to test it in a real-world XForms rendering environment. A wide variety of XForms rendering options are available to you (see Resources). Some of these rendering options require your form document to be in a specific format, while others do not require any conversion. Fortunately, the Visual XForms Designer contains utilities (see Figure 9) for converting your document into the appropriate format for any one of several renderers.
Figure 9. Conversion options

The Visual XForms Designer provides another set of menu options for rendering the form in any of the renderers you have installed and configured on your local machine (see Figure 10).
Figure 10. Rendering options

Finally, Figure 11 shows a simple form rendered in Mozilla Firefox, with the Mozilla XForms plug-in.
Figure 11. A simple rendered form

In this article, you saw how the Visual XForms Designer enables the major phases of form development: data definition, control creation, submission creation, and testing. Hopefully, addressing form development in this way has highlighted one of the appealing aspects of the XForms standard: the clean separation of model and view. You learned the advantages of addressing the creation of a data instance (the model) first and addressing the creation of user interface controls (the view) only upon completing that task.
In the meantime, you've seen the Visual XForms editor's design canvas and palette, as well as many of the views it provides: Enclosures view, Instance view, XForms view, and Properties view. You've seen the renderer-specific conversion utilities, as well as the facilities for testing your completed form in a renderer.
Of course, the Visual XForms Designer has more to offer. The best way to become familiar with it is to install it and experiment with it yourself. You can install the Visual XForms Designer from IBM alphaWorks (see Resources).
The designer comes with extensive documentation built into the Eclipse help system. This documentation includes an animated tutorial that takes you, with detailed step-by-step instructions, through the creation and testing of a form.
Finally, like most alphaWorks releases, the Visual XForms Designer has its own user forum that you can use to share your questions and comments. While you're there, you might want to take a peek at some related alphaWorks tooling: the XML Forms Generator and Compound XML Document Toolkit. You'll be well on your way to creating your own XForms.
Learn
- Dig into XForms at the home page of W3C XForms,
which has links to the official XForms specification, as well as to a wide variety of XForms rendering options.
- Find out more about XHTML, Cascading Style Sheets (CSS), XML, XML Events, XPath,
and other related standards at the W3C site.
- XML and XML Schema: See developerWorks XML Zone for a wide range of technical articles and tips, tutorials, standards, and IBM Redbooks.
Get products and technologies
- Visual XForms Designer:
Check out the home page, with links to installation instructions, prerequisites, and the forum.
- Mozilla XForms:
Render your standards-compliant forms in Mozilla Firefox using this plug-in.
- XML Forms Generator:
Create functional, standards-compliant forms with a click of the mouse using this Eclipse-based tool from alphaWorks.
- Compound XML Document Toolkit:
Explore other open-standard XML markups, including Scalable Vector Graphics (SVG), MathML, VoiceXML, and Synchronized Multimedia Integration Language (SMIL).
- Eclipse:
Get the open source Eclipse workbench and Web Tools platform.
Discuss
-
Get answers to your questions about the Visual XForms Designer
on its discussion forum.
Jan Joseph Kratky, the development lead for the XML Forms Generator and Visual XForms Designer, is a member of the W3C XForms Working Group. A Sun Certified Java Programmer and Sun Certified Web Component Developer, Mr. Kratky has worked with Java technologies since 1997 and with Eclipse technologies since 2001. He is currently a software engineer with IBM Emerging Software Standards in Research Triangle Park, N.C.
Keith Wells is a software engineer at IBM in Research Triangle Park, N.C. Mr. Wells has been involved with Emerging Technologies and the Emerging Technologies Toolkit for several years. Currently, he is exploring opportunities with compound documents, model-driven development, software standards, and XML-based technologies.
Kevin E. Kelly is an IBM senior technical staff member who works on software standards. Mr. Kelly has been a member of the W3C XForms Working Group and is chairman of the W3C Compound Document Formats Working Group. His focus is on developing open standards-based technologies for faster, more efficient standards adoption through XML-based and model-driven approaches.
Comments (Undergoing maintenance)





