Orbeon Forms — XForms Everywhere

What happens after users fill out a form?

2012-05-30T11:26:00.002-07:00

Orbeon Forms focuses on making it easy for form authors to create and deploy forms, and for end users to fill out those forms. When you create and deploy a form with Form Builder, you get the URL of a new page for that form. You can point users to that page, so they can fill out the form.
But what happens when users are done filling out the form? There are several ways to setup Orbeon Forms, but we’ll cover here the common use case where you want to have a Submit button that:

Saves the data in a database, per your configuration. (For more details, see which databases Orbeon Forms supports out of the box.)
Takes users to another page.

You can do this by setting the following 3 properties. If you haven’t setup properties before, you might find this overview of properties useful.

<property as="xs:string"  name="oxf.fr.detail.buttons.*.*" value="submit"/>
<property as="xs:string"  name="oxf.fr.detail.submit.buttons.*.*" value="go"/>
<property as="xs:string"  name="oxf.fr.detail.submit.go.uri-xpath.*.*"
                          value="'http://www.your-site.com/form-submitted'"/>

Let’s go through those 3 properties:

The first property defines which buttons are shown on the form; here we only include the Submit button, as this is the one we’re interested in, but you might want to include additional buttons.
The second property configures the dialog that shows upon submission, which you can see in the screenshot below. Here include one button, taking users to a page of your choosing.
The third property defines the page users are taken to. To put a static value, add single quote inside the double quotes as done here. (The value can also be dynamic: you can provide an XPath expression returning a URL, which runs on the data entered by users.)

Dialog upon submission

What if this form is part of a workflow, and that depending on the data users entered, you want to take them to a different page? Then the workflow send button is what you are looking for. To end users, the workflow send button looks like a regular Submit button. But it is one that you can configure to do much more; for instance, it can:

Optionally, generate a PDF of the form, with the data entered by users.
Optionally, send out an email, with the XML data and/or the PDF.
Optionally, store the XML data and/or the PDF in Alfresco.
Take the user to a page, either sending the XML data or the PDF to that page.

The page mentioned in this last step is one you provide. That page receives an HTTP POST with the data entered by users, so you can implement it outside of Orbeon Forms using the technology of your choice (servlet, PHP…). Maybe based on the information entered by users, you can implement it to direct users to the next step in their workflow, which may involve filling out another form. For more details, see the documentation for the workflow send button.

Orbeon Forms 4.0 M1

2012-05-23T21:53:00.000-07:00

Today we released Orbeon Forms 4.0 M1 (Milestone 1). As the name implies, this is not a final release, but a release aimed at people who want to have a preview of what's going to be in the upcoming 4.0 release and, hopefully, send us some feedback.

Most features planned for 4.0 are in, including:

Form Builder

repeats
nested sections
live XBL components
improved and more responsive editor
custom XML (PE only)

Form Runner

improved Liferay support (PE only)

Tons of bug-fixes and improvements!

What's not in it?

Landing pages and some look and feel improvements
Form Builder IE 8/9 support (so for now use Chrome, Firefox, Safari or Opera)
Fixes for the remaining issues:

You can download the builds using these links:

PE version: orbeon-4.0.0.m1.201205232241-PE.zip
CE version: orbeon-4.0.0.m1.201205232300-CE.zip

Don't forget to grab a trial license for the PE version.

Also check the release notes for 4.0, which are a work in progress.

Please send feedback preferably to the ops-users list or via twitter (if short!), or feel free to comment on this blog entry if appropriate.

Run modes

2012-05-22T22:23:00.001-07:00

Recently, we implemented support for run modes in Orbeon Forms.

The idea is not new and it comes down to this: sometimes you want to run Orbeon Forms with development settings, and sometimes with production settings.

So far, to achieve this, you had to play with your properties-local.xml file, either commenting and uncommenting properties, or maybe switching between property files.

Now, you can simply change your run mode in web.xml. You can still use the good old properties-local.xml, which impacts all modes, but you can also use the new properties-local-prod.xml and properties-local-dev.xml, which are used depending on the mode.

Orbeon Forms also comes out of the box with slightly different settings depending on the run mode, including:

whether exceptions are shown to the user
whether JavaScript and CSS resources are combined and minimized

Oh, and the feature is implemented in a simple and beautiful way by selecting different internal property files, which in turn include different secondary files. That's just a few lines of code, the rest being toying with property files.

We hope you find this useful! For the specifics, see the documentation.

Forms access control with Form Builder

2012-05-17T16:47:00.000-07:00

Who can do what with Form Builder? You guessed it: in this post, we’ll discuss access control, as it relates to Form Builder. More specifically, that question has two facets:

When it comes to people using Form Builder to create or edit forms, often referred to as form authors, who can create or edit which form?
When it comes to the end-users of the forms created with Form Builder, who can access which form?

In both cases:

Permissions are role-based: access isn’t given based on usernames, but on roles. For instance, for Form Builder permissions (the first case above), you could be defining that only users with the role finance can access forms in the app payroll.
Users and roles are not defined in Form Builder or Orbeon Forms. Instead, you configure the container (say, Tomcat), in which you’re running Orbeon to leverage your existing authentication system, say users and roles defined in LDAP. And if you don’t already have users and roles defined somewhere, Tomcat lets you define them is a simple XML file (tomcat-users.xml).

Let’s get back to the two types of access control mentioned earlier:

Access control to Form Builder itself is done through a property file: form-builder-permissions.xml. There, you can define which roles have access to which apps, and which forms. This is most often used to partition your forms into group, and give people access to a specific group. For instance, a local government might have different departments, say police, social services, parks, housing… and would like to keep the forms for each department separate. So they will create an app and a role for each department, and will define in form-builder-permissions.xml that form authors can only access forms of a given app of they have the corresponding role; say, they can only access forms in the social-services app if they have the social-services role. For more on this, see how to define access control to specific apps/forms in Form Builder.
Access control to published forms is a new feature of the upcoming Orbeon Forms 4.0, but you can already give it a try today using a nightly build. With this new feature, you can, as a form author, define who can access the form you’re editing right from Form Builder. You do so through a dialog, as shown in the screenshot below. For more on this, see how to define access control for deployed forms with Orbeon Forms 4.0.

Screenshot of the Form Builder permissions dialog

More XForms bindings

2012-05-08T14:31:00.000-07:00

Photo by preservationgal

In a previous post, we covered the basics of controls bindings, where XPath expressions are used to bind a control to XML elements. But it's not always that simple, is it? So now is the time to cover all the cases you can encounter with binding expressions.

First, there is another difference with HTML worth pointing to: if the XML node does not exist, the control becomes non-functional (non-relevant), and appears hidden (or in some implementations grayed out). So it's important to create an instance (XML document) which contains all the elements and attributes your controls are pointing to, unless you want to hide them on purpose.

So now we have covered binding expressions pointing to a single element, or pointing to nothing. Are there other possibilities? Well yes!

1. Attributes

Obviously, a control can bind to an XML attribute too:

<xforms:input ref="@tag">

Here the input field reads and writes to a "tag" attribute:

2. Multiple nodes

What if the XPath expression returns more than one node? For example, assuming the document from the previous post, the following would return two elements:

<xforms:input ref="instance('zoo')/animal/nickname">

XForms solves this by saying that you just take the first node returned. Except, that is, for bindings that support multiple nodes. The only control which supports this is <xforms:repeat> (but other XForms constructs support multiple nodes: <xforms:itemset>, <xforms:bind>, <xforms:header>, and the <xforms:insert> and<xforms:delete> actions.

3. Atomic values

What if the binding expression returns something other than a node, like a number? In XForms 1.1, this was disallowed and the binding would throw an error. XForms 2 changes this because XPath 2 deals more generally with items, which can be nodes but also atomic values. Also, and maybe more importantly, there are some interesting use cases to bind to atomic values, in particular with <xforms:repeat> and <xforms:itemset>.

So XForms 2 says that it's ok to bind to atomic values. For example this will work:

<xforms:input ref="42">

However, the input control appears read-only, because in XPath it doesn't make sense to write to an atomic value.

In general, it's not very useful to bind controls such as <xforms:input> to atomic values. It's ok for <xforms:output>, although that control already had a value attribute for that purpose. Where this really shines is for repeats or itemsets:

<xforms:repeat ref="1 to 10">
<xforms:output value="."/><hr/>
</forms:repeat>

Then there are a couple of things you probably shouldn't do:

1. Binding to text nodes

<xforms:input ref="instance('zoo')/animal/nickname/text()">

This is allowed but discouraged. Why? First, there might not be a text node, and then the control won't show. Second, if there is one, and the user enters a blank string, the text node will go away (because XForms and other specifications like the XPath data model say you can't have empty text nodes), and the control will hide. Not very useful!

2. Comment nodes and processing instruction nodes

<xforms:input ref="comment()">
<xforms:input ref="processing-instruction()">

XForms doesn't prevent you from doing this, but not all implementations might support it, and XForms doesn't say what must happen. Since recently, Orbeon Forms allows you do do that, and the control will read and write the comment text or the processing instruction value. It's unlikely you will need that, and it's not guaranteed to be portable between implementations, but at least XForms allows it and if you need it you'll be a happy camper!

Finally, there are things that are outright prohibited:

1. Binding to elements that contain other elements

<xforms:input ref="instance('zoo')/animal">

This is not allowed. Why? Probably because there are a few ways this could be understood. For example, the control could read and write text at the beginning of the element, or at the end. Or, it could read the XPath string value, but overwrite everything when writing back! Also, XML Schema doesn't validate values in such elements with so-called complex content. To make things clearer, XForms says there that if you do that, the binding will throw an error.

2. Binding to a document node

<xforms:input ref="instance('zoo')/..">
<xforms:input ref="instance('zoo')/root()">

This is not allowed. Why? Because in XML it's not possible to have non-blank character data at the top of an XML document, so the control wouldn't be able to write data there. Here again, the binding will throw an error.

In both these prohibited cases, Orbeon Forms now uses its new error handling behavior.

Please let us know if we missed any aspects of control bindings!

How XForms controls bind to data

2012-05-02T14:40:00.000-07:00

Photo by Philippa Willitts

Take the most basic HTML input field:

<input name="nickname">

Then, compare to the equivalent XForms:

<xforms:input ref="nickname">

Both look pretty much the same, right? Well yes, but only on the surface!

In HTML, you just specify a name, which is later used by form submission (or to query form fields). In XForms, on the other hand, the ref attribute holds an XPath expression pointing to zero, one or more XML element or attribute nodes.

Often, XPath binding expressions are very simple and look just like a plain name, like above, where the expression in fact says "under the curent XPath context, point to the XML element called nickname".

Where are those XML elements defined? In XML documents (called instances in XForms) defined in the XForms model. For example:

<xforms:model>
<xforms:instance>
<animal>
<nickname>Batman</nickname>
</animal>
</xforms:instance>
</xforms:model>

Because the expressions are XPath, they can be more fancy when needed. In fact they allow you to point to any node in an instance. Consider the more complex:

<xforms:instance id="zoo">
<zoo>
<animal tag="42">
<nickname>Thika</nickname>
</animal >
<animal tag="43">
<nickname>Iringa</nickname>
</animal >
</zoo>
</xforms:instance>

Here we point to a very specific nickname element:

<xforms:input ref="instance('zoo')/animal[@tag = '42']/nickname">

Now once your control points to a node, what does it do? It is pretty simple:

When the user enters data into the field, the data is written to the XML document.
If the data changes in the XML document, the control is updated with that data.

It's a nice example of the MVC pattern, where the model is made of hierarchical XML documents, the view is made of controls, and where data flows in both directions between model and view.

In a subsequent post we cover in more details what kind of things you can bind controls to!

Form Runner gets a home page

2012-04-26T19:42:00.000-07:00

For every form you create with Form Builder, after you deploy the form, Orbeon Forms exposes two pages:

A new page, which end users go to to fill out the form. When a form is filled out and saved, it creates what we refer to as form data.
A summary page, which lists all the saved form data for a given form. Depending on your workflow, access to this page is typically limited to admins or users in charge of processing the submitted form data.

Each one of those pages has its own URL. In a typical deployment, you would link to those pages from a site your users are accustomed to go to. For instance, a city might have a site with a description of the parks in the city, which contains a Reserve picknick area link, taking citizens to the new page of a form created with Form Builder.

There are cases, however, where it is useful to have a list of the deployed forms, without the need to add links to the new or summary pages from another site. And this is precisely what the new Form Runner home page does.

As you can see from the above screenshot, forms listed on the home page depend on the permissions you've been granted. For instance, you may be able to fill out a form, but not to see all the data saved for that form. Or maybe you don't have access at all to a given form, in which case it won't get listed. This permission system is new as well in Form Builder, and we'll cover it in more details in a future post here.

You can already experiment with the new home page today by downloading a nightly build. And this is just a start: we have big plans to improve this new Form Runner home page to make it even more useful.

XForms 2.0: goodbye nodeset

2012-04-18T22:27:00.000-07:00

XForms 1.1 makes a distinction between two commonly-used attributes: ref and nodeset. Both are binding attributes, and they hold an XPath expression pointing to zero, one or more XML element or attribute nodes:

ref points to a single node ("single-node binding"). Its most frequent use is to bind a control such as xforms:input to XML data.
nodeset points to any number of nodes ("node-set binding"). This is used for example by xforms:repeat and xforms:itemset, which iterate over multiple nodes.

While working on the upcoming XForms 2.0 specification, which fully supports XPath 2.0, the XForms Working Group noticed a problem: node-set is terminology from XPath 1.0, and XPath 2.0 instead uses the more general notion of sequence. So keeping an attribute named nodeset in XForms 2.0 would be quirky!

The good news is that the solution is very simple, because it turns out that having two separate attributes is not necessary in the first place. So the Working Group has decided that XForms 2.0 will use ref everywhere and deprecate nodeset, keeping it around for backward compatibility only.

This has the additional benefits of simplifying the XForms syntax and removing a possible source of confusion for form author (e.g. which attribute should you use on xforms:bind?).

So get used to write:

<xforms:repeat ref="foo">
<xforms:bind ref="bar">
<xforms:itemset ref="baz">
<xforms:delete ref="qux">

Another good news: Orbeon Form already supports "ref everywhere" since version 3.9, so feel free to drop good old nodeset!

Support for repeats lands in Form Builder

2012-04-11T18:44:00.001-07:00

XForms has a rather powerful feature called repeats, which allows form authors to easily create forms with sets of fields that can occur multiple times. Repeats have always been supported by the XForms engine in Orbeon Forms, and now, they can also be used directly from Form Builder.

For instance, consider the "DMV 14" form, from the Department of Motor Vehicles in California, which allows you to list multiple vehicles. In the paper version of the DMV 14, the fields for a vehicle have been repeated 3 times, allowing a maximum of 3 vehicles to be entered. This is how things were on paper, and often today still with PDF, but with web forms, we can do much better: we can enable end users to add or remove vehicles, without even having to impose a limit on the number of vehicles users can enter. And of course, what works for vehicles, works for any set of fields you'd like to see repeated.

Imagine you want to create a conference registration form allowing an organization to suggest talks their members can give. For each talk, you'd like to know the presenter, the topic, and the date/time. In Form Builder, you create a repeat, by clicking on New Repeat on the side bar, (see screenshot to the right). You then create columns and add fields, as you normally would in grids. The following screenshot shows how this looks like in Form Builder.

When filling out the form, users add new lines as necessary clicking on the + sign.

Note how the label for the fields, instead of being repeated on each line, show just once in the table header. Such a table layout works well when you have a few fields repeated. But as the number of fields grows, you'll want to put them on multiple lines, and it will then be a block of lines that gets repeated. This is what we did in the following example, creating a total of 6 fields to be repeated:

Now note how, both in Form Builder (above) and when users fill out the form (below), the labels for the fields show above each fields, as having them just once in the table header wouldn't work anymore. And all this is automatically handled for you.

Repeats in Form Builder will be part of the next release of Orbeon Forms, and if you feel adventurous, you can try them today by downloading a nightly build.

Asynchronous submissions

2012-04-04T12:09:00.000-07:00

You might not have heard about it, but XForms supports asynchronous submissions since version 1.1. In fact, XForms 1.1 even made the asynchronous behavior the default, probably because in the browser XMLHttpRequest is asynchronous. [1]

So what does it mean for an XForms submission to be asynchronous? Simply that sending the submission (with an action or the <submit> control) doesn't wait for the submission to be fully completed before returning. For example, consider:

<submission
id="save"
ref="instance()"
mode="asynchronous"
method="post"
replace="instance"/>

And then this sequence of actions:

<send submission="save">
<setvalue ref="foo" value="42"/>

The <send> action starts the submission with an xforms-submit event, instance data is prepared, and then an HTTP request is started with that data as payload. "Soon" after, control returns to the action processing, and the <setvalue> action runs. The response from the submission may not have yet happened at that point. In fact, if the submission takes a long time (say, seconds or minutes), the submission will just be hanging there, waiting for a response. Once the response arrives, the submission result is processed.

With a synchronous submission, on the other hand, the <setvalue> action only runs once the response has arrived (or once an error has occurred). So the submission mode matters when you deal with XForms actions and events, and you have to be aware of the difference in processing between the two types of submissions.

There are useful practical uses to asynchronous submissions, including:

running background operations, for example autosaving data
reducing latency, for example loading initial data from multiple services concurrently

Background operations are good because they allow the user to continue working with the application while the operation completes. Reducing latency is good for the user because pages load faster.

Now since Orbeon Forms implements submissions on the server, you might wonder how this works! Orbeon Forms checks for pending asynchronous submissions at the end of page initialization and at the start and end of an Ajax request.

If page initialization or an Ajax request terminates and submission are still pending, the browser is instructed to poll the server from time to time, to check whether pending submissions have completed. Those which have are then handled appropriately.

You can find more details in the documentation on asynchronous submissions.

[1] Orbeon Forms has so far kept the default to synchronous for backward compatibility reasons.

TinyMCE control now in Form Builder, with HTML cleanup

2012-03-28T16:34:00.001-07:00

Back in February, we were telling you about the new TinyMCE component. Since then, we have made a couple of important improvements to this component:

It is now used in Form Builder when you insert an HTML text control, instead of the YUI RTE. The screenshot below shows what the TinyMCE control looks like now in Form Builder. (Doesn't it look exactly like the actual TinyMCE control? It does, because it is the actual TinyMCE control running there in Form Builder.)
The TinyMCE component now does automatic HTML cleanup. This avoid having a tag soup in your data, and, more importantly, improves security by preventing XSS attacks. As a bonus, the code doing the tag soup parsing is now available in a processor: the TagSoup processor.

Be focused!

2012-03-21T17:40:00.000-07:00

Contrary to what the title might suggest, this isn't a post on personal productivity or self-realization! Instead, we will be talking about keyboard focus.

We recently made a number of improvements to focus handling in Orbeon Forms, on two fronts:

The XForms engine is more aware of which control owns focus.
Focus in/out events are now handling container controls.

Say you have a group containing two fields: name and email, followed by a save button:

This corresponds to the following simplified XForms:

<group id="name-and-email">
<input id="name" ref="name"/>
<input id="email" ref="email"/>
</group>
<trigger id="save"/>

Starting with initial focus on name, when you navigate from the name field to the email field to the save button, focus events used to be dispatched as follows:

DOMFocusOut on name
DOMFocusIn on email
DOMFocusOut on email
DOMFocusIn on save

With the recent changes, you are also informed of the fact that focus has left the group:

DOMFocusOut on name
DOMFocusIn on email
DOMFocusOut on email
DOMFocusOut on name-and-email
DOMFocusIn on save

Of course this works for DOMFocusIn as well, nested groups, and in fact any grouping control, including repeats, switches, and XBL controls. Focus is not only updated upon the user navigating between controls, but also when the user interface updates following UI refreshes and actions such as setfocus, setindex, toggle, show/hide, and insert/delete.

This behavior also makes perfect sense for XBL controls which are composites of other XForms controls. Say you have a composite control for dates with multiple fields:

You use this control this way in Orben Forms:

<fr:fields-date ref="date"/>

From the component user's perspective, fr:fields-date gets focus in/out events as if the composite control was a a single control. This satisfies the requirements for abstraction that come with XBL components, and in effect works like event retargeting specified by XBL 2 and the HTML Shadow DOM.

To learn all the little details, see the documentation.

The autocomplete gets a new labelref attribute

2012-03-19T11:48:00.000-07:00

The autocomplete is a quite powerful but also fairly involved component. We've looked at how form authors use the autocomplete in Orbeon Forms, and found that in most cases they use it as an alternative to a combo box or radio buttons, for cases where the number of items to choose from is too large to be displayed in its entirety. The autocomplete then acts as a search interface to locate one specific item amongst many. In some cases, the number of items is so large, that it not only doesn't make sense to display all the items to users: it also wouldn't be reasonable to load them all in Orbeon Forms, on the server-side. In those cases, as users type in the field, you want the form to make a request to a service to load the items relevant to what users typed so far. To make that use case easier, last year we introduced the resource mode.

But the resource mode had one flaw. To see exactly what it is, let's first backtrack a bit. Items have two components: the label, which is shown in the UI, say "California", and the value, which is stored as part of the form data when users make a selection, say "CA". This is consistent with how things are done in XForms for all XForms selection controls. The trouble is that when users load a form where a value has already been selected, say "CA", we didn't know what to show in the autocomplete. Of course, you say, show "California"! But how can the autocomplete know that the label for "CA" is "California"? In resource mode, form authors give the autocomplete a service allowing the component to find items based on labels; but here we want to do the opposite: find a label based on the value. We could have asked form authors to provide another service, returning the label for a value. But this would have put more burden on form authors and could have caused performance problems on forms with several autocompletes, causing many service calls. So instead, we added a new labelref attribute, simply pointing to a node in the instance that will be used to store the label, so the component can store both the value and label of the selected item.

And for those of you using Form Builder, all of this is entirely transparent. You can forget what you just read about labelref, as Form Builder will take care of adding that attribute as well as a corresponding node in the instance.

More concise XForms

2012-03-12T12:22:00.001-07:00

Recently we made a proposal to the XForms working group to help reduce the size of XForms code.

The XForms syntax is XML-based. When designing an XML vocabulary, it's often hard to choose between using elements or attributes. XForms has historically leaned toward using more nested elements [1], which tend to add more markup (you need pointy brackets and closing tags), and more lines (as you tend to indent nested elements for readability).

For example, compare the following HTML:

<select>
<option>French</option>
<option>English</option>
</select>

with similar [2] XForms:

<select>
<item>
<label>French</label>
<value>fr</value>
</item>
<item>
<label>English</label>
<value>en</value>
</item>
</select>

You notice how <label> and <value> are defined as nested elements and influence a lot the size of the markup.

The programmer community lately seems to have spoken in favor of concision, witness languages like Ruby, CoffeeScript, and Scala, and we agree at Orbeon that concision is a great thing when it removes boilerplate and does not come at the cost of readability. So we propose to use more attributes nested text whenever possible. The XForms above becomes then:

<select>
<item label="English">en</item>
<item label="French">fr</tem>
</select>

That's just an illustration of the idea and the next step is to figure out the details, specifically which new attributes to support and where to allow nested text (like in the <item> value above). In addition, we propose to use attribute value templates (AVTs) to handle dynamic values and keep the concise syntax. For example, to retrieve the label from localized resources:

<input ref="name" label="{instance('resources')/name}"/>

The good news is that the working group has received the idea positively so far!

[1] One exception is the XForms for HTML Working Draft, which introduces a set of attributes for the purpose of integration with HTML.

[2] To be fair we are not exactly comparing apples and oranges here as HTML doesn't separate label and value for items. So XForms does a little more, but at the (unnecessary) cost of a lot of extra markup.

Quickly search code on GitHub with Chrome

2012-02-29T15:36:00.000-08:00

You're looking at a project on GitHub, say Orbeon Forms, and would like to do a search in that project. GitHub provides a search field, but it searches through everything on GitHub, not just the current project you're looking at. This unless you click on the Advanced Search icon, in Search for select Code, and prefix your search by repo:orbeon/orbeon-forms. If you're anything like me, you'll find this too time consuming and won't use the GitHub site for searching.

Luckily, if you're using Chrome, there is a shortcut. With that "shortcut" in place, type o hello world in the location bar, and you'll see:

Press enter, and you'll get the results from GitHub. Now that is something I'd use! All you need to do:

Go to the Chrome settings (⌘, on OS X).
In the Search section (shown below), click on Manage Search Engines.
Scroll to the very bottom of that dialog to add a new entry. In the first field enter a descriptive name, say Orbeon Forms source. In the second, the keyword you'll use as a prefix when doing a search, say o for Orbeon. (You can pick a more descriptive keyword, but I'm in a rush, so o it is.) Finally, the last field put:

https://github.com/search?type=Code&q=repo%3Aorbeon%2Forbeon-forms+%s

Note the orbeon%2Forbeon-forms in that URL, which you can change if you'd like to search another GitHub projects. With this, your new custom search engine will look like:

Enjoy!

An improvement to inline JavaScript in actions

2012-02-15T09:22:00.000-08:00

We just implemented a performance enhancement when using JavaScript from XForms, in particular from XBL components.

In Orbeon Forms, you typically call client-side JavaScript from actions with the <xxf:script> extension action or with <xf:action type="javascript"> (which is now the preferred way). For example, the Currency XBL component has a call like this:

<xxf:script>
YAHOO.xbl.fr.Currency.instance(this).setfocus();
</xxf:script>

Until now if you used more than one instance of the currency component in your page, the inline scripts would be duplicated multiple times on the client.

Now, with this enhancement, each script body is associated a SHA1 hash based on its content, and a given script body is sent to the browser only once. This means less duplication of code.

Here is the documentation on <script> and <action> actions for scripting. And if you are interested in the implementation, here is the git commit, in particular PartEventHandlerAnalysis.scala.

Does XForms need to be implemented natively in browsers?

2012-02-14T09:22:00.001-08:00

For as far as we can remember, we've been getting variants of the following question: "Does XForms, as a technology, really have a future? I wonder, as I don't see browsers making any moves to implement it."

When considering technologies, it is reasonable to worry about their future. But why would one think XForms has no future if it isn't implemented in browsers?

In the late 90s and early 2000s, XML technologies were widely imagined to be the foundation on which future web apps would rely. As part of that vision, browser vendors implemented XML parsing, XPath, XSLT transformations, and even CSS styling of XML documents. XForms too was initially designed to nicely fit in that stack.

For better or for worse, that XML-centric vision didn't come to fruition. This in particular means that initial efforts to bring XForms to the browser natively have been abandoned. Instead today's browsers mostly eschew XML and implement improved, faster and more robust versions of the technology stack we had 10 years ago: HTML, CSS, the DOM and other JavaScript APIs, and of course JavaScript itself.

In short, in the browser, JavaScript has won and XML has lost, as part of the native browser stack. It might be disappointing to some, but at Orbeon, we recognized this many years ago. In 2005 already we implemented the first version of our Ajax-based XForms engine, which shipped in Orbeon PresentationServer 3.0.

So the native XForms ship has sailed a long time ago in our opinion. Instead, the web browser has increasingly shown to be a great platform to build all sorts of application and frameworks, and XForms happens to be just one such technology.

This situation in fact has great benefits: nobody waits for browser vendors or all web users to upgrade their browsers to use a newer version of jQuery or Ruby on Rails. So not being a native browser technology allows us to move faster, and you to benefit from improvements sooner (proof: the Orbeon Forms engine still works in IE 6!). It also allows Orbeon to implement a split architecture, where data can reside on the server, while logic run on either the browser or the server, depending on what is the most appropriate.

And what about HTML5 forms? Do HTML5 forms mean that XForms is no longer needed? HTML5 contains welcome incremental improvements over what is available in HTML 4: if you are creating very simple forms, HTML forms and a bit of JavaScript will be just fine. Where XForms has a big edge is for creating complex forms, maybe with sophisticated validation logic, or to manage a large number of forms. And needless to say, if you already deal with XML data, XForms will be a perfect match.

Orbeon Forms 3.9.1 PE released

2012-02-08T10:55:00.000-08:00

We are happy to announce the release of Orbeon Forms 3.9.1 Professional Edition (PE).

This release is a stable update to Orbeon Forms 3.9.0 PE. It includes over 40 bug-fixes and select low-risk features. For more information, see the full list of changes.

Orbeon Forms 3.9.1 PE is available immediately from the downloads page.

New TinyMCE rich text editor, with iPad support

2012-02-01T17:40:00.000-08:00

Orbeon Forms has supported rich text editing for the longest time, leveraging the YUI 2 RTE. However, depending on your situation, the RTE isn't always the best editor. For instance, it doesn't support <p> and instead uses <br>, by design. Also, it can't be use on iPads and iPhones, despite iOS 5 now supporting HTML5's contentEditable. For this reason, we created a new component, which uses the TinyMCE WYSIWYG editor, with the thebigreason skin.

For more details, see the TinyMCE component documentation. Our thanks go to Teleflex, who sponsored the development of this component, as well as Florian Schmitt, who contributed a first implementation.

Use HTML5 placeholders, in XForms

2012-01-12T11:46:00.000-08:00

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

2011-12-07T15:11:00.001-08:00

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:

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.

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.

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

2011-12-07T10:20:00.001-08:00

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:

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

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.

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.

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!

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

2011-12-06T11:13:00.001-08:00

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

2011-11-22T17:45:00.001-08:00

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

2011-11-17T13:25:00.001-08:00

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:

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.
Not producing any result at all. Example: a value calculated using an XPath expression failing at runtime is ignored.
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.