Orbeon Forms 3.9: aggregating CSS and JavaScript resources

Orbeon Forms has had the ability to automatically combine (aggregate) together CSS AND JavaScript resources for years. The idea is simple: serving many files to the browser is not optimal due to the latency introduced by each request from the client, so you should try to server fewer files to the client.

In general, this is pretty easy for CSS and JavaScript files: just concatenate them together, create a URL to represent the combined file, and tell your page to load the combined file instead of the individual files.

For CSS, you have to be a bit careful as CSS can contain URLs pointing to other resources, such as images, that are assumed to be relative to the URL of the CSS file itself. So Orbeon Forms rewrites URLs in CSS files to point to the right place. For JavaScript, a simple concatenation works.

This is nice and all, but before Orbeon Forms 3.9 this was limited to built-in XForms engine resources. As more and more built-in CSS and JavaScript is added by the use of nicely packaged XBL components as well as custom resources, this feature had to be improved.

So in Orbeon Forms 3.9, we revisited the whole aggregation feature to make it even better!

Now, the aggregator looks at all CSS and JavaScript:

• built-in XForms engine resources
• XBL resources
• custom resources placed by the form author

Here is how it works. When the page is generated, just before sending the page to the browser, the URLs of all the CSS and JavaScript to use are considered. They are split in three categories:

1. baseline resources: resources that every single page will load no matter what
2. supplemental resources: resources specific to the current page
3. non-aggregated resources

For baseline and supplemental resources, a hash is computed based on the paths to the resources and a version number (Orbeon Forms version number plus, if present, your application's version number). This hash is included in the URL sent to the browser. This ensures that aggressive, perpetual caching can take place on the browser. So you will see paths like:

/orbeon/xforms-server/orbeon-8b3d174e93f2d74146c9b2a5356bd5b8b5e196f8.css

Then the server maps the hashes to the list of actual resources, which when requested by the browser can then be aggregated on the fly and even subsequently cached on the server.

Baseline and supplemental resources are aggregated separately. The idea of the baseline is the assumption that in an application, many pages will share lots of resources. Once you have hit a page the first time and caching has occurred, the baseline resources will be picked directly from cache on all subsequent pages.

Only the supplemental resources, which we hope are small (or even empty if the baseline includes everything you need for all pages), will be loaded for each new page. Of course, the supplemental resources too are cached aggressively by the browser.

Finally, there are some resources that can't be aggregated easily: for example, CSS targeting a specific media. There are usually no such resources, or few of them.

The result: fewer requests to the server when loading and navigating Orbeon Forms pages, and also a cleaner implementation.

More information:

• Combined resources
• If you are curious to see how things work, you can check the source:
• ResourcesAggregator.scala
• XFormsResourceServer.java