Smarter Everyone, Smarter Everything, Smarter Everywhere

Aggregate Controls, Auto-tabbing and XForms

John M. Boyer 1,722 Views

Someone wrote me recently asking how they could aggregate a number of form controls together to achieve a common purpose.

Sidebar: It is legal to use the word they as a singular pronoun. And not just when the answer to the question he/she or s/he asked is applicable to a plurality of people, it can be used at any time to avoid those horrible slashing language kludges. Still, I have to admit it's easier on the ear when the answer applies to many.

Of course, the answer to the above question applies to many! I'll use the syntax of pure XForms as a pseudo-code for your visual experience in the Workplace Forms designer, where you can add whatever presentational beautification seems appropriate. So, let's say you want to aggregate the input controls to collect the parts of a phone number. Since forms are often written per locale, I'll focus on the North American format, since the same idea applies to other formats. The format consists of a 3 digit area code, a 3 digit exchange and a 4 digit local. So your instance data would look something like this:

<xforms:instance xmlns="" id="X">    <phone>        <areaCode/>        <exchange/>        <local/>    </phone></xforms:instance>

Now you'd hook up input controls to allow the user to enter data for each of these parts. We'll talk about the elided part of each control in a moment:

<xforms:input ref="areaCode" incremental="true" id="areaCode">    <xforms:label>Area Code</xforms:label>    ...</xforms:input>

<xforms:input ref="exchange" incremental="true" id="exchange">    <xforms:label>Exchange:</xforms:label>    ...</xforms:input>

<xforms:input ref="local" incremental="true" id="local">    <xforms:label>Local:</xforms:label>    ...</xforms:input>

The automatic tabbing feature begins with the incremental attribute. By default, an xforms:input allows the user to type any number of characters without changing the XML data to which the control is bound until the user indicates that the value should be committed (by hitting tab or changing the input focus). This is the false setting for incremental, which is the default. But if you set it to true, then the bound XML instance data node is changed on every keystroke.

Every time you change the data associated with an XForms form control, the control receives an xforms-value-changed event. This means that an XForms action can be created to listen for that event and perform a behavior when it happens. Like, say for example, change the focus if the user types 3 digits. In XForms 1.1, you will be able to write the area code input as follows:

<xforms:input ref="areaCode" incremental="true" id="areaCode">    <xforms:label>Area Code</xforms:label>    <xforms:setfocus ev:event="xforms-value-changed" control="exchange"                        if="string-length(.)=3 and . >= 0"/></xforms:input>

The ev:event attribute says that the xforms:setfocus action is a handler for the xforms-value-changed event. The form control to which the focus will be sent is the one with id="exchange", and this will occur only if the current context node contains three characters and evaluates to a number greater than or equal to zero. The current node is of course areaCode, and in XPath you signify the current node using a period, which is very familiar to many because it is the same notation as is used for the current directory on a file system.

OK, all of this is simple enough, but why did I use the future tense. The reason is that XForms 1.1 is a working draft. XForms 1.0 is the recommendation, so what can you do now. Well, for all of its elements, XForms 1.0 defines the "Common Attributes" bundle as including any foreign namespaced attributes. This was done to allow host languages (like XFDL for Workplace Forms) to be able to add their own enhancements in advance of the recommendations to meet pressing business needs and also to experiment with the best ways of adding new features to the XForms language. In this case, the need for conditional execution of an action is clearly needed, and it's pretty much a done deal that the if attribute will be in the XForms 1.1 when it becomes a recommendation. So, in Workplace Forms you can use the conditional attribute today, only it has to be in the XFDL namespace, so you would simply adjust the xforms:setfocus handler as follows:

<xforms:input ref="areaCode" incremental="true" id="areaCode">    <xforms:label>Area Code</xforms:label>    <xforms:setfocus ev:event="xforms-value-changed" control="exchange"                        xfdl:if="string-length(.)=3 and . >= 0"/></xforms:input>

That's all folks!

[Read More]

Workplace Forms Trial Versions Now Available

John M. Boyer 1,494 Views

Now you can get free access to the trial versions of IBM Workplace Forms software. The trial software includes the Eclipse-based visual design environment as well as the rich client viewer (a desktop application and web browser plugin). The suite includes a server component that delivers the form viewing and rich user experience with a zero footprint on the client (using the existing web browser only with no client-side install). However, the server product is not part of the trial software.

Workplace Forms supports development and deployment of XML forms and XForms-based XML forms in the following languages: Chinese Simplified, Chinese Traditional, Croatian, Czech, Danish, Dutch, English International, Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese Brazilian, Romanian, Russian, Slovakian, Slovenian, Spanish, Swedish, and Turkish.

One final note is that in order to get the trial software, you have to get an IBM developerworks ID. But that's free and easy to do, and the benefits immediately begin with access to the most powerful, advanced, pure XML electronic forms system on the market today.

[Read More]

XForms submissions: asynchronous and synchronous

John M. Boyer 1,623 Views

In the final day of the XForms face-to-face meeting today, we made great progress for XForms 1.1 defining synchronous or asynchronous submission.

A number of current implementations of XForms 1.0 perform instance data relevance pruning and validation followed by initiation of the data submission. The upload and download of octets occurs asynchronously, and when completed, the xforms-submit-done or xforms-submit-error is dispatched. However, the current recommendations for (DOM2) XML events and XForms actually describe a synchronous procession that starts with dispatching an xforms-submit through fives steps of default processing from relevance pruning and data validation all the way through to completion and dispatch of xforms-submit-done or xforms-submit-error.

A difference of behavior occurs when an action sequence contains a send action followed by other actions. If the submission is synchronous, then the form author can expect that the actions after the send are able to operate over the data returned by the submission. For an asynchronous implementation, the send action returns before the new data arrives.

In reality, form authors should put the follow-on actions after a send into a handler for the xforms-submit-done event, since actions over data should only be run if the submission succeeds. Still, what's a working group to do?

We'll be adding a new attribute, probably called mode and probably having the value synchronous or asynchronous, so that the form author can choose which behavior is best. The synchronous behavior will have other advantages like suspending user interaction with form controls, but the default will undoubtedly be asynchronous.

Meanwhile, XForms 1.0 authors, get into the habit now of putting actions that operate over submission response data into the xforms-submit-done handler, not after a send action.

[Read More]

An exciting day in an awesome week for Workplace Forms

John M. Boyer 1,718 Views

Since I couldn't put it better myself, let me quote from an email today from John Schumacher, our Development Director for Content Management Applications for Websphere Portal, Workplace and Domino:

"Please join me in congratulating the WorkPlace Forms team. This morning, on schedule, WorkPlace Forms 2.6 was made available for eGA on passport and is also available for download internally on Extreme Leverage!!!! I have already downloaded my copy. Keith MacKenzie and his team have done a tremendous job staying focused on the delivery of this major release ... The Forms products are now Internationalized to help support world wide sales, provides market leading support for the XForms standard which differentiates us from our proprietary competitors... and has aligned our development tool story with the rest of the IBM."

I am very pleased personally that we have been able to create the union of XForms, product globalization, and precision forms technology offered via the XFDL language. It is particularly satisfying this week since the IBM Victoria Software Lab is hosting the XForms face-to-face meeting starting tomorrow. It's always good news to see XForms implementers deriving power, efficiency and overall benefit from XForms, but being able to announce general availability on the first day of the face to face meeting you are hosting... cat to the cream!

And finally, this release and the completion of the XForms face-to-face will open up my ability to talk about more pointy bracketed things on this blog in the coming weeks :-)

[Read More]

The Notion of Document: XML, XForms, XFDL

John M. Boyer 1,464 Views

We usually think of a document as a file. A file is, at the operating system level, a unit of information. The OS can associate properties with it (like who can read it or write it), and the file can easily be moved from directory to directory or computer to computer with standard tools like FTP, email, or flash drive.

The XML recommendation defines a document as that which conforms to BNF rule #1 of the XML syntax. Of course it is useful if an XML document is the sole content of the unit of information being transferred, i.e. if the XML is the only thing in a file. This is because XML tools tend to be built with programming languages that expose services of the operating system.

However, the most important part of an XML document is capable of being contained within another document. In fact, XML canonicalization strips away the part of an XML document that would prevent the result from appearing as element content.

This is the idea that XForms uses when it expresses XML instance data within a larger document, and specifically within the <xforms:instance> element. Of course, the <xforms:instance> element can also reference a whole XML document using the src attribute, but in both cases, the result is parsed into the live running instance data. The user interacts with the XML data document, and the XML data document is what is returned to the server by an <xforms:submission>.

This paradigm works well enough if you think of a form as an ephemeral view of a back-end database or content repository. However, people find it easier to work with a document in the file sense of the word. we like to save our document, email it, reload it the next day or on a new computer, and especially on a computer that has become disconnected from the net or from the original web application context that would be associated with the ephemeral view kind of form.

Enter the document-centric approach of Workplace Forms, the technological basis of which is an XML document whose element names belong to the XFDL and XForms vocabularies. Moreover, the underlying XML data document is still incorporated by the <xforms:instance> just like all other XForms-based documents.

A key difference is that being a document implies that the form with eventually have to be re-serialized, e.g. to save or sign the form. XForms doesn't really talk about how to reintegrate the live, modified XML data back into the document, but in truth it's really not that hard. The main technical hiccup on the XForms side is that the src attribute takes precedence over the content of <xforms:instance>, so when the live data is synchronized back into the form, the src attribute has to be eliminated.

The conclusion, though, is that a Workplace Form, or XFDL document, is a cross between an office document and an mobile intelligent agent. It can be saved, reloaded, printed, emailed, archived, signed, submitted to web application and portal servers, and participate in document management, records management and content repository processes. This is how the notion of document makes a form be more than just an ephemeral view of data.

[Read More]

Feed for Blog Entries ▼ Feed for Blog Comments ▼

Blogs