Thursday, July 21, 2005

About the OPS 3.0 XForms Engine

Two days ago we released OPS 3.0 beta. This is a great milestone for the open source Orbeon PresentationServer, because it's the first time OPS features an XForms engine with full support for events!

When we started designing OPS (then called OXF) back in the summer of 2002, we focused on two main things: the XPL pipeline engine and XForms. Our choice of XForms was motivated by the fact that we really did not want to reinvent the wheel, and that we have always believed we should choose standards whenever possible. However at the time XForms was still in its infancy at W3C, so our approach consisted in picking a few features of XForms we could easily implement server-side. There was born the first OPS XForms engine.

Between OXF 1.0 and OPS 2.8, we progressively added features to the XForms engine, based on users' needs, including our own. However, XForms events were nowhere to be seen, which left us a little bit uncomfortable since events account for a very large part of the XForms 1.0 specification.

Then came Ajax. Like everybody else, we had been doing Ajax forever at Orbeon. Back in 1999-2000, our Virtual Browser project had a user interface with underpinnings which were very much Ajax-like. However, to be fair, there was nothing of the sort in OPS. But the Ajax craze made us realize that we had now a mature solution to implement XForms events in OPS in a responsive way.

So we set to work, heavily refactored the OPS 2.8 XForms engine, designed a compatilibity mode in OPS for legacy applications, and updated the architecture of the Page Flow Controller which would accomodate the new XForms engine. The architecture, based around the concept of XML submission, turned out great! In just a few days of work, we had a functioning Calculator example. In another four weeks, we had a decent Ajax-based XForms engine with support for most XForms events and actions, the Switch module, and more, enough to do some pretty cool demos at XTech 2005. It then took us another 6-7 weeks and here we are with OPS 3.0 BETA!

Now this is actually quite exciting because the approach we have chosen for our XForms engine makes it different from the competition. Other XForms engines are available in the form of plugins (FormsPlayer, for example), native browser implementations (the in-progress Firefox XForms implementation), or pure Javascript implementations. Chiba is a pure XForms engine which can work as a pure server-side implemenation (non-Ajax at the moment) or as an applet on the client. The Ajax-based OPS implementation is in fact hybrid, with a light client-side module written in Javascript communicating with a heavier server-side module written in Java.

In short, what are the benefits of the OPS way?

  • Deployment is trivial: there is in fact no deployment at all, as OPS is using stock web browsers.

  • Upgrades are easy: update the server-side code, and your XForms engine is updated.

  • Code is light on the client: the Javascript running on the client is much simpler than a full-fledged Javascript client-side implementation, or than a Java applet or Flash-based implementation.

  • Extensions are easy: because the XForms engine can leverage the entire Java platform, it is possible to easily build extensions to XForms. For example, it is trivial to add XPath 2.0 support (in fact this is already supported in OPS 3.0 BETA).

  • Optimizations are possible: for example, an option to keep state information on the server could be implemented. Large XForms instances could be kept on the server instead of being sent to the client, resulting in smaller pages and increased confidentiality.

  • Other XForms engines are not ruled out: you can decide with OPS to send native XForms directly to clients that support XForms, and to use the OPS XForms engine for clients that do not.

  • Time to market is shorter: this could is in fact be considered an implementation detail, but because the hybrid architecture chosen for OPS delegates most of the hard work to the server, development of the XForms engine is much faster: developing in Java gets you a strongly typed programming language, powerful tools like IntelliJ or Eclipse with incredible editors, debugging and refactoring, profiling tools, myriads of available open source libraries, and more. We argue that it is much faster to write an XForms engine in Java than in Javascript, Flash, or C++!

I probably forget some benefits, but you get the gist of it. Of course, to be fair, there are some drawbacks too, since any Ajax-based architecture requires communication between the client and the server. It is going to be up to application developers to evaluate how their use of XForms events in particular impacts the latency of their XForms-based application and the load of their server. But for sure, said latency and load can be smaller than by doing full client-server roundtrips that reload pages entirely, as is today customary for many web applications. And finally, this is the first version of the OPS hybrid XForms implementation, and optimizations can certainly be achieved in the future.

Don't forget to go check out the beta. The OPS examples are online, and the downloads are at ObjectWeb as usual.

Spell Checking With Google: The Web Service

Remember that old book called a dictionary? Once upon a time, this is what we had to use to check the spelling of a word. Now instead, we can use the spell checker that comes with the free Google Toolbar for Firefox and IE. After you install the toolbar, click on the Check button of the newly added toolbar: the content of every text field and text area on your page will be checked, and spelling errors will be highlighted. Click on a highlighted word and a drop down with appear with a number of suggestions.

This is nice tool per se. But if you are looking at the requests made by your browser while you are using the toolbar, which is extremely easy on Firefox using the LiveHTTPHeaders plugin, you will notice something even more interesting: the web service behind the toolbar. How does it work? The toolbar posts on an XML document that contains the text to check on http://www.google.com//tbproxy/spell?lang=en&hl=en. The document looks like:

    <spellrequest textalreadyclipped="0" ignoredups="1"
            ignoredigits="1" ignoreallcaps="0">
        <text>what is the speling of exemple?</text>
    </spellrequest>

To this request, Google responds with this XML document:

    <spellresult error="0" clipped="0" charschecked="30">
        <c o="12" l="7" s="1">spelling spieling sapling spilling spoiling</c>
        <c o="23" l="7" s="1">example exemplar exampled examples exempt</c>
    </spellresult>

Simon Willison noticed this a few days ago and wrote an entry about it in his blog. This opens the door to a number of interesting hacks. Do you feel inspired? (Calling this service directly from your code might violate the Google EULA, so you might want to check it out to see how you feel about it.)

Wednesday, July 20, 2005

WYSIWYG Programming for XSLT, XQuery, XPL, and More

Yesterday, I decided to write some code to generate an RSS feed from our project news page on the ObjectWeb Forge. It was a simple matter doing some screen scrapping and generating XML based on the collected data. I chose to go with XQuery as it was a perfect language for the task: the doc('http://site.com/page') function makes a web page accessible as an XML document from which it is easy to extract data and generate RSS.

The final code is about 30 lines long, and while this is no rocket science, the code is full of little details. Getting those 30 lines right is an intense trial and error process. This is when the XQuery Sandbox came to my rescue and made my job much easier. Instead of having to constantly switch between an editor and a browser to see the result, I could type the XQuery code in a web page, and see the result as I was typing it, without even having to click on a "submit" button. Give it a try! And if you are interested in other languages, we also have an XSLT Sandbox, an XPath Sandbox, an XPL Sandbox, and an XUpdate Sandbox.

Those sandboxes use Ajax: the browser sends XML data to the server, which executes your program and sends back an XML response to the browser. Dealing with Ajax can be pretty complex, and you might think that creating those sandboxes pages must have involved a respectable amount of work. Think again: they are all written in XForms, and their code incredibly simple, while the heavy weight lifting is left to the XForms engine in PresentationServer.

Tuesday, July 19, 2005

OPS 3.0 BETA Released

OPS 3.0 BETA Repeating Controls

It is with great pleasure that we are announcing that OPS 3.0 BETA is out!

The major novelty is much improved XForms 1.0 support. OPS has implemented a subset of XForms since its first release about three years ago, but this is the first time OPS can boast support for XForms events, an important part of the XForms 1.0 specification. This is made possible thanks to a new Ajax-based XForms engine.

Try for example the XForms Controls, Repeating Elements, Calculator, and BizDoc NG examples. Other cool examples include the Translate This example and all the dynamic sandbox examples you will find in the OPS examples portal.

The purpose of the OPS 3.0 BETA is to provide a first glimpse of the OPS 3.0 functionality, while OPS developers keep ironing out the last bugs and finishing up the documentation. During the beta period, we are looking for as much feedback as possible related to all the aspects of the beta release, so please go check it out. Also, don't forget that OPS is an open source project looking to grow its community of users and developers!

As usual, you can download this version of OPS from the ObjectWeb Forge. The full list of changes is available here.

Please use the ops-users mailing-list for questions feedback about OPS 3.0 BETA.

Thursday, July 14, 2005

XForms on Mobile Devices

As I wrote recently on the Wikipedia XForms page, implementing XForms in mobile devices provides a number of benefits:

  • User interfaces using XForms require less round trips with the server and are in that sense more self contained than user interfaces using HTML 4 forms.
  • Capabilities of mobile devices vary greatly; consequently the amount of the work involved in generating different user interfaces for different devices is of particular concern in the mobile world. XForms has been designed from the ground up to allow forms to be described independently of the device, which reduces the amount of work required to target multiple devices.
  • XForms reduces the need for JavaScript, which is particularly interesting as JavaScript is in general not available on mobile devices.

Despite those benefits, XForms on mobile devices is still an emerging technology at best. Jon S. von Tetzchner, CEO of Opera, producers of the leading browser for mobile devices, says his company is currently considering support for XForms but that in his mind Webforms 2.0 makes more sense on the client side. So far, only IBM and Oracle has produces significant initiatives:

  • IBM Forms for Mobile Devices is an implementation of XForms that run on Palm-powered devices and shows how XForms can be used to create form-based enterprise applications running on mobile devices. This package has been released by IBM on alphaWorks, their site showcasing emerging technologies.
  • Oracle Wireless Client has released a preview of their Wireless Client in March 2004. Despite its name, the preview contains no software that run on a mobile device. Instead, it is delivered in the form of a plug-in for Internet Explorer, hence maybe the "preview" in the name. The plug-in run XForms client-side, just like the browser would if it supported XForms natively.

Are we going to see the XForms technology being picked up soon by major players in the mobile market? Even if this happens, it will be years before XForms becomes widely available on handsets. In the meantime, those application developers who understand the benefits of XForms can either require users to install an application that understands XForms on their mobile device (similar to the plugin approach for browsers) or rely on a server-side XForms engine that will transform their XForms code into an appropriate format understood by mobile devices, like Orbeon PresentationServer does right now for desktop browsers.