XForms Everywhere

As a reminder, there will be a free XForms Evening this Monday at the XML 2007 conference in Boston, and I will be presenting a talk about XForms and eXist. There are several great speakers scheduled and this is a great opportunity to learn about XForms, so don’t miss it! I hope to see you there!

See also our previous blog entry on the topic for all the details.

Yesterday, I was filling-out an application form on the E*TRADE web site.

So here I go, entering my information in a traditional wizard-like workflow, with page reloads et al. When I get to the end of it (about six or seven pages total), I figure I would check if I could amend my mailing address on page two. So I carefully press the “Previous” button of the wizard, until I reach the page. So far so good, my information is still there (even though it turns out I can’t change this particular bit). This is the beginning of the trouble:

• First issue: there is no way to complete the workflow from page two, even though I have completed all parts of the wizard. I have to press the “Next” button again and go through the remaining pages all the way to the end.

• Second issue: as I am doing so, part of the information I had just entered is not restored at all. It had displayed just fine as I was navigating back in the wizard, but now that I am navigating forward, it is missing and I have to re-enter it!

• Third issue: finally getting to the end of the wizard again, I complete my workflow and reach a summary page. That page has buttons to edit particular parts of the information. I click on one of those as a last attempt to change my mailing address. This takes me to page two again, just to find out that no, I really can’t change it. This time, there is no way to just go back to the summary page. I have to go forward in the wizard again. And as I do so… guess what: the information that was missing during my first attempt is missing again. So there I go, filling-out bits of information a third time.

Now you can easily imagine how the software got to be so buggy: written with software tools not particularly designed to handle forms, developers had to write by hand things such as “when the user goes to page two from page three, restore such and such information from the session”. Somebody forgot to write the code that restores a particular piece of data, and lousy QA missed it. (Needless to say, there were not many usability tests on this wizard either.)

Now imagine the next version of this form if E*TRADE developers decide to use XForms and Orbeon Forms instead:

• The information gathered by the wizard is constantly kept in one or several XForms instances. The XForms engine takes care of keeping this around and not losing it.

• It is easy to check whether all the required information is entered correctly at any point in the wizard. This allows you to exit the workflow to the summary page from anywhere after you have amended information.

• You can easily provide multiple views of the same information, including the editable wizard view, and the read-only summary view: they both share the same underlying XML data representation.

• The wizard is automatically Ajax-enabled, with as-you-type validation, providing a much more pleasant user experience.

And of course, users are much happier because they enter their information once, not three times.

We have just posted a release candidate for Orbeon Forms 3.6. Orbeon Forms 3.6 now contains over 170 improvements over Orbeon Forms 3.5.1.

The idea behind the release candidate is to see if anything is obviously broken before we release 3.6 final. It does not mean that Orbeon Forms is bug-free, mind you there are lots of known issues and requests for enhancements in Orbeon Forms.

If you have a chance, please give this build a try and send feedback to the ops-users mailing-list!

When a form field is loosing the focus, the browser is supposed to send two events: blur and change. The latter is only sent if the you have changed the value of the field. When you change the value of a first field and tab to a second field, all the browsers get the events right. But if you change the value of a first field, alt-tab to another application, alt-tab back to the browser, and tab to the second field, then different browsers implement different behaviors:

• IE 7 implements this “correctly”, i.e. as if the alt-tabs between the browser and the other application were not there.
• Firefox 2 on Windows sends a change event when you alt-tab away from Firefox, and then doesn’t send the change event when you tab to the second field. This is not what I would expect, but it isn’t terribly incorrect either.
• Firefox 2 on Mac never sends the change event. That is just plain wrong.

If you are using XForms to define your forms and running them through Orbeon Forms you won’t have to deal with any of this. Orbeon Forms will do the hard work for you. Lucky you! ;)

Over the last two weeks, we fixed a series of bugs that we considered blockers for Orbeon Forms 3.6:

• Error when using browser back button when using xforms:instance[@src = ‘input:*’]
  
• Label is not hidden when repeat iteration is added
  
• Inspector does not show initial XML (in some cases)
  
• Issue with adjacent itemsets
  
• Google Suggests example doesn’t work anymore
  
• XPL, XQuery, XSLT, XPath and XUpdate sandboxes don’t show results anymore
  
• Logout example: still shows the page as if logged in after logging out
  

We have one remaining JavaScript bug which we consider a blocker, and then we should be able to officially proceed to an RC build!

A really cool thing about Orbeon Forms is that it automatically handles your browser’s back and forward buttons.

What are we talking about here? Browser back and forward buttons should just work, right? Well, not quite, at least not with web applications that dynamically modify the HTML page.

What happens when you navigate back and forth in your browser history (typically with back and forward buttons) is that the browser attempts to reload the page (if possible from a local cache, following the usual HTTP caching mechanisms). It also restores form field values. But one thing it doesn’t do all the time is restore the DOM as it was when you left the page. Opera, Firefox and Safari attempt to handle this in some cases, but not all. IE doesn’t even try. This means you can’t trust browsers to do the right thing.

Changes to the DOM happen very often with Orbeon Forms: when you make a field invalid, hide or show parts of the page, insert new rows of data, show a dialog, etc.

So Orbeon Forms tries to be smart: when you navigate the browser history to an Orbeon Forms page, if the browser doesn’t restore the DOM itself, Orbeon Forms discretely talks to the Ajax server to ask it to send back a list of changes which, when applied to the page, would restore its appearance as you last saw it.

A nice thing is that we can do this at little cost because, as part of the regular XForms processing, we already:

• produce and store a serialized, encoded version of the state of the page, and

• use a difference engine to compute changes to apply to the page in your web browser

The news is that we made some enhancements to this feature:

• We fixed a long-standing bug, whereby going back to a page which loaded instance data using <xforms:instance src="input:data"/> or <xforms:instance src="input:instance"/> would throw an exception, because the XForms engine was unable to reload these instances.

• At the same time, we now make sure that all instances loaded during XForms initialization, whether with <xforms:instance src="..."/> or with a submission upon xforms-ready, are restored as they were initially (rather than by loading them again or executing submissions again).

• Finally, the recent addition of a disk-based cache makes the feature much more robust: as long as your session is alive, the initial state of the page will be found.

As a side note, this should finally allow us to implement <xforms:reset> correctly.