XForms Everywhere

A few weeks ago, XForms 1.1 went to Last Call Working Draft status, and we forgot to blog about it! Luckily, John Boyer and Mark Birbeck have been quicker to talk about it. The purpose of the last call is to solicit comments about the specification before going to Candidate Recommendation status. Here is the specification to look at:

http://www.w3.org/TR/2007/WD-xforms11-20070222/

The last call will last until April 5, which is one week from now. So if you have some spare time, have a look at the specification and send back your comments to the XForms Working Group!

As some studies have shown (including Optimizing Page Load Time), serving CSS and JavaScript can have a high performance cost on page loads. This reality is particularly important now that JavaScript usage is increasing in web applications through the use of Ajax libraries like the Yahoo! User Interface Library, used by Orbeon Forms.

The following two points are particularly important:

1. The smaller the amount of data you send, the better.

   • Using gzip compression for HTML, XHTML, CSS and JavaScript helps. It is easy to enable gzip compression on your server, so by all means always do it on you production servers.

   • JavaScript “compressors” also help. Orbeon Forms already ships with “minimal” versions of most JavaScript files. This is enabled by default in properties.xml with the following:

     <property as="xs:boolean" name="oxf.xforms.minimal-resources" value="true"/>
     

2. Serving many small files at a time is slower than serving a single large file.

   • HTTP pipelining improves very much on this, but it is (very unfortunately) useless in practice because Internet Explorer doesn’t implement it at all and Firefox / Mozilla do implement it but do not enable it by default. Lobby your browser vendor to change that and the web will soon be faster!

   • Another possibility is to send only the JavaScript files required for a given page. Orbeon Forms already does this automatically. For example, if you don’t use the tree widget, JavaScript files handling the tree are not sent to the client.

   • Finally, another strategy consists in combining multiple JavaScript and CSS files into a single JavaScript file and a single CSS file.

This latter feature was introduced in Orbeon Forms last week. You enable it with the following property:

<property as="xs:boolean" name="oxf.xforms.combine-resources" value="true"/>

When this is enabled, Orbeon Forms refers to a single JavaScript file and a single CSS file for XForms-related functionality. The URL identifies special resources needed by the page, for example:

<link rel="stylesheet" href="/ops/xforms-server/xforms-range-autocomplete-min.css" type="text/css">
<script type="text/javascript" src="/ops/xforms-server/xforms-range-autocomplete-min.js">

This in short tells the XForms server to produce the minimal CSS and JavaScript for the XForms engine including support for the “range” and “autocomplete” features.

The Orbeon Forms XForms server has been enhanced with functionality to handle such URLs. When it receives a request, it determine what files need to be combined and outputs them all together. Furthermore, for CSS files, all URLs referred to with url() are rewritten, so that links to images, in particular, remain correct.

Note that an experimental cache for compressed resources has also been written. You enable it with:

<property as="xs:boolean" name="oxf.xforms.cache-combined-resources" value="true"/>

This cache works differently from other Orbeon Forms caches, as the result is stored in the resources, typically under:

WEB-INF/resources/xforms-server/

One benefit of this mechanism is that it allows making such combined files to be served by an Apache front-end.

So what are the results like? On certain pages using lots of widgets, you can save as many as 30 hits on your server with combined resources, and save several seconds of loading time! Needless to say, you may want to experiment with this feature and see what it can do for you.