| Table of Contents |
|---|
Introduction
There are many opportunities surrounding Fedora to create user interface experiences. Many times it is preferred that these interfaces be deployed via a web browser. One specific example of this is seen in the plan to replace the Some examples of potential interfaces to build using these tools are a replacement Fedora Administrative GUI with a web-based solution, a Fedora Share application, object builder applications, and server monitoring applictaions. This comparison considers the capabilities and benefits of several tools for building rich internet applications. The goal of this comparison is to aid developers in determining the appropriate tool(s) to use when building UIs for Fedora. Since many of these tools will need to work directly against the existing Fedora REST and SOAP APIs, special attention will be given to each tool's ability to connect to these services.
Disclaimer
These write ups are generally completed after conducting research about the tool and experimenting with using it for a day or two. If you have implementation experience with a particular tool feel free to add notes or comments.
...
Flex has a wide industry adoption, the flex showcase alone lists around 500 sites built using Flex. The open sourcing of most parts of Flex seems to have encouraged use. The SOURCE Fedora interface will be using Flex. The RepoMMan project used Flex.
General Impressions
I was impressed by how quickly and easily my test application came together. I appreciated being able to run the end product (a .swf file) directly in a browser (with the latest Flash plugin) without even needing to deploy it to a server. I came away with the impression that, once you get used to MXML and ActionScript you could do a lot in a short amount of time. It's nice that, in general, the application looks pretty decent even if you're not a graphic artist. There tends to be at lot of focus on getting, displaying, and working with data from a server, particularly XML data, which is very useful. A primary drawback is the requirement for the client to have the latest Flash player.
Open Laszlo
Overview
Open Laszlo is a framework for building rich internet applications which can be deployed either to Adobe's Flash player or as DHTML in the browser.
...
In comparison with Flex, an obvious benefit is the ability to use DHTML rather than Flash. Unfortunately, it It took twice as long and significantly more code to create essentially the same application with Laszlo as with Flex. The documentation for Laszlo is not as comprehensive as what is available for Flex.
Google Web Toolkit (GWT)
Still to come...
AJAX libaries (Dojo, Rico, etc) with HTML, CSS
...
Overview
The Google Web Toolkit is a development toolkit for creating AJAX-based web UIs which are written in Java and compiled to javascript for deployment.
Sample application
I spent about a day and a half attempting to create a sample application. In that time I was able to achieve a textbox which accepted a PID and queried for the object's xml, datastream list, and dublin core. The data all came back in xml, as long as the app was running on the same host/port as the Fedora server, but unfortunately either the xml parsing or widget display components did not cooperate well enough to actually display anything. What did display was very ugly, which is why there's no screenshot. This all could have been fixed if I'd had the time to spend.
API
UI code is written in Java in a style similar to Swing. Basic widgets and layout options are available with extension libraries providing a richer set.
Communication is limited to the server and port from which the UI is served, so allowing the server to perform any external communication to REST/SOAP/etc interfaces is the expected technique.
Debugging is performed using "hosted" mode where the UI is constructed on-the-fly in the vm and pushed to an embedded tomcat server, allowing you to debug directly in the java code. This is somewhat useful while in development, except that the UI output is not quite the same in hosted mode as it is when it is compiled to javascript. Debugging a deployed application would be very difficult as the javascript code is optimized to reduce transfer time.
Documentation
Documentation is good, at least for getting started. There is Javadoc for all classes provided by Google.
Development Languages
Development is in Java, which is familiar, but tends to require a lot of code to do simple things like implement action handlers and provide callbacks. Since Java provides many capabilities that javascript does not, only parts of the standard Java libraries are supported, meaning that care must be taken to not use classes/methods/types/etc which are not supported. The ability to use external libraries is limited.
Styling is done via a combination of external CSS and embedded component styles.
Deployment schemes
Java code is compiled to Javascript using XML config files. Along with the Javascript are HTML and CSS files (which can be edited directly). All of these together comprise the application which can be served from any standard web server.
Open source?
Completely open source.
Client requirements
Enabled JavaScript is required.
Market penetration
Based on the Who's Using GWT page, user groups, and other websites, it appears that while GWT has generated significant buzz, there's not much happening in the "real" application space. There are several recently published books about GWT.
General Impressions
Being able to work in Java in a manner resembling Swing is nice, but it also reminds me how long it takes to create even a simple UI. Learning how to use all of the GWT-specific classes (and learning which standard Java classes and libraries to not use) would take time similar to that of learning how to use components in an XML syntax. Not being able to access REST or SOAP interfaces directly without being on the same host/port is a major drawback.
Others
Echo2/3
Similar to GWT except that rather than compiling to Javascript, the Java code runs on the server, producing the UI and storing state on the server side. See: Comparing the Google Web Toolkit to Echo2 . Creating an application which runs only on the client is not possible with Echo.