Tuesday, March 29, 2011

Switching to CoffeeScript


JavaScript feels like Stink Spirit, the character in Miyazaki’s Spirited Away, who one day arrives at a bathhouse, loaded with all the filth it accumulated through the years. In the movie, Chihiro's, through her courage and generosity, helps Stink Spirit cleanse, and while its essence is unchanged, it comes out cleaner, purer… which brings me to CoffeeScript.
A few months ago, at Orbeon, we started using CoffeeScript instead of JavaScript for our client-side code. Just as when we started using Scala instead of Java for server-side code, the switch wasn't disruptive: CoffeeScript compiles to readable JavaScript, and so we could start using CoffeeScript for new functionality, while leaving existing code in JavaScript. So far, our experience has been all but positive. CoffeeScript will help you to:
  • Get rid of the cruft — This isn't only about using less characters; more importantly it is about making what is important stand out. Case in point: comprehensions.
  • Avoid common errors — this is a source of numerous mistakes, as it works differently than its counterpart in Java. Certainly, your JavaScript code is bug free, but even so: making sure this is bound to the object you intend it to be is a constant preoccupation, and creates more complicated APIs. Depending on the cases, I've resorted to declaring a var self = this, to Underscore's bind as in addListener(_.bind(function() { … }, this), or to creating APIs with additional parameters as is often the case in YUI. CoffeeScript's fat arrow elegantly solves this.
  • Using object oriented programming — I always loved functional programming, but there are case where classes are the right tool for the job. JavaScript discourages this approach by making it overly complicated. In contract, CoffeeScript gives you a simple and clear way to declare classes.
Those are just a few examples, and the whole is greater than it parts: you are left with a language that feels fresh, attracts rather than repulse, and I'm looking forward to write new functionality and refactor some of our existing client-side code using CoffeeScript.

Tuesday, March 22, 2011

Orbeon Forms 3.9.0 Release Candidate 1


We are happy to announce a release candidate build of Orbeon Forms 3.9!

Orbeon Forms 3.9 features over 300 improvements since Orbeon Forms 3.8.

Major improvements include:

  • Performance and reliability (including the new XPath dependency analysis engine)
  • Liferay support
  • A new implementation of the upload control
  • Updates to Form Runner, custom components, accessibility, the XForms engine, and more.

Don't miss the complete release notes.

The RC1 builds for both Orbeon Forms PE and Orbeon Forms CE are available from the downloads page.

Thursday, March 17, 2011

How writing in the cloud has improved the Orbeon Forms documentation

We have recently finished moving all our documentation to the Orbeon wiki, powered by Google Sites.

All the way back to 2003 (maybe 2002) the documentation of the Orbeon platform was written in a text editor with an XML syntax. Nicely structured markup has benefits, such as the ability to process files through XSLT and XML pipelines and to shift formats. But in reality we didn't make much use these capabilities.

On the other hand, we found that writing new documentation was tedious with that system. Worse, quickly amending documentation was a chore: you had to locate the XML in your code, type funny markup you had to constantly lookup, make sure a servlet container was started so you could see the result; then commit the result to version control, and check it out on the other side to make it available online.

In 2009, we started using Google Sites and writing all our new documentation there. What we have found is that the turnaround time is much faster this way (even as frustrating as Google Sites can be at times). You find a typo or a paragraph that sounds a bit out of date? It's fixed in a matter of seconds. You need to document this new feature? You are up and running immediately. That's the same process that allows Wikipedia to evolve so fast (Orbeon being a bit smaller than Wikipedia ;).

So all in all we are very happy to have made that decision.

Tuesday, March 15, 2011

Be persistent: if it fails, try again

Do you remember the last time you loaded a web page, the page started to load, but then stalled… after a little while, you hit that reload button, and the page showed up just fine. The browser reload button puts you in control when page loads don't go through. But what about Ajax requests?

You can't manually tell the browser "retry that last Ajax request"; only the JavaScript code that issued the request can, and so it is important that it does. The soon to be released Orbeon Forms 3.9 incorporates an automatic retry mechanism for Ajax requests:
  1. If an Ajax request fails or times out, Orbeon Forms client-side code automatically resends it to the server.
  2. If the request fails multiple time, the delay between each retry is increased (up to a maximum delay). This is done not to overwhelm the server with lots of requests, in case a number of clients experience failures at the same time, and then all the retries reach the server around the same time, for instance because a connection is reestablished.
  3. Imagine an Ajax request makes its way to the server, is executed by the server producing some side effect (for instance updating a database), but the corresponding Ajax response fails to get back to the browser. In that case, you would like the browser to be able to resend the request, and the server to resend the Ajax response it produced earlier without executing it again. Lucky us: this is exactly what happens with Orbeon Forms 3.9.
  4. And as a bonus: the same retry mechanism also applies to file uploads.
You don't need to setup anything for this retry mechanism to be active, but should you want to tweak it, see the section Retry mechanism for Ajax requests in the XForms configuration properties.

Tuesday, March 8, 2011

How Scala helps with Orbeon Forms unit tests

For the server component of Orbeon Forms, we started using the Scala language in addition to Java last year.

A killer feature of Scala for Java programmers is that it integrates very smoothly with Java. For example, Scala classes can extend Java classes an vice-versa, and all Java libraries can be used transparently from Scala.

This also goes for the JUnit testing framework that we use for our server-side unit tests, which run every time a build of Orbeon Forms is created (often that's several times a day!). Scala has a few test frameworks, and we picked ScalaTest, which can be used on top of JUnit.

Some unit tests that we need to write need as source a short XForms page, which must run through the XForms processor. Once the XForms document is "live", we need to poke it a little bit (for example by changing the values of some fields), and then test some assertions.

This is one area where Scala turns out to be very elegant, because the XForms page can be embedded directly in the Scala code. Here is an example of this:


With this kind of setup, it's (almost) a pleasure to write unit tests!

Tuesday, March 1, 2011

Out of the box sample data for the demo forms

Orbeon Forms comes with several demonstration forms, including the Bookshelf, Contact, and DMV-14 forms.

When you download recent builds of Orbeon Forms, you will notice that there is now sample data in these forms out of the box, especially the Bookshelf form.

How is this done? Orbeon Forms ships with an embedded eXist XML database.

  • Outside the build process:
    • We enter sample data into a locally deployed eXist database.
    • Then, with the eXist ant tasks, we export this data to disk, into a hierarchical structure committed alongside the source code in git.
  • As part of the build process:
And presto, by default when you start Orbeon Forms the database includes the sample data.


Bookshelf form with sample data