Tuesday, July 5, 2011

Improved Autocomplete

We recently made a couple of major improvements to the autocomplete control that comes with Orbeon Forms.

First, we wanted the autocomplete to be simpler for end-users. For the longest time, the autocomplete had the ability to display a show all button to the right of the text field. When users click on that button, all the items (or rather, to be precise, the first n items, where n is configurable) were displayed. This is great for those cases where users don't quite know what they are supposed to type in the text field. We used to have two lists: one showing all the items below the button, and one showing suggestions as you type below the text field. Those two lists have now been unified. The one remaining list provides suggestions as you type, and if you click on the button to the right of an empty field, it shows you all the items.

Second, we wanted to make the autocomplete easier for form authors. We used to have two ways to use the autocomplete. One was to provide the autocomplete with the full list of items, referred to as static mode. From an API perspective, this makes the autocomplete as simple to use as a drop-down, a list, or other selection control. This requires you to have all items in memory on the server, which works if you have, say, a hundred or even a thousand items. What what if your autocomplete allows you to select a product or a book from a collection with millions of items? For that case, the autocomplete provided a lower level, event-based API: the dynamic mode. Several organizations have used the dynamic mode successfully, but it was complicated. So we introduced a third option, referred to as resource mode. In resource mode, you provide the autocomplete with the URL of a service returning a subset of the data in XML format. As users interact with the field, the autocomplete automatically calls your service, providing the text users typed so far as a request parameter, and showing the data returned by your service in the suggestions list.

Bonus: watch the autocomplete automated unit tests as they run, here in Safari (and to see the screen better, you might want to put the video in full screen).

Friday, July 1, 2011

Dynamic XForms and a new grid editor for Form Builder "next"

Until now, the Form Builder grid worked as an "interpreter" of XForms documents. In each grid cell, Form Builder had a big "switch" containing all of the built-in XForms controls, only one of which would be enabled at a time.

For example, if you placed an xforms:input field into a grid cell, Form Builder would enable its xforms:input alternative, and disable all the other controls (xforms:select, xforms:textarea, etc.) in the cell.

This approach has a number of issues:

  • Each control type you want to support in a WYSIWYG way has to be known by Form Builder in advance.
  • Form Builder becomes more complex as more control types need to be supported and simulated. This is particularly hard for XBL controls.
  • The size of the Form Builder HTML increases greatly with each new control you add.

So there is a tradeoff between keeping Form Builder simple and efficient, and supporting more control types, including XBL controls.

For the next version of Form Builder, which will support a host of new features such as repeats, tab views, and nested sections, we figured that this approach had to be revised, and we realized that we should just let the XForms engine interpret the form as it is being created in Form Builder!

This simplifies the architecture of Form Builder greatly and allows it to support any XBL control without extra work, as well as facilitating the support of repeats and other features.

So yesterday we have committed changes to XForms engine that we have been working on for quite some time. These changes allow the XForms engine to dynamically evaluate and update a sub-form, via an extension called xxforms:dynamic.

The next version of Form Builder, under development, uses xxforms:dynamic to point to an XForms instance containing the form being edited. As the user builds the form through Form Builder, the XForms engine automatically reflects the changes. Form Builder itself can just relax!