Interactive Web Services with XForms
by Micah Dubinko
|
Pages: 1, 2
XForms in Two Easy Steps
Form authoring can be thought of as a two step process: first, create the underlying form definition, called the "XForms Model"; second, create the user interface mapped the the XForms Model. A huge benefit of this design is that existing XML and Schema resources can be directly used with forms.
Step one is to create the XForms Model. In an XHTML containing document,
this goes in the head section:
<xforms:model> <xforms:instance xlink:href="http://www.example.com/getInstance"/> <xforms:schema xlink:href="CCInfo-Schema.xsd"/> <xforms:submitInfo action="http://www.example.com/submitInstance"/> </xforms:model>
As short as this is, it defines a complete form, though without any means
for user interaction (that's the next step). The XForms Processor looks at the
initial instance data and constraints found in the XML Schema to initialize
the XForms Model. A submitInfo section gives directions (all
defaulted here) for writing out the submitted instance data and then where to
submit it.
Step two is to attach a user interface, keeping in mind the range of
possible target devices (desktop browsers, cell phones, voice browsers, paper,
and so on). In an XHTML containing document, this goes in the
body section:
<xforms:output ref="i:FullName"/>
<xforms:selectOne ref="i:CardType" selectUI="radioGroup">
<xforms:caption>Card Type</xforms:caption>
<xforms:choices>
<xforms:item>
<xforms:caption>MasterCard</xform:caption>
<xforms:value>MC</xforms:value>
</xforms:item>
<xforms:item>
<xforms:caption>Visa</xforms:caption>
<xforms:value>V</xforms:value>
</xforms:item>
</xforms:choices>
</xforms:selectOne>
<xforms:secret ref="i:Number">
<xforms:caption>Card Number</xforms:caption>
</xforms:secret>
<xforms:input ref="i:Exp">
<xforms:caption>Expiration Date</xforms:caption>
</xforms:input>
(Complete XHTML+XForms document)
Here there are four form controls defined:
- An
<output>form control to display (but disallow changing) the User's full name. - A
<selectOne>form control to choose the card type from a list. A user interface hint is included to treat it like a radio button group. - A
<secret>form control (bound to anxsd:decimaldatatype from the Schema) to allow the entry of a credit card number without rendering the digits as they are typed. - An
<input>form control (bound to anxsd:gYearMonthfrom the Schema) to allow the entry of the expiration date.
The ref attributes on each form control, which contain XPath
location paths, serve as a connection between the form controls and a data
location in the instance data.
Compared to the XHTML discussed earlier, getting XML data in and out of forms is cleaner and simpler. And a new set of form controls provides greater functionality across a wider set of devices of all shapes and sizes. Form building is generally an iterative process. From this foundation, additional constraints, validations, and usability enhancements can be added.
Conclusion
|
Related Reading XML in a Nutshell |
Since its inception the Web developed as a rich source of information trapped in a format meant primarily for human consumption. This led to a raft of retyping, screen-scraping, and poorly integrated applications. Recently, the focus has shifted towards automatically discoverable, self-describing modular applications. XForms technology is the bridge between these two worlds.
Authoring XForms is simple, taking only two steps, and you can reuse Schemas and instance data already available in a web services environment.
The main issue at this point is the lack of conforming XForms Processors with which to utilize forms on the client side. The XForms specification is still a moving target, still in the "Working Draft" phase. The XForms Working Group is actively seeking feedback and implementation experience. In the short term, server-side tools that transform XForms into browser-digestable HTML are a good solution. Looking farther out, next-generation networked devices are lining up support for XForms. Who knows, maybe even someday browsers will support XForms.
In the end, information for, from, and about people is what's interesting. New tools on the horizon make this easier than ever.
Got ideas or experience with adding user interfaces to web services, or comments on XForms? Share them in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- Modulairzing XHTML 2.0 doc and XForms
2003-07-03 06:20:08 John Sasso [Reply]
I have a master XHTML 2.0 doc (master.html) that I'd like to modularize such that it embeds 4 sub-docs via HLinks, all of which are XHTML 2.0, e.g.
<head>
<hlink:hlink namespace="http://www.acme.org/work"
element="doc1" locator="@dlink" effect="embed" actuate="onLoad"
onSuccess="processChildren" onFailure="fail" />
<hlink:hlink namespace="http://www.acme.org/work"
element="doc2" locator="@dlink" effect="embed" actuate="onLoad"
onSuccess="processChildren" onFailure="fail" />
...
</head>
<body>
...
<h2> Data Input: </h2> <br/>
<doc1 dlink="/docs/input_form.html" />
<p/>
<h2> Data Output: </h2> <br/>
<doc2 dlink="/docs/output_form.html" />
<p/>
....
</body>
The sub-docs are forms implemented w/ XForms. The reason for the modularity is for reuse, i.e., there will be a good number of such master docs that may include some/all of the sub-docs, so if I want to change the style of the input form, I can just modify the single sub-doc (input_form.html) instead of every single master doc. (BTW, if there is a better way to achieve this modularity aside from HLinks, I'd like to know)
PROBLEM: My understanding is that XForms requires an <xforms:model> section in a doc's <head>, to describe what the forms do. If I have to do this in the master doc, this ends up defeating the intention of modularity I am trying to achieve. I'd prefer to have such descriptive sections in the sub-docs themselves.
Any advice to help me out of this dilemma?
---john
