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.

    Monday, August 31, 2015

    Responsive design

    When you create a form, Form Builder encourages you to layout fields using multiple columns. This gives you more flexibility in:
    • grouping fields in a logic way;
    • making better use of the space available on the page.

    This works well on well on laptops, desktops, and tablets, but not so well on mobile phones. In general, you just don't want your fields to be shown in multiple columns on mobiles, as this will require users to scroll horizontally to see fields "to the left of the page", thus greatly reducing usability.

    This is why, starting with version 4.10, your multi-column forms will automatically show in 1 column when accessed from a mobile phone, or any device with narrow screen.

    This is done automatically for you, using an approach referred to as responsive web design. If you're upgrading from Orbeon Forms 4.9 or earlier, you'll get this out-of-the-box: you don't need to change anything in in your forms, or set any configuration setting.

    For more, see our documentation on responsive design.

    Wednesday, August 26, 2015

    Orbeon Forms 4.10

    Today we released Orbeon Forms 4.10! The main user-visible feature is the introduction of responsive design for mobile devices such as smartphones. Form Builder also gets some nice enhancements.

    Major features and enhancements
    • Form Builder
      • Control appearance switcher. Form Builder now features a general-purpose mechanism to switch between control appearances: this allows for example switching between a dropdown menu and radio buttons, adding a character counter to your fields, and more, with just one click! (blogdoc)
      • Maximum and minimum length validations. This release introduces the notion of common constraints. These are validation constraints which can be enabled via the Form Builder user interface without writing formulas by hand. As a first step, we introduce maximum length and minimum length constraints. (blogdoc)
      • Integration. You can now open the Form Builder "New" page with URL parameters which skip the initial dialog. (doc)
    • Form Runner
      • Responsive design for mobile. The Form Runner detail page now features a single-column layout on smaller devices. This also supports the Wizard view. (blogdoc)
      • Accessibility improvements. Output fields use HTML labels. (#1243)
      • Option to show a "character counter" next to a field. This new option for input fields, password fields and text areas displays a character counter next to the field, showing the current number of characters, or, if a maximum length is set, the number of remaining or extra characters. (docblog)
      • Section templates fixes. 
        • Fix execution of actions upon section templates load. (#2233)
        • Fix sending of email recipients, subjects and attachments in section templates (#2016)
      • Form Runner Home page.
        • Don't ask user for credentials more than once. (#2276)
        • Fix refresh of remote server  data when more than one remote server is configured. (#2274)
    • XForms
      • New validation functions. There are two new functions: xxf:max-length() and xxf:min-length(). (doc)

    See Localizing Orbeon Forms for the latest localization support. Localization depends on volunteers, so please let us know if you want to help!

    Other new features and bug-fixes

    Including the major features and enhancements above, we closed over 60 issues since Orbeon Forms 4.9.
      Current browser support
      • Form Builder (creating forms)
        • Chrome 44 (latest stable version) and Chrome 46 dev (current dev channel)
        • Firefox 40 (latest  stable version) and the current Firefox ESR
        • IE 11
        • Safari 8
        • Form Runner (accessing form)
          • All browsers supported by Form Builder (see above)
          • IE8, IE9 and IE10
          • Safari Mobile on iOS 7 and iOS 8
          • Chrome for Android (stable channel)
        Compatibility notes
        • XBL event handlers.
          • Until this version, it was possible for event handlers to listen for events on a different XBL scope. This was not desirable and is removed in this version. Custom XBL components which rely on this will need to be updated. (#243)
        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!

          Wednesday, August 12, 2015

          A dangerous Java 7 JVM option: TieredCompilation

          A while back, we had a customer with a production server exhibiting a curious problem: performance would start well after an application server restart, but over a few days, and sometimes over a single day under heavy load, response times would become longer, until the system would become unresponsive.

          Over weeks we analyzed logs files, trying to figure out whether there were unusual patterns in the user requests. We also connected monitoring tools and a profiler to the production system in order to see whether the VM was running out of memory or other resources.

          Unfortunately, in spite of a number of false leads, we could not figure out anything conclusive. It was as if the system just became slower for no good reason!

          Luckily, after a good deal of additional Googling, we figured out that the culprit was JBoss, or rather, a combination of a particular version of JBoss (JBoss AS 7.1.1.Final) and a particular version of the Java virtual machine (Java 7). [1]

          This version of JBoss forces the -XX:+TieredCompilation VM option behind the scene, and this option is the direct cause of the problem. It is supposed to improve performance, but turns out to have a very serious adverse effect instead. [2]

          Practically, the issue is solved very easily by setting PRESERVE_JAVA_OPTS=true in standalone.conf.

          Clearly, it was wrong of JBoss to set this option by default, and it seems that this was reverted in subsequent versions of the application server. But many organizations are still using JBoss AS 7.1.1.Final, even though it is more than three years old now, and we hope that this post will be useful to somebody else.

          1. Here are some useful links on this issue:  ↩

          2. This option is activated by default with Java 8, and it might be that Java 8 fixes the issues associated with it, but we haven’t tested that.  ↩

          Thursday, July 16, 2015

          How Common Constraints Work

          Form Builder allows you to configure several types of validations associated with form controls:

          • Required: whether the value can be empty or not.
          • Datatype: such as string, decimal, date, or time.
          • Formulas: custom formulas, expressed in XPath.

          In Orbeon Forms 4.10, we are introducing the additional notion of common constraints. These are validations which are predefined by Form Builder and which you can just select with a dropdown menu.

          There are currently two such constraints:

          • “Has Maximum Length”
          • “Has Minimum Length”

          Where you could only choose “Formula” in addition to the preset “Required” and “Datatype” validations, you can now select one of the common constraints.

          Choice of common constraints
          Choice of common constraints

          Each of these two common constraints takes a numeric parameter specifying respectively the maximum number of characters and the minimum number of characters allowed in the field.

          Setting values for common constraints
          Setting values for common constraints

          These constraints are equivalent to the following formulas:

          string-length(.) le 140
          string-length(.) ge 10

          But in fact, under the hood, we introduced two new custom validation functions to make things more palatable to Form Builder and the forms engine. With these formulas the constraints become:


          In practice, as a user of Form Builder, you do not have to care about these functions and they remain hidden to you.

          One benefit of using custom functions is that special properties can be set by them when they run. For example, if you set the maximum length of a field to 140 characters, a max-length property becomes associated with that field. The new “Character Counter” appearance for example has access to that property and is able to show the number of characters remaining or the number of characters over the limit.

          The character counter uses the max-length property
          The character counter uses the max-length property

          Now that we have a solid foundation, we hope to introduce many more useful custom constraints in the future. And in fact we have already come up with a pretty good list of such constraints. You can see some of them in this RFE.

          We hope that you like this new feature!

          Wednesday, June 10, 2015

          How the new Form Builder Appearance Selector Works

          Recently, a customer asked us to implement a feature which looked simple at first: adding a character counter to input fields, text areas, and rich text controls (think a Tweet or an instant message which must fit in an SMS, for example). It looks like this:

          Input Field with Character Counter
          Input Field with Character Counter

          We could have gone the easy way:

          • write 3 new custom controls,
          • add them to the Form Builder toolbox,
          • and done!

          This would be easy enough to do with Orbeon Forms custom controls, but it is not an ideal solution. Instead we would like:

          • the “character counter” function to be independent from the control to which it applies (input field, text area, or rich text control),
          • and the ability to switch back and forth, in Form Builder, between a control with and one without the character counter.

          Going down to the markup level (that is, how the form definition is specified), an input field looks like:

          <xf:input bind="message-bind"/>

          What we want to do to add the character counter is add an appearance attribute, like this:


          The appearance attribute is a standard XForms attribute[1] which allows specifying how a control “looks like” without changing the kind of data it captures.

          And the good news is that since Orbeon Forms 4.9 we have a mechanism to bind custom controls with an appearance. Here is how it works:

          1. We create an fr:character-counter component which implements the logic of counting the characters in a field and acts as a wrapper around an existing control,[2]

          2. and we say that fr:character-counter must apply to input fields, text areas, and other controls if desired, when the character-counter appearance is found:

            xf|input[appearance ~= character-counter],
            xf|textarea[appearance ~= character-counter]

          This code specifies a “binding” for the custom control, and the cool thing is that it uses standard CSS selectors - yes, the same CSS selectors which developers use daily in their Web apps. This selector says in essence: “use this custom control implementation for input fields and text areas which have the character-counter appearance”.

          But there is more: this binding is declarative which allows Form Builder to discover automatically which controls support the character counter, and propose this as an option to the form author in the Control Settings:

          Character Counter Appearance Selection in Form Builder
          Character Counter Appearance Selection in Form Builder

          This is a fully general mechanism, which not only works for the character counter, but also for selection controls, buttons, and more:[3]

          Selection Control Appearance Selection in Form Builder
          Selection Control Appearance Selection in Form Builder

          Under the hood, there is a not-entirely-trivial algorithm[4] which:

          1. looks at the current control’s name (such as xf:input), datatype, and appearances,
          2. checks all available control bindings in the Form Builder toolbox,
          3. and returns the list of appearances which can apply to the control given its name and datatype.

          We are quite happy with the underlying architecture, and we hope the user-facing feature will be useful too! This feature will be available in Orbeon Forms 4.10.

          1. XForms specifies or suggests some standard appeararances. For example, a single selection control <xf:select1> with apperance full should show as radio buttons, while the compact appearance should show as a dropdown menu.  ↩

          2. Curious developers can see the very simple implementation of the fr:character-counter control here.  ↩

          3. We used to have a way to switch between selection controls before Orbeon Forms 4.0, but that disappeared during the big Form Builder rewrite which took place at that time. Now this feature is back but in a much more general way.  ↩

          4. Mostly implemented in BindingDescriptor.scala and BindingOps.scala.  ↩