In Tim Berners Lee's proposal for a hypertext project, he conceived of the Web as a medium for sharing documents. All the concepts revolved around retrieving documents from and posting documents to the server. Berners Lee saw the need for this venture due to the large number of documents at CERN and the lack of an established way to navigate through them: “HyperText provides a single user-interface to many large classes of stored information such as reports, notes, data-bases, computer documentation and on-line systems help,” he wrote.

With hypertext the World Wide Web was born, but the technology that the hypertext revolution brought into existence was far too powerful to be limited to just storing and retrieving documents. Technologists and geeks around the world began to break the limitations and came up with far more interesting things to do with the Web. What began as “Remote Scripting” (coined by Microsoft in 1998) and Rich Internet Application (coined by Macromedia in 2002) became all the rage with AJAX.

The World Wide Web had evolved from a medium for sharing documents into a medium for distributing networked applications, or Web 2.0 (coined by, well, everybody). Through all this, it became clear that there was a need for better tools to develop more interactive applications. Before too long, there were a flurry of new AJAX toolkits around, including GWT, Dojo, ATLAS, echo and so forth. OpenLaszlo is a recent, open-source addition to this group.

I stumbled upon OpenLaszlo through my work on a project called Cached Web Application. The vision of this project is to gradually step towards the "Global Internet Brain" described in the paper “The Global Brain As An Emergent Structure From The Worldwide Computing Network, And Its Implications For Modeling," by G. Mayer-Kress and C. Barczys. This paper proposes an Internet in which all the information stored on the various servers is acted upon by user agents in ways beyond the creator’s imagination.

Our study so far has suggested that a mixed model, incorporating the hyper-linked nature of the web and the data-driven nature of traditional networked applications, works well. To achieve this we've studied a number of Rich Internet Application formats, OpenLaszlo among them. In this article, I'll present my findings and compare OpenLaszlo to some of its peers.

OpenLaszlo Architecture
OpenLaszlo is an end-to-end system for creating Rich Internet Application. The Laszlo Presentation Server (LPS) operates as a servlet running in the server, which compiles source code into swf files upon client request and outputs a representation. Apart from compilation, LPS also manages persistent state and data transfer to and from the client. LPS comes into play only if you deploy your application as proxied.

You can also choose to deploy the application in the SOLO option, in which the source code files are pre-compiled to swf files. The swf files can then be deployed normally like any other swf files. Although the documentation recommends the SOLO mode of deployment, due to performance reasons and ease of deployment, a proxied application gives you more power to work with. Since only the first request would require compilation and subsequent requests can be met from a cache, I believe the performance cost due to compilation shouldn’t be too much of an issue.

Regardless of how you deploy the application, the client will always be an swf file. Note, though, that the application does not use any of the Flash services or objects. Instead all the functionality – and there is a wide range, including timers, data-binding, animation etc. -- is provided by Laszlo Foundation Classes (LFC). These classes are actually present and included in every swf file. Accordingly, one of the drawbacks is that the application can become bulky. A simple “Hello World” application is 72K, for example. Hopefully OpenLaszlo will not expand on these classes or, if they do, hopefully they will limit the number of required classes to as few as possible.

Basic installation of OpenLaszlo was neat and one-click. There was no post-installation configuration needed to get it up and running.

LZX Programming Language
OpenLaszlo uses the LZX Programming Language, which is a mixture of XML and Javascript. All code should look like this:

 <canvas> 
    <dataset/> 
    <script/> 
    <resource/> 
    <class/> 
    <components> 
       <handler name="eventname" method="methodname"> 
          !<[CDATA[ 
             Your Javascript here. 
          ]]> 
       </handler> 
    </component> 
    <view> 
       <layout/> 
    </view> 
 </canvas> 

Script, class, resource, component and view are all optional (though there wouldn’t be an application without them). The script tag is meant for adding arbitrary codes and functions. Class, as the name suggests, creates classes (and yes, OpenLaszlo is object oriented). View represents the visual element of LZX. All the visual elements are present in the View and View is the super class of all the classes.

Components are comparable to user controls in Visual Basic, and include buttons, windows, texts, edit boxes, and a lot more. Components add all the functionality to your applications, and are themselves classes. Although all the components could be put straight onto the canvas, there is little incentive to do so since maintaining the layout would become difficult.

Layout is not a tag as such, but I included it to represent all the classes of layout like simplelayout, hbox and vbox, stableborderlayout and constantborderlayout. Although combinations of view and layout offer complete control over the layout, you may find this approach frustrating due to complicated multiple nestings. This is where the IDE's help: A WYSIWYG IDE can arrange all the elements on the canvas.

All views receive events, and are handled using the handler tag. The handler tag encloses the javascript for handling the event. There can be more than one handler for a single event, but in those cases all the handlers will be evoked. Make sure your handler javasript is marked by CDATA. This will ensure the parser won't try to parse this and mistake a usage of "<" within the script as the beginning of a tag.

The name attribute identifies which event the handler is handling. Alternatively the method attribute can contain the name of the method that will be fired to handle the event. This mode of handler can be used when multiple events are being handled the same way.

Dataset is a feature that adds data support to the application. It is equivalent to XmlHttpRequest but is conceptually different and neater in several ways.

One nice addition to the language is Constraints. Often, codes are included just to say things like "resize the width because the container's width changed." Constraints are expressions that are continuously evaluated and whose value is stored in an attribute. For example:

<view width="$(parent.width - 10}"> 

will make the width of the view always 10 less than the parent's width.

Object-Orientation
As noted above, OpenLaszlo has object-orientation. Classes are created using the <class> tag. Classes can have attributes and methods declared. While all classes inherit from View, the inherited methods can be overridden. Also, as is characteristic to Javascript, the methods of the objects created can be individually overridden, and objects can also have additional methods. In other words, this model operates as classes that guarantee the presence of methods and attributes without limiting the objects to those methods and attributes. A class will look like the following:

 <class name="ClassName" extends="SuperClass"> 
    <attribute name="Name" type="Data Type"/> 
    <method name="methodname" arg="argument list"> 
       !<[CDATA[ 
          Your Javascript here. 
       ]]> 
    </method> 
    <handler/> 
    <event/> 
    <state/> 
 </class> 

The attribute name is used to create instances of the class. If no superclass is specified then View class is the default super class. The attribute and the method tags are self-explanatory. Handlers are as described before, though it's worth noting that new custom events can be created.

This is how instances are created:

<ClassName name="instancename"/> 

You can also create the instances using script. Each instance can have a name or an id. The difference between the two is that name has to be qualified with its parent name while id must be unique. These two forms of names give you the best of both worlds – using a unique id eliminates the risk of a name conflict, while using consistent names makes it easier to use frequently referred-to components.

There is one more feature that is a great addition to the language overall, called state. Every application can be imagined to be in some state. If you want some piece of code to be executed only when those states are applied, you use this feature. The documentation on OpenLaszlo includes a neat example on drag and drop that uses state.

Data Set and XPath
Data Set is OpenLaszlo's most innovative and powerful feature. A DataSet is an entity in your application that represents an xml file. What it refers to and how it is included is hidden in the abstraction. Essentially, it implement an asynchronous http request, but itsfunctionality exceeds that. DataSet can bind to information in three ways: embedded, included and HTTP data. In embedded mode the XML data is hardcoded into the source and referred to later on. In included mode, the XML data is a static file, which is requested when the application is loaded. The HTTP data mode, however, is the most flexible and useful of the three – here's how you declare it:

<dataset name="mydataset" type="http" src="URL" request="true/false"/> 

The URL can be anything: a server side script, CGI, a static XML file etc. If the request attribute is true, the data is fetchedas soon as the application loads. To send a request manually, the mydataset.doRequest() method is invoked. Further, mydataset.setQueryString() can be used to set the query string. There are also a number of other interesting methods for powerful feature access.

There are three events raised by DataSet: ondata, ontimeout and onerror. ondata is raised when the request is complete. It is equivalent to HTTP Status 4. ontimeout occurs when the request takes more than 30 seconds to complete. You cannot change the ontimeout expiry time to anything else but there is a documented hack on how to make it expire is less than 30 seconds. The onerror event is raised when the server returns any error.

Once you have the dataset, XPath can be used for data access. This will make more sense with an example -- suppose you had an XML file like this:

 <topcoders> 
 <coder> 
    <handle> Petr </handle> 
    <rating> 3500 </rating> 
 </coder> 
 <coder> 
    <handle> tomek </handle> 
    <rating> 3400 </rating> 
 </coder> 
 </topcoders> 

Now topcoders:/coder[1] refers to the coder 1 XML, which is Petr and his rating, and topcoders:/coder[1]/handle refers to his handle alone.

This is called a datapath, and it is used to fill up the values of various components. For example:

 <dataset name="favcoders" src="topcoders.xml"/> 
 <view datapath = "favcoders:/coders[1]"> 
    <text datapath = "handle/text()"> 
    <text datapath = "rating/text()"> 
 </view> 

The output of this is

Petr 3500

Neat, isn't it? You could make a method call favcoders.doRequest(), and the values of the text would be automatically updated. This could allow you to do a number of complex things, and the documentation of OpenLaszlo includes a lot of detailed information on databinding. If you've worked with Visual Basic, you can probably relate dataset to datasource and datapath to the datafield attribute of the controls. The difference here is that dataset acts on XML, whereas the controls in VB act on a database.

You should be very careful using datasets, especially since OpenLaszlo's debugging mode doesn't always catch errors related to datapaths. Generally I would advise people to create an embedded dataset first, test your application to the maximum with it and then change the dataset mode to HTTP.

Although the documentation says dataset can be procured from a remote source, the example it cites doesn't actually work. At the same time Flash disallows cross-site request for security reasons (unless the domain you are requesting to has crossdomain.xml, which allows it). My conclusion is that this is an error in the documentation. That said, you can work around this problem with server-side caching of remote data.

Testing and Debugging
OpenLaszlo has some built-in debugging support. To enable debugger in your application, set the debug attribute of the canvas tag to true.

 <canvas debug='true'/> 

This will bring up a debugger window that displays a log of runtime errors, like referring to non-existent methods and attributes.

One interesting thing to note is that there is no division by zero error. Instead the expression evaluates to infinity. The number of runtime errors is few and needs some improvement, especially with datapath. Despite all this, the inherent features like method trace, backtrace, and stack dump provide enough tools for relatively efficient debugging. In addition, there is an additional debugging feature which traces all unused objects to detect memory leaks.

OpenLaszlo has a testing feature with the spirit and feel of JUnit. The Testing objects are included with the following line:

 <include href="lzunit"/> 

A TestSuite is a collection of TestCases, which are collections of textXXX functions.

 <TestSuite> 
    <TestCase> 
       <method name="testXXX"> 
       </method> 
       <method name="testXXX"> 
       </method> 
    </TestCase> 
 </TestSuite> 

Tests are run in the order they are written, but a longer test can sometimes finish later than a smaller test. Hence the test starts are synchronous but tests may end asynchronously. A global flag can be set to make the entire process asynchronous. As you might expect, there are also setUp and TearDown methods that get executed before and after every tests.

Comparison
So, how does OpenLaszlo stand up to the competition? The following table compares it some similar Rich Internet Applications: GWT, Dojo, Atlas and Yahoo UI library.

Future enhancements for OpenLaszlo include supporting multiple deployment runtimes (currently in beta, with OpenLaszlo 4) and, through a collaboration with Sun code-named Project "Orbit," enabling OpenLaszlo applications to run on devices like cell phones and PDAs that are powered by Java ME.

Conclusion
Using OpenLaszlo entails some trade-offs. For example, as a staunch supporter of the WWW architecture standards, I found it difficult to digest yet another setback to bookmarking. A DHTML version of OpenLaszlo may add bookmarking, but then DHTML itself is not a W3C standard. In addition, some argue that it is inadvisable to build an application entirely on a third-party plugin, though it's worth noting that the Flash Player is almost as widespread as Internet Explorer itself.

However, I believe that OpenLaszlo can be a useful tool for accelerating Rich Internet Application development and that, when used discreetly, the features that it offers justify these trade-offs. With the support of the open source community behind it, OpenLaszlo should continue to evolve and improve. If you're looking for a Rich Internet Application toolkit, and have some flexibility in what you can use, then I'd encourage you to give OpenLaszlo a look.