Thursday, April 26, 2012

Form Runner gets a home page

For every form you create with Form Builder, after you deploy the form, Orbeon Forms exposes two pages:
  1. A new page, which end users go to to fill out the form. When a form is filled out and saved, it creates what we refer to as form data.
  2. A summary page, which lists all the saved form data for a given form. Depending on your workflow, access to this page is typically limited to admins or users in charge of processing the submitted form data.
Each one of those pages has its own URL. In a typical deployment, you would link to those pages from a site your users are accustomed to go to. For instance, a city might have a site with a description of the parks in the city, which contains a Reserve picknick area link, taking citizens to the new page of a form created with Form Builder.

There are cases, however, where it is useful to have a list of the deployed forms, without the need to add links to the new or summary pages from another site. And this is precisely what the new Form Runner home page does.

As you can see from the above screenshot, forms listed on the home page depend on the permissions you've been granted. For instance, you may be able to fill out a form, but not to see all the data saved for that form. Or maybe you don't have access at all to a given form, in which case it won't get listed. This permission system is new as well in Form Builder, and we'll cover it in more details in a future post here.

You can already experiment with the new home page today by downloading a nightly build. And this is just a start: we have big plans to improve this new Form Runner home page to make it even more useful.

Wednesday, April 18, 2012

XForms 2.0: goodbye nodeset

XForms 1.1 makes a distinction between two commonly-used attributes: ref and nodeset. Both are binding attributes, and they hold an XPath expression pointing to zero, one or more XML element or attribute nodes:

  • ref points to a single node ("single-node binding"). Its most frequent use is to bind a control such as xforms:input to XML data.
  • nodeset points to any number of nodes ("node-set binding"). This is used for example by xforms:repeat and xforms:itemset, which iterate over multiple nodes.
While working on the upcoming XForms 2.0 specification, which fully supports XPath 2.0, the XForms Working Group noticed a problem: node-set is terminology from XPath 1.0, and XPath 2.0 instead uses the more general notion of sequence. So keeping an attribute named nodeset in XForms 2.0 would be quirky!

The good news is that the solution is very simple, because it turns out that having two separate attributes is not necessary in the first place. So the Working Group has decided that XForms 2.0 will use ref everywhere and deprecate nodeset, keeping it around for backward compatibility only.

This has the additional benefits of simplifying the XForms syntax and removing a possible source of confusion for form author (e.g. which attribute should you use on xforms:bind?).

So get used to write:
<xforms:repeat  ref="foo">
<xforms:bind    ref="bar">
<xforms:itemset ref="baz">
<xforms:delete  ref="qux">
Another good news: Orbeon Form already supports "ref everywhere" since version 3.9, so feel free to drop good old nodeset!

Wednesday, April 11, 2012

Support for repeats lands in Form Builder

XForms has a rather powerful feature called repeats, which allows form authors to easily create forms with sets of fields that can occur multiple times. Repeats have always been supported by the XForms engine in Orbeon Forms, and now, they can also be used directly from Form Builder.

For instance, consider the "DMV 14" form, from the Department of Motor Vehicles in California, which allows you to list multiple vehicles. In the paper version of the DMV 14, the fields for a vehicle have been repeated 3 times, allowing a maximum of 3 vehicles to be entered. This is how things were on paper, and often today still with PDF, but with web forms, we can do much better: we can enable end users to add or remove vehicles, without even having to impose a limit on the number of vehicles users can enter. And of course, what works for vehicles, works for any set of fields you'd like to see repeated.

Imagine you want to create a conference registration form allowing an organization to suggest talks their members can give. For each talk, you'd like to know the presenter, the topic, and the date/time. In Form Builder, you create a repeat, by clicking on New Repeat on the side bar, (see screenshot to the right). You then create columns and add fields, as you normally would in grids. The following screenshot shows how this looks like in Form Builder.

When filling out the form, users add new lines as necessary clicking on the + sign.

Note how the label for the fields, instead of being repeated on each line, show just once in the table header. Such a table layout works well when you have a few fields repeated. But as the number of fields grows, you'll want to put them on multiple lines, and it will then be a block of lines that gets repeated. This is what we did in the following example, creating a total of 6 fields to be repeated:

Now note how, both in Form Builder (above) and when users fill out the form (below), the labels for the fields show above each fields, as having them just once in the table header wouldn't work anymore. And all this is automatically handled for you.

Repeats in Form Builder will be part of the next release of Orbeon Forms, and if you feel adventurous, you can try them today by downloading a nightly build.

Wednesday, April 4, 2012

Asynchronous submissions

You might not have heard about it, but XForms supports asynchronous submissions since version 1.1. In fact, XForms 1.1 even made the asynchronous behavior the default, probably because in the browser XMLHttpRequest is asynchronous. [1]

So what does it mean for an XForms submission to be asynchronous? Simply that sending the submission (with an action or the <submit> control) doesn't wait for the submission to be fully completed before returning. For example, consider:


And then this sequence of actions:
<send submission="save">
<setvalue ref="foo" value="42"/>
The <send> action starts the submission with an xforms-submit event, instance data is prepared, and then an HTTP request is started with that data as payload. "Soon" after, control returns to the action processing, and the <setvalue> action runs. The response from the submission may not have yet happened at that point. In fact, if the submission takes a long time (say, seconds or minutes), the submission will just be hanging there, waiting for a response. Once the response arrives, the submission result is processed.

With a synchronous submission, on the other hand, the <setvalue> action only runs once the response has arrived (or once an error has occurred). So the submission mode matters when you deal with XForms actions and events, and you have to be aware of the difference in processing between the two types of submissions.

There are useful practical uses to asynchronous submissions, including:
  • running background operations, for example autosaving data
  • reducing latency, for example loading initial data from multiple services concurrently
Background operations are good because they allow the user to continue working with the application while the operation completes. Reducing latency is good for the user because pages load faster.

Now since Orbeon Forms implements submissions on the server, you might wonder how this works! Orbeon Forms checks for pending asynchronous submissions at the end of page initialization and at the start and end of an Ajax request.

If page initialization or an Ajax request terminates and submission are still pending, the browser is instructed to poll the server from time to time, to check whether pending submissions have completed. Those which have are then handled appropriately.

You can find more details in the documentation on asynchronous submissions.

[1] Orbeon Forms has so far kept the default to synchronous for backward compatibility reasons.