Thursday, February 11, 2016

Required fields: more subtle than you might think

In forms parlance, a required field is a field which must contain a value, or else the form will show an error and you won't be able to save it or submit it. This is a pretty fundamental idea, and both XForms and HTML5 even include a way to mark a field as required. Orbeon Forms is no exception and has had support for required fields since the beginning, including in Form Builder.

But what does it mean to contain a value in the context of web forms? Say you enter a few spaces in the field: does this pass validation? Unfortunately, with both XForms and HTML5, the answer is yes, because their definition of a required field is just a field whose value is not the empty string! You might even remember seeing online forms which you can trick into submission (pun intended) by entering a space, or maybe even some fancy Unicode characters, into a required field.

We realized a long time ago that this definition of required was just plain wrong, because in the vast majority of cases the form author really means that the field must contain some non-blank value when the field is required. Providing a few spaces for your name just won't do!

With Orbeon Forms, you can work around the issue by adding a validation formula such as normalize-space() != ''. But this is a bit heavy and we figured that we would address this better in the next release of Orbeon Forms.

We first thought about changing the meaning of required to mean non-blank, or at least to provide that option to the user. But then we realized that most fields do not need to contain leading or trailing spaces. If we were to introduce trimming of leading or trailing spaces for text fields, then the value of a field containing only spaces would automatically become an empty string, and the current notion of requiredness could survive!

So that's exactly what we did. We implemented an option to trim whitespace deep down in our XForms processing engine, and also exposed it nicely to Form Builder. By default, new text and email fields added to a form have leading and trailing space trimming enabled (existing fields are not changed). Further, you can control any field's trimming with the new "Trim leaving and trailing spaces" option in the Control Settings dialog.

When a text field has trimming enabled, its value is automatically adjusted when the field loses focus, such as when you navigate to the next field. If a field contains only spaces, it becomes empty at that time, and shows an error if required.

While we were at it, we made sure that the notion of "space" was inclusive rather than exclusive: we remove not only the ASCII space character, but tabs, any Unicode space characters, zero-length spaces, non-breakable spaces, and even ISO control characters.

We hope you will like this feature, which will be available in Orbeon Forms 4.11.

Wednesday, January 20, 2016

Removing the "double" datatype

A while back, we explained how and why we greatly simplified the list of data types in Form Builder, and we wrote:
We have reflected this in Form Builder by putting the decimal type at the top and the double type at the bottom, and we might even remove it altogether in the future.
Lately, as we were working on improvements to the Number field, we gave a bit more thought to the "double" type (AKA "double-precision floating point") and have decided that it was finally time to remove it from the data type list as well! So here is the new list:

For compatibility reasons, the list still shows "Double-precision floating point" for existing controls with that data type, but not otherwise. So the "double" data type keeps working as it did in the past, but form authors are strongly discouraged from creating new controls with it.

If you are using the "double" data type, we recommend that you think about whether you really need it. In general you should use the "decimal" type instead. One thing is certain: don't use doubles to represent currency amounts!

This change will be available in Orbeon Forms 4.11.

Wednesday, January 13, 2016

Better numeric input on mobile

Orbeon Forms has a Number field which allows you to enter integer or decimal numbers, but until now this field didn't particularly help users enter numbers efficiently on a smartphone or tablet without a physical keyboard.

But we thought we could do better, since iOS has the ability to show a numeric keypad when only the digits 0 to 9 are allowed, and, alternatively, to show the "numbers and punctuation" keyboard pane if digits are expected but other characters are needed as well (such as a decimal point). This is available even to mobile web apps, so the Number fields now does some magic and toggles these keyboards as needed!

When we know that the number field only accepts non-negative integer numbers, we show the numeric keypad:

In other cases, we show the "numbers and punctuation" keyboard pane:

There is a little trick: how do we know whether the number is restricted to integers, or cannot be negative? Until now we couldn't express these constraints nicely, but we have now added new common constraints called "Positive or Zero" and "Maximum Fractional Digits":

These common constraints not only help toggle the proper keyboard, but also, of course, validate the data appropriately.

It turns out that the implementation was not as simple as you might think, but we figured it out so you don't have to and now you can have much more efficient numeric input on mobile devices!

This enhancement will be available in Orbeon Forms 4.11.

Wednesday, December 9, 2015

Leaner repeated sections and grids

Orbeon Forms's repeated sections and grids are powerful. For example they support adding, inserting, removing, and moving repeated content freely.

But in some cases, users can prefer a simpler interface without all the bells and whistles. So repeated sections and repeated grids now support a minimal appearance, which you can enable via properties for all forms or for specific forms. It's entirely opt-in.

Compare the default appearance of a single-line repeated grid:

with the new minimal appearance:

You notice that the minimal appearance doesn't include the row dropdown menus, that the grid lines are missing, and that you simply have Add/Remove links at the bottom.

For more details, see the documentation. This feature will be available in the next major version of Orbeon Forms and we hope you'll like it!

Wednesday, December 2, 2015

Orbeon Forms 4.10.2

Today we released Orbeon Forms 4.10.2 PE. This update to Orbeon Forms 4.10 PE and Orbeon Forms 4.10.1 PE contains bug-fixes and is recommended for all Orbeon Forms 4.10 PE users.

Specifically, this release addresses the following issues on top of those addressed in 4.10.1:
  • Form Builder
    • Repeated fr:grid migration to 4.10 doesn't migrate templates (#2440)
    • Repeated fr:grid migration doesn't handle zero iteration case (#2441)
  • Form Runner
    • Server incorrectly setting back focus on XBL control (#2433)
You can download the latest version of Orbeon Forms from the downloads page.
    Don't forget to grab a trial license for the PE version.

    Please send feedback:
    We hope you enjoy this release!

    Monday, November 16, 2015

    Orbeon Forms 4.10.1

    Today we released Orbeon Forms 4.10.1 PE. This update to Orbeon Forms 4.10 PE contains bug-fixes and is recommended for all Orbeon Forms 4.10 PE users.

    Specifically, this release addresses the following issues:
    • Form Runner
      • Infinite loop with focus events on number control (#2387)
      • Explicit commit/rollback for CRUD operations (#2430)
      • PDF Template does not display drop down controls (#2331)
      • PDF template: image appears on all pages (#2334)
      • FR Home: layout issue in table header (#2369)
      • Icons not centered vertically in landscape mode on iOS (#2361)
    • XForms
      • Support for event('response-body') appears to be gone (#2336)
      • JavaScript API: getValue/setValue must take optional form (#2382)
    • Other
      • portlet.xml for proxy-portlet uses <param-name> and <param-value> within <init-param> (#2418)
    You can download the latest version of Orbeon Forms from the downloads page.
      Don't forget to grab a trial license for the PE version.

      Please send feedback:
      We hope you enjoy this release!

      Thursday, October 22, 2015

      Repeated grids and sections just got more subtle

      We recently implemented two improvements to repeated grids and repeated sections, which appear as two new options in the “Sections/Grid Settings” dialog:

      The Sections/Grid Settings dialog
      The Sections/Grid Settings dialog

      Initial values

      The new “Apply Initial Value Formulas when Adding Iterations” option specifies whether the “Initial Value” formulas apply to new fields when you add a new row to a repeated grid or a new section repetition to a repeated section.

      As a reminder, the “Initial Value” formula applies only once to new form data, unlike the “Calculated Value” formula which applies to new form data but also any time anything changes in form data.

      Previously, the “Initial Value” formula would apply to initial iterations in a repeated grid or section when the form loaded, but not to new iterations added by the user while filling out the form.

      With this new option, you have a choice to keep things as they were, or to allow Form Runner to apply the “Initial Value” formulas to newly-added iterations, which we think is what most users would want.

      Here is an example showing how, with the option enabled, new iterations can have dynamic initial values. As the user adds rows, the following formulas apply to the fields in that new row:

      • a constant value, “42”
      • the date and time at which the new row got added (using the current-dateTime() formula)
      • the current number of controls in the form

      Each new row gets the new values exactly once, and existing rows are left untouched:

      Initial values as iterations are added
      Initial values as iterations are added

      Number of initial iterations

      The new “Initial Number of Iterations Uses Template” option specifies, when an enclosing repeated section creates a new iteration, how many iterations the enclosed repeated grid or section will contains:

      • when enabled: the number of iterations shown in Form Builder (which can be no iterations at all, one iteration, two iterations, etc.)
      • when disabled: exactly one iteration

      The following screenshot shows a case with a repeated grid within nested repeated sections. At first, when the form shows, there are two iterations of the repeated grid.

      Initial iterations when the form loads
      Initial iterations when the form loads

      With the option enabled on the grid, adding a new iteration of Repeated section 2 causes the new iteration to contain a new repeated grid with two iterations:

      Number of initial iterations coming from the template
      Number of initial iterations coming from the template

      While, with the option disabled on the grid, adding a new iteration of Repeated section 2 causes the new iteration to contain a new repeated grid a single iterations:

      One initial iteration only
      One initial iteration only

      These two options are enabled by default for new forms and new repeated grids and sections. They are disabled by default for grids and sections created with previous versions of Orbeon Forms. So if you have existing forms and want the new behavior for some or all repeated grids/sections, you need to open these forms in Form Builder and enable the relevant options.

      These improvements will be available in Orbeon Forms 4.11.