Use HTML5 placeholders, in XForms

When a form is first shown to users, text fields are often empty. So why not use that space, to provide some useful information? For instance, the Yahoo! Registration page leverages this technique:

"First name" or "Last name", in this example, are often referred to as placeholders, and they disappear when you focus on the specific text field. You can get this behavior by implementing it in JavaScript, and in fact this has become quite popular in the last few years. So much so, that a placeholder attribute was been added in HTML5; this way, every web site wouldn't have to re-implement this behavior in JavaScript. This HTML5 feature is now supported by all the major browsers (Chrome, Firefox, Safari, Opera), except IE up to IE9 (IE10 is expected to support the placeholder attribute).

Placeholders are often used:

• Like a label, as in the above example. HTML5 warns against using placeholders as labels, as the information carried by the label won't be shown if the field isn't empty. So only use placeholders as labels in cases where, even if missing, there is little doubt as to the meaning of the fields. You can tell Orbeon Forms to show a label as a placeholder by setting an appearance="minimal" on the label, as in:
  
  <xforms:input ref="first-name">
      <xforms:label appearance="minimal">
          First name
      </xforms:label>
  </xforms:input>
  
• Like a hint, placing the appearance="minimal" on the hint, as in:
  
  <xforms:input ref="phone">
      <xforms:label>Phone number</xforms:label>
      <xforms:hint appearance="minimal">
          (555) 555-5555
      </xforms:label>
  </xforms:input>
  

When using a placeholder in XForms, if users access your form with a browser that:

• does supports HTML5 placeholders, Orbeon Forms leverages that native feature of the browser;
• does not support HTML5 placeholders, Orbeon Forms simulates it, with JavaScript.

This way, you as an XForms author don't have to write different code for different browsers, or worry about browser compatibility, and your end users get the same rich user experience, even on browsers that don't support this HTML5 feature.

The state of Orbeon Forms, Part 10.2

This is the second and last part of "The state of Orbeon Forms, Part 10", covering the changes that have taken place since the release of Orbeon Forms 3.9 (part 1 is available here). This time we focus on Form Builder and Form Runner improvements:

1. Form Builder
• Access control for deployed forms. When using Oracle and MySQL, Form Builder can now specify fine-grained role-based access control for deployed forms. This will have to be implemented for eXist as well.
• Services and actions in section templates. Form Builder services and actions now work within section templates. This is a long-requested feature! See also the section templates documentation.
• Conditional actions. The Form Builder Action Editor now supports Run always/Run on creation only. See also the Action Editor documentation.
• Grids withs more than 4 columns. Form Builder grids by default have a maximum of 4 columns. You can now optionally allow Form Builder to support more columns with a new property.
• "Save as". Form Builder now has a "Save As…" button to save a form definition as a new document.
2. Form Runner
• reCAPTCHA. reCAPTCHA is now integrated with Form Runner. See Stop spammers by adding a CAPTCHA to your forms.
• Improved persistence configuration. The main goal is to allow multiple SQL databases, each using its own datasource. See the compatibility notes.
• Excel import. Quickly import form data from an Excel spreadsheet. See Excel import in Form Runner.
• Required fields have an asterisk. See Styling required fields with a star.
• Improved Liferay support. Liferay support had been improved quite a bit for 3.9, and has improved even more since then. In particular, there is a new asynchronous portlet content loading mode which provides better performance with slower browser, and many bug fixes to both the full portlet and the Form Runner proxy portlet.
• XBL sections and grids. Form Runner sections and grids used to be implemented in XSLT, back when XBL support was not available. They have now been rewritten using XBL. See section.xbl and grid.xbl.
• Font embedding in PDF files. See the documentation.
• Third-party Alfresco persistence layer. See this blog post by Alexey, this presentation, and the source on github.
• MongoDB persistence layer. This is still experimental. We got a nice contribution to support form definitions and attachments. See the source.
3. Form Builder "next"
• Dynamic XForms architecture. The next version of Form Builder uses a different approach at edit time. See Dynamic XForms and a new grid editor for Form Builder "next". This is cool because it is a solid foundation for nested sections, repeats, tabs, and live XBL controls in the builder.
• New cell editor. A good part of the cell editor (in charge of editing a control's label and hint in particular) is now written in CoffeeScript on the client, the idea being to make it more responsive.
• Nested sections. Some support for nested sections is now in. See also Dealing with nested sections in Form Builder.
• Repeats. Support for repeats is partially implemented. Some rough edges still have to be handled.

As usual this does not include bug-fixes and other smaller improvements which you can follow on github.

Right now we are working hard on a couple of things, in particular:

• Event handling refactoring. There are some unfortunate bugs related to event handling, especially in relation with XBL, which are hard to fix at the moment. Now that Form Runner sections and grids are implemented in XBL, it has become important to fix those issues. So we are refactoring the code in charge of events to make things easier to maintain.
• Form Builder "next". This is the big piece! We are learning from our experience with Form Builder over the last few years and building on that for the next major release of Orbeon Forms. Things are starting to fall into place.

Enjoy,

-The Orbeon Team

The state of Orbeon Forms, Part 10.1

NOTE: Orbeon Forms 3.9 CE and PE were released in May 2011. This is a major release with lots of improvements. You might want to check what's new in that version first.

A lot has been going on since the last "The state of Orbeon Forms" post! This means that this new installment, covering improvements since Orbeon Forms 3.9, is in two parts. Here we focus on everything besides Form Builder and Form Runner:

1. Security, performance and reliability
• External XML DTDs. For security reasons, processing and loading of external DTDs when XML validation is turned off (which is in most cases) is disabled by default.
• Better XForms error handling. Some runtime errors are now handled better and allow the XForms engine to continue processing. See also More resilient error handling in XForms.
• Aggressive caching for all versioned resources. Until now, only JavaScript and CSS resources that were aggregated by the XForms server had aggressive caching settings. Now this is the case for any resources (typically JavaScript, CSS, images) that is versioned. This can lead to better performance if no further caching is implemented downstream (like by an Apache front-end).
2. XForms engine and components
• Native iPhone/iPad date and time widgets. This is pretty cool. See the blog post.
• Input "placeholder". This causes either the label or the hint to appear on the background of the field when it is empty. The native HTML 5 implementation is used when possible. See the documentation.
• New default button style. You know how buttons look different in every browser? We had a solution for this using the fr:button component based on YUI. Unfortunately this component uses JavaScript which causes some performance issues with older versions of IE. So we have now created a new CSS style for standard buttons which does not require Javascript. This is the default now for every standard button created with xforms:trigger. See also the documentation.
• Improved autocomplete. The autocomplete control is now simpler for end-users  and easier for form authors. See Improved Autocomplete.
• Improved xxf:valid() XPath function. This function has been updated to handle relevant nodes in the same way that xf:submission does. See the documentation.
• New xxf:custom-mip() function. This function allows you to retrieve the value of a custom Model Item Property (MIP). See the documentation.
3. XPL pipeline engine
• Multiple XSLT outputs. You can now use xsl:result-document and the output: scheme in an XSLT transform placed in a pipeline. This allows an XSLT transform to produce multiple resulting documents for further processing in the pipeline.
4. Architecture
• Scala and CoffeeScript. Most of the new server-side code is now written in Scala (using 2.9.1) and most of the new client-side code is written in CoffeeScript.
• Refactoring. Major refactoring of the XForms engine so-called static state has taken place to support dynamic XForms, a feature required for Form Builder "next". And more refactoring is on its way!
5. On the side
• XForms editorial meetings. Sub-groups in the XForms Working Group have met a few time to progress on XForms 2.0. In particular, we had a three-day meeting in Palo Alto, where good progress was made towards the XForms 2.0 spec.

This is for the important stuff, not counting numerous bug-fixes and other smaller improvements. If you are interested in the details, please follow the commits on github.

Part 2 will focus on Form Builder and Form Runner.

Enjoy,

-The Orbeon Team

Stop spammers by adding a CAPTCHA to your forms

If you're creating a form only accessible by members of your organization, chances are you're not worried about spammers. On the other hand, if your form is publicly available, and can be accessed anonymously, your form can easily become the target of spammers, hoping someone will read the content they submitted, or that this content will be published online, giving more weight to their site, through spamdexing.

Luckily, you can easily prevent spammers from exploiting your forms by adding a CAPTCHA. If you're writing your forms "by hand", in XForms, you can use the reCAPTCHA component. The component used the free reCAPTCHA service, provided by Google, and will show a challenge to your users filling the form, such as:

If you're creating your form with Form Builder, just enable CAPTCHAs for your form by setting the captcha-related properties, and Form Runner will take care of the rest for you, making sure that users entered a correct response before they can save or submit data.

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.

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.

Excel import in Form Runner

A pretty neat recent feature of Form Runner is the ability to import data from Excel files. In a few words this allows you to:

1. upload an Excel file with header and data rows
2. validate each row against the form's validation rules
3. import all valid data rows into the persistence layer

As a user you are in control at each step. For example, if your document contains invalid data, you might decide to cancel the import and review your Excel document.

The feature is documented on the Orbeon Forms wiki and is currently available in nightly builds of Orbeon Forms.

For the curious programmer, the implementation is pretty neat and makes use of:

• Orbeon Forms's XSLT/XPL support to extract the Excel workbook data
• asynchronous XForms service calls to validate and extract data in the background
• background XForms to validate and import the data
• XForms for the user interface

The source code for the feature is available on github.