Tuesday, November 22, 2011

Orbeon Forms now using native iPhone/iPad date and time widgets, and more

With mobile browsing on the rise, we set out to better support mobile devices in Orbeon Forms. We are particularly focused on tablets, as the larger real estate provided by those devices makes them more suitable than phone to fill out forms. And for now, we are doing most of our testing on iOS, since, as of this writing, Apple is dominating the tablet market, even though we wouldn't be surprised to see Apple's lead erode given Android overall success in the mobile space.

Over the last few months, we addressed a few smaller cosmetic issues, for instance to leverage iOS 5 native style momentum scrolling in text areas, or improving the look and usability of the selection control using the menu appearance. In the last few days, we implemented the support for the native iOS date and time widgets.



And this is just a beginning: we have more improvements targeted at mobile browsers in the pipeline.

Thursday, November 17, 2011

More resilient error handling in XForms

What should your application do when a error occurs?

One approach is to let the application crash and burn (errors are not supposed to happen, right?). This behavior remains typical of many "native" (C/Objective-C/C++) desktop and mobile applications. Your only hope is that the app has some kind of autosave feature, or you have lost your work.

On the other hand, some applications are more resilient. For example, Java-based apps like the IntelliJ IDE nicely warn you that something wrong occurred but try their best to stay up. Some web applications also try to recover from JavaScript errors. More often that not the error is not fatal, your data is not lost, and you can even continue working as if nothing had happened. This is made easier with languages that use exception handling.

Now the XForms spec takes kind of a tough stance on this. For certain errors (like referring to the wrong model or bind by id, or an error in an XPath expression), the expected behavior is to "halt processing", and this is not even cancelable by the application author.

This behavior is perfectly fine if those errors are found as the app is initializing: in that case, you haven't had a chance to interact with the app and enter data, so typically nothing is lost.

But if those errors occur later, after you have already spent minutes typing in information, the "crash and burn" approach is going to be a source of frustration.

To alleviate this, an "autosave" feature is a great option, and we hope to add this to Form Runner in the future. But what else can be done? Well, break out of the XForms requirement to halt processing is one thing.

And that's exactly what we have done recently: Orbeon Forms now has the ability to recover from many runtime errors. Recovery has a few aspects:

  1. Defaulting to default values. Example: a control binding using an XPath expression failing at runtime binds to the XPath empty sequence, in effect making the control hidden.
  2. Not producing any result at all. Example: a value calculated using an XPath expression failing at runtime is ignored.
  3. Interrupting processing locally. Example: an action encountering an error stops, but further events and user actions are allowed to proceed.

In all those cases, errors are logged so the developer can be informed and take action. By default, the user also sees an error dialog, which can be dismissed so that further actions, such as saving data, can be attempted.

We think that this change is good for both users and programmers, and we hope that XForms 2 will standardize some of this behavior.

For more details, see the documentation for this feature.