Thursday, February 11, 2016
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
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
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
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
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)
Monday, November 16, 2015
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)
- Support for event('response-body') appears to be gone (#2336)
- portlet.xml for proxy-portlet uses <param-name> and <param-value> within <init-param> (#2418)
Thursday, October 22, 2015
We recently implemented two improvements to repeated grids and repeated sections, which appear as two new options in the “Sections/Grid Settings” dialog:
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
- the current number of controls in the form
Each new row gets the new values exactly once, and existing rows are left untouched:
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.
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:
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:
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.