• Form Builder
• Renaming an action duplicates it (#1913)
• FB user sees all forms in summary page if role is not found (#1963)
• Test mode: Validate button shows instead of inner buttons (#2002)
• Publish: document parameter value is not encoded (#1985)
• Exception when calling dataMaybeMigratedTo() (#1986)
• FB: Keyboard focus is not on first dropdown when present upon new (#2010)
• Form Runner
• Automatic PDF performance improvements
• Requests for resources must be internal (#1995)
• Don't store XForms document in cache (#1999)
• Automatic PDF output should cache images (#1996)
• Other automatic PDF improvements
• Grid rows without visible controls must not take space (#2004)
• Page number/count loses alignment if form title is too long (#2005)
• Don't let long title wrap in header or footer (#2006)
• Show form logo on PDF header (#2007)
• Textarea content must wrap (#2008)
• PDF templates improvements
• Automatically decide whether to use label or value (#736)
• Non-boolean checkboxes don't work (#1987)
• fr:number is always blank (#1955)
• fr:xforms-inspector causes PDF template error (#1949)
• XVT not evaluated for `uri` in `send` action (#1972)
• xxf:itemset() not working anymore now that we use fr:dropdown-select1 (#1856)
• Add a few missing Swedish resources
• XForms
• Incorrect check on headers in Connection (#1933)
• Error dialog not working (#1938)
• Don't log full stack trace of session expiration messages (#1979)
• Serializer not to filter elements in no namespace (#1981)
• Default value for Dynamic Data Dropdown is lost when pasting form source (#1962)

• PostgreSQL support. Thanks in good part to an external contribution, Orbeon Forms supports PostgreSQL in addition to Oracle, MySQL, SQLServer, DB2 and eXist. (blog, #1941)
• Better management of server resources. Under load, Orbeon Forms limits the number of concurrent form processing requests in order to reduce the likelihood of the server running out of memory (doc, #1971).
• Support for repeated grid visibility. It is possible to completely hide (including the header row) or mark as readonly a repeated grid (doc, #597 / #635).
• Owner and group-based permissions eXist support. Owner and group-based permissions were only supported with relational databases. This release adds eXist support. See also Database Support. (doc, #1341)
• Singleton forms. A singleton form is a form with only a single instance of form data visible to a user. Form Builder allows you to mark a form as such, and Form Runner then uses this information to prevent the creation of more than one instance of form data. (doc, #2009)
• Improved XForms 2.0 support. 
• The caseref attribute on xf:case is implemented (#1089).
• The xf:case() function is implemented (#1951). It was already available as an extension function with xxf:case().

Orbeon Forms supports versioning of form definitions since Orbeon Forms 4.5[1].

Since Orbeon Forms 4.6[2], Form Builder also allows you to control whether a new form definition version must be created:

Or whether the last existing form definition version must be overwritten:

You notice that there are warnings associated with each option! Ideally, we wouldn’t have a need for them, but the use of each option has different consequences on published forms.

So which option should you chose when you republish a new form definition?

1. If there is no data associated with the form definition in the database, it is safe to overwrite the latest form definition, unless you really want to keep the older version published.
2. If there is data associated with the form definition in the database and the changes you have made to the form definition
   1. are not structural, it is also safe to overwrite the latest form definition.
   2. are structural, it is not safe to overwrite and you should create a new version.

The following operations count as structural changes:

• adding controls, grids, or sections
• removing controls, grids, or sections
• moving controls, grids, or sections
• renaming controls, grids, or sections

The following operations are not structural:

• changing the form’s title or description
• changing a control’s label, hint, help, or alert message
• changing a section’s title or help
• adding or removing repeated grid or section iterations
• adding or removing languages
• changing the form’s permissions
• adding, changing, or removing the form’s PDF template [3]

In general, the following non-structural operations are safe, but can have consequences on data validation and access:

• adding or removing services and actions
• adding, changing, or removing validations or formulas
• adding, changing, or removing an XML Schema

For example if validation rules change, the situation can arise where data stored in the database was valid at the time it was saved, but the new form definition considers them invalid. So viewing the data will work, but attempting to save without changes will not satisfy the new validation rules and will fail. It is important to be aware of this when making validation rules changes.

Similarly, changing actions or visibility rules can make the form behave differently when editing or viewing existing data. Here again, you must be cautious.

Now you might ask, what is the drawback of always creating a new form version when publishing?

Existing data in the database is associated with a specific form definition version. This means that existing data cannot be viewed or edited with a different form definition version. So a fix for a typo in a control label, for example, wouldn’t show when editing or viewing existing data. This may or may not be acceptable depending on your use case.

As discussed in the original post about versioning, we hope to enable more scenarios with basic data migration in the future.

Orbeon Forms often needs to perform calls to itself, for example to:

• call persistence layer implementations,
• load internationalized resources,
• navigate between pages,
• proxy requests for dynamic XForms resources,
• and request CSS, JavaScript and image assets when producing PDFs.

In previous versions, Orbeon Forms performed actual HTTP connections on itself. This caused problems:

• Configuration: Orbeon Forms needed a host and port to connect. In some cases, this could be guessed, but in others, for example when a front-end was placed in front of Orbeon Forms, you had to override a configuration property. There were also reported cases of interference with some servlet filters installed by our users.
• Authentication and authorization: Internal services typically need the same credentials as the incoming request. To do this we were forwarding cookies and other headers, which could fail in some corner cases and was sometimes difficult to configure.
• Thread usage: This required more servlet container threads than needed. In some cases, a external request to Orbeon could cause 3 threads to be used, 2 of them just waiting on HTTP connections.
• Deadlocks: When the pool of threads provided by Tomcat was exhausted, deadlocks could occur, especially since we recommended a small pool in order to avoid overloading the forms processor. [1]
• Performance: Page and service calls were slower than needed, as HTTP connections needed to be established, and communicating over HTTP has a certain cost.

In short, change was needed! So with Orbeon Forms 4.7, we got on this and entirely removed of the use of HTTP for internal calls!

How did we do this?

We were already using an abstraction to perform requests within Orbeon Forms. This abstraction unifies how we access internal resources stored in the Orbeon application itself, as well as calls such as HTTP calls.

So we built on this [2] to provide an additional HTTP abstraction. We now have an ApacheHttpClient, which uses HTTP proper, and a new InternalHttpClient, which behaves like the real HTTP client from the perspective of the caller but in fact does its work entirely internally, without any network access.

From the perspective of the page or service called, it is as if the request was coming from an external HTTP client (with some minor twists).

This in one shot addresses all the issues listed above. So we are quite happy with this change!

• Form Builder
• Incorrect label edited upon insert of XBL with nested labels (#2075)
• Form Runner
• Error when producing PDF in parallel with Ajax request (#2071)
• Crash when paging on Summary page (6af5bed6c5)
• fr:number: incorrect rounding when using decimal separator other than `.` (#2076)
• Custom mips are not propagated to section templates (#2065)
• Other
• Ajax retry doesn't work with Firefox (#2074)
• Object cache statistics are not used but can be costly (#2072)
• NPE using xxf:evaluate-bind-property() (#2048)

The Form Runner wizard view is widely used by Orbeon Forms users: it presents a simple, navigable view of a form’s top-level sections, shown as separate pages.

Until recently, the wizard view only supported free navigation. In this mode, you can freely navigate between pages, independently from whether there are validation errors.

In Orbeon Forms 4.9, we are introducing a new wizard mode, called the validated mode. [1]

The main idea of this new mode is to prevent the user from navigating to subsequent pages until all the data entered so far is valid:

• You can always navigate back in the wizard, even if you have errors on the current page.
• But you can only navigate forward if there are no errors on all preceding pages as well as the current page.

This helps ensure that the user follows (and hopefully pays more attention to) specific steps when filling out a form.

There is a little twist: once you have visited a page, you can freely navigate again to it, whether with the Next button or the table of contents.[2] The idea behind this is that it can be frustrating to enter information on a page, only to be prevented by the wizard to reach that information at a later time.

As an aside, this improvement also fixes an issue related to incorrect highlighting of errors within wizard pages. [3]

The complete documentation is available here. We hope you will enjoy this feature!

• Form Builder
• XBL template bind attribute prefix/namespace lost when control inserted (#2095)
• Form Runner
• xxbl:mirror="true" not working after oxf.xforms.cache.documents.size reached (#2106)
• Wrong value in date/time control when using picker (#2086)
• Error when generating schema for form using section template (#2091)
• NPE when running pipeline with output from CLI (#2092)
• Autocomplete: fr-set-label has no effect if resource doesn't use the value (#2098)
• POST to /new handles missing data-format-version incorrectly (#2104)
• PDF: Wrong language if fr-language was passed to new/edit/view page (#2110)
• Tables in HTML control labels don't show in the PDF (#2135)
• Email validation too strict on TLDs supported (#2116)
• Persistence proxy to support header/cookies forwarding (#2053)
• Liferay Proxy Portlet - init-param "enable-url-parameters" is backwards (#2138)
• Error "The moduleId is not correct" when deploying portlet (#2153)
• Disable Liferay "speed filters" in proxy portlet (#2155)

Orbeon Forms can automatically produce nice PDF files without any extra work (see the documentation).

While PDFs are useful for printing and archival, they also have a few smarter features. For example, web links in a PDF file can be made clickable, and this is something that Orbeon Forms leverages:

1. Links in rich text content are clickable and open your web browser to the target link.
2. Links identified in regular input fields and text areas are automatically highlighted and clickable as well. [1]

And now we have added detection and automatic linking of email addresses in input fields and text areas as well. Here is an example of PDF output with the various types of links Orbeon Forms detects:

This enhancement will be included in Orbeon Forms 4.9. And for the curious, you can see the regular expressions we use for this.

• Form Builder
• New control for showing explanatory text. Lots of forms require explanations, often inline with form fields. Until now, you had to use workarounds to do this in Form Builder, such as using a Text Output field with an HTML label. The new Explanation control addresses this need, and allows you to place explanatory rich text anywhere in your form. (blog post, #507)
• Custom alerts for invalid data types and missing required fields. Since version 4.3, Form Builder allows you to set separate alert messages for constraints. Now you can also set separate alerts to show when the datatype is incorrect, as well as when a field is required but missing. (doc, #1978)
• Deselecting all radio buttons. Radio buttons do not have a way, in HTML, to be completely deselected except programmatically. This is usually not something you need to do in a form, but in Form Builder this is often desirable. The Itemset Editor now allows you to do just this (with thanks to Aaron Spike).  (#595)
• Performance improvements. We improved performance of very large forms in Form Builder. (#2183, #2181)
• Form Runner
• Fix for occasional data loss with section templates. This is an important fix, which we have also backported to previous version of Orbeon Forms. We recommend patching Orbeon Forms if you are using section templates. (#2106)
• New wizard validated mode. This new wizard mode allows you to only navigate forward if there are no errors on all preceding pages as well as the current page. This helps ensure that the user follows specific steps when filling out a form. (blog post, #2066)
• Email validation too strict on TLDs supported. Up until recently, it was possible to know which top-level domains (such as .com, . fr, etc.) were actually in use and to include such tests as part of email validation. But currently there are 810 of those, and the number is likely to grow. So we have relaxed our email validator to allow any TLD. (#2116)
• Configurable PDF file name. You can now configure the filename to use with the PDF button on the Form Runner Detail page. The filename is configurable via XPath and can even depend on form data. (#2122)
• Accessibility improvements.
• Screen readers will now tell you whether an input field is invalid and/or required, via the aria-invalid and aria-required attributes. (#2148)
• The Refresh button now includes a label. (#2158)
• Button with menus tell you they are collapsed or expanded (#2162)
• Performance improvements. We implemented a couple of performance enhancements, in particular to handle large form updates under Chrome. (#2185, #2174)
• XForms
• Nested required and type elements. You can now use elements instead of attributes to assign required and type model item properties. This allows giving them distinct identifiers and alert messages. (doc and doc, #1978)
• New functions to access the username,  group and roles. The following functions can be used to access current user information: xxf:username(), xxf:user-group(), and xxf:user-roles(). These functions also work when using headers-based permissions. (doc, #2062, #2063)
• Other
• Namespaced jQuery.  Orbeon Forms is now a better JavaScript citizen by namespacing our version of jQuery. This way you can include your own version of jQuery or Zepto.js in your page, and it won't conflict with the version used by Orbeon Forms. (#1155)

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:

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:

<xf:input
    bind="message-bind"
    appearance="character-counter"/>

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:

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

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.

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.

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.

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:

xxf:max-length(140)
xxf:min-length(10)

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.

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!

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.

• 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! (blog, doc)
• 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. (blog, doc)
• 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. (doc)
• 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. (doc, blog)
• 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)

• grouping fields in a logic way;
• making better use of the space available on the page.

We recently implemented two improvements to repeated grids and repeated sections, which appear as two new options in 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:

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.

• 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)

• 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)