javascript

An interesting question has been raised on Linkedin Answers:

What is your opinion of formsPlayer, the XForms development environment, with regards to developing dynamically configurable UIs where throughput is critical?

Although phrased as a question about formsPlayer, it gets to the heart of important issues that concern XForms, so it's worth seeing this as a collection of separate but interrelated questions. The first question is essentially about how appropriate XForms is for developing dynamically configurable UIs, whilst the second relates to whether there are performance issues to watch out for. Having established whether XForms is suitable, the third question asks if formsPlayer specifically, is right for the job.

Since solving the problem of dynamic user interfaces is exactly the reason I got involved in XForms in its early days, this was bound to be a question I'd have an interest in, even if it hadn't mentioned formsPlayer.

Dynamic user interfaces

A number of years ago much of my work was based around content-management systems. Although my company built a number of different applications and took a number of different approaches to the problem, the common factor in everything we were investigating was the desire to create flexible user interfaces. We nearly always came up against the limitations of HTML in what we were doing, and as a result we nearly always found ourselves defining user interfaces in some hacked together UI language...until one day I stumbled across XForms.

XForms as a UI definition language

Initially we simply used XForms to define user interfaces, which were then translated into HTML. XForms was perfect for the job because it allowed UIs to be defined in an 'abstract' way, independent of any platform or system. This was important because other languages that could be used--such as XUL--were insufficiently abstract and focused too much on GUIs. (And although HTML is to some extent abstract, it just doesn't provide enough of a feature-set.)

In some ways both of these problems had already been overcome by defining our own intermediate forms language, but XForms was not only more powerful, it came from the W3C, and we felt it important to use standards (standards often lead to productivity benefits).

XForms as a run-time language

Of course it wasn't long before we decided that passing XForms through an XSLT processor in order to produce static HTML was nowhere near as interesting as processing XForms at run-time, and we decided to spend some time producing a run-time processor. We worked on a number of different architectures, all of which were useful in different contexts, but the one we decided to put most effort into was our browser extension, formsPlayer.

By putting XForms into the browser we were able to speed up our form development times (edit your form and press F5), as well as improve performance and the range of features that we could support. Other developers took other routes, and now, a few years on, there are a wide range of XForms processors, each reflecting a different approach to the architecture, and encompassing a variety of platforms; there are solutions for mobile devices (PicoForms and MoviForms), browser extensions for both Internet Explorer and Firefox (Mozilla XForms and formsPlayer), and of course sophisticated server-side transformation engines (Orbeon and Chiba).

(XForms processors can be built with such a broad range of architectures because of XForms' MVC structure, which I hope to discuss in another post.)

XForms and performance

Whilst it's clear that XForms is an ideal solution for dynamic UIs, it has to be said that it is not (yet) a silver bullet that will hide issues with the underlying architecture. Just as when building an ASP, JSP, Rails--or whatever--solution you need to get your architectural approach right for the task at hand, so too with XForms. Issues such as getting the right data at the right time, or creating modular and manageable forms, will still need to be taken into account.

One problem we see a lot in our consultancy work is that XForms gets treated as a programming language like Visual Basic, rather than a web-based technology. As a consequence, authors tend to create very large forms, often with numerous instances each importing a large amount of data on document load. This is often compounded by using XSLT to generate the forms, creating a great deal of avoidable duplication, and resulting in even larger forms.

These are not practices that an Ajax, Java or C++ programmer would follow whilst building an application, but because XForms is so powerful, it presents a great temptation to the author to create monolithic forms without consideration to what is going on 'under the hood'.

HTTP and concurrent requests

For example, most Ajax programmers--at least those who program to the metal--will tell you that there is no point in sending more than two concurrent HTTP requests to the same server, since the third and subsequent requests will be blocked by the browser until the first or second completes. This is not a browser limitation, but a consequence of the HTTP specification, and the effect is to slow down the loading of the main document if all the required images, stylesheets and scripts are placed on the same server.

If you look at Google Maps or Flickr, for example, you'll see that the image URLs make reference to lots of different servers; you may have assumed that this is to do with distributing server load, but it's not (that problem can be addressed in other ways), and is in fact to do with finding a way to allow browsers to load more external files at the same time, and so improve overall load time. If all Flickr images or Google map tiles were stored on one server then the elapsed time for loading four images into your browser would be the amount of time taken to load two images, one after the other. (I.e., two are loaded simultaneously, followed by another two.) But if those four images were each on separate servers, all four could be requested at the same time, and the elapsed time would essentially be halved.

Unfortunately, although XForms hides a lot of complexity from the author, this is the kind of thing that XForms can do nothing about--it won't matter what XForms architecture you use if the transport protocol is HTTP. This means that if you have a number of instances in your form, each loaded via the src attribute, the initial load time will be limited by the fact that only two instances can be loaded simultaneously. And since the UI won't usually be available to the user until all models are initialised, this could create a bad experience for the user.

Of course the good news is that XForms handles data communications asynchronously out of the box, which means that once the data has been obtained, any form controls that depend on that data will automatically be adjusted to reflect any new values. So provided that you get the underlying architecture of your application right, managing XForms itself is very straightforward.

Deferred loading (or 'Google Suggest')

Another common problem caused by XForms making some things just too easy, concerns very large selection lists. In XForms it's straightforward to populate a select1 from some XML data, by using the itemset element. The problem is that authors will often load the necessary instance data when the form first loads--well before it is ever needed--and worse, this data could be quite large.

Once again it's important to think about the principles we would have applied if we were writing a C++ or Java application--or even an Ajax one--that was going to obtain data from the internet. For a start we would probably consider loading the data only at the point when we needed it, or perhaps in the background, and in many situations we'd certainly try to load only as much information as was needed.

For example, if we have a large list of chemical compounds or part numbers for a car, there may be thousands or even tens of thousands to choose from. But by connecting a select1 to an instance that is populated with data from the server as the user types--as popularised by Google Suggest--we don't need to download so much data, and we also reduce the size of the list. (See XForms Patterns: Incremental and 'Google Suggest' and Using Google Suggest to Categorise del.icio.us for a detailed discussion of how this is done.)

XForms modularisation

None of this is to say that there are no problems with XForms, and that the only issues you'll ever have are to do with the underlying infrastructure, and as XForms is used for larger and more ambitious applications, there is a lot of scope for improvement at the mark-up level. For example, not only could we defer the loading of some of the data (as discussed above), but we could also defer the loading of some of the form. There is no mechanism in XForms for doing this at the moment, but much of the 'machinery' is in place in XForms 1.1, and it could be quite straightforward. (See Using subforms in XForms for some ideas on this.)

formsPlayer

The final question being asked is simply that if the first two questions are answered positively--i.e., if XForms is a good technology fit in applications that need responsive, dynamic forms--is formsPlayer a good choice as an XForms technology?

The answer to that question will depend completely on the architecture being deployed to, since as we've seen, XForms can be used in many different kinds of environments. For example, Chiba and Orbeon are both great server-side solutions. They work by translating XForms into HTML (or HTML plus Ajax) that can be processed by any browser. The key benefit of using XForms in this way is that it abstracts away much of the logic that would normally be trapped in RoR controllers, ASP scripts, Java servlets, and so on.

formsPlayer on the other hand, pushes all of the processing into the client, which has advantages when it comes to control over advanced functionality (we are able to do things that browsers cannot, such as save-and-resume, off-line working, PDF printing, and so on), but for the time being we only support Internet Explorer on Windows (although versions for other platforms are now being developed).

An interesting bonus of having full XForms support in the client, is that formsPlayer can be deployed not just in web-based applications as you might expect, but also embedded in other kinds of applications. For example, we have a customer that uses fP inside a .NET application that runs on Tablet PCs; this architecture allows them to use more conventional programming techniques for their processing logic (in this case C#), but to use simple XML tools to develop the complex user interfaces that are needed in their industry. In other words, they use XForms to give them more "dynamically configurable UIs" than C# is able to.

(It's worth noting that this is a real problem for everyone, and to some extent it lies behind the motivation for XAML. But in my view, XForms wins over XAML by being a standard.)

formsPlayer therefore meets a different set of needs to server-side solutions like Chiba and Orbeon, so as with any application, developers will need to work out for themselves which XForms architecture is the most appropriate for their project.

Regardless of the model used, it should be stressed that we are still dealing with only one language. Try finding another programming language which would allow you to write an application that could run in a browser or embedded in a .NET application or on a mobile phone...or even as a server-based application, without altering any of the code.