Mike Davis's Weblog A blog of what I'm learning and thinking as I go through my days at Sun.

An AJAX framework Review - NextApp Echo2

I've been doing a lot of prototype work recently for some new products that we are building within the new SysNet organization of Sun Software. I've taken this as an opportunity to expand my horizons a bit in a few different areas by using some new frameworks and technologies as part of the prototype work. In particular, I've been using the latest version of the Spring Framework (Spring AOP, MVC, Data Access, and Web Services), and have been digging into a number of the new AJAX frameworks. I figured I should write up my experiences around these as I go, so this is the first installment of that. Here I'll discuss my experiences using the NextApp Echo2 Web Framework.

First an overview (snippet from their website):

Echo2 unifies AJAX technology with a practical server-side framework to create a next-generation web application platform. For web application developers, Echo2 provides a familiar and powerful component-oriented framework that promotes event-oriented design similar to traditional thick-client user interface toolkits like Java Swing or Eclipse SWT. Echo2 leverages AJAX technology to deliver rich internet applications that create a user experience normally reserved for desktop-based applications.

It was the component-oriented and event-oriented and Java Swing-esque model that really drew me to this framework. I am not a Website developer, nor am I a web designer. If you've seen any websites I've built you would know that immediately! So to be able to program a website (containing lots of JavaScript especially) using the familiar Java language and pre-built components and a solid event model was intruiging to me.

The task that I decided to use this framework for was to build a prototype viewing UI for demo purposes. The majority of my current prototype is pretty boring to demo, it all runs in memory and does its thing. There is the verbose logging that you can watch scroll by to know that something is happening, but that is a bit difficult to make heads or tails of what is happening. The prototype makes use of 3 memory based backing stores that are essentially state machines that track the state of different objects representing systems and software products that register, get enabled, and invoke services. Each of these state machines is fronted by a web service which provides an functional abstraction on top of them. So the deom UI that I wanted to build using Echo2 would integrate with the functional services to access the state store and display the dynamic state of all objects. This seemed like it has a perfect AJAX, dynamic updating, web UI potential.

To get started I added the 3 Echo2 jar files to my project. The Echo2_App jar is the main framework for building an application. It provides things like the main ApplicationInstance, which is the mother of all objects in an application; all of the UI type objects like windows, layouts, tables, labels, fonts, etc., a lot like AWT classes (in fact in the little context popups while coding in my IDE, the classes were typically available as java.awt and nextapp.echo2.app); and the thing that I wanted the most, the task related objects which allow you to build the dynamic updating features into your webpages using this framework. The next jar was the Echo2_WebContainer which provides things like generic servlet implementations and the ability to control client interaction with the server side objects. Finally, there is the Echo2_WebRenderer jar that provides the basics for rendering html, I didn't really have to use any of this though.

With the basic implementation I created this framework was pretty simple. I had a simple, dynamically updating web page up within minutes. The rest of my time was spent with the layouts of the page s that I could display the data that I really wanted to in a nice looking format. This proved to be more of a pain than I had anticipated. Although I did get it working, I wouldn't claim that it looks pretty still! (I am also not a Swing programmer, in fact I am not a UI person at all.) The pain really comes in the fact that there is an object for every aspect of a UI. I first create a window, then a layout, then a table, then a table cell, then a label for the table cell, then I add formatting objects to everything, etc.. A simple html for this might look like:

<html>
<head><title>My Web page</title><head>
<body bgcolor="white">

My Data!
<table border="1" width="50%">
  <tr>
    <td cellspacing="5" cellpadding="5">data</td>
    <td cellspacing="5" cellpadding="5">data</td>
  <tr>
</table>

Window window = new Window();
window.setTitle("M Web page");

ContentPane contentPane = new ContentPane();
window.setContent(contentPane);

Grid fullWindowGrid = new Grid();
fullWindowGrid.setId("FullWindowGrid");
contentPane.add(fullWindowGrid);

Label clientAreaLabel = new Label("My Data");

TableModel model = new ClientTableModel();
Table table = new Table(model);
table.setId("ClientTable");
table.setDefaultRenderer(Object.class, new GenericTextRenderer());
table.setBorder(new Border(1, Color.BLACK, Border.STYLE_GROOVE));
table.setWidth(new Extent(50, Extent.PERCENT));
		
contentPane.getComponent("FullWindowGrid").add(clientAreaLabel);
contentPane.getComponent("FullWindowGrid").add(table);

And this doesn't even include the TableRenderer class and the TableModel class which give me the actual data to put in each cell and how that cell should look.

My overall conclusion was that it was relatively difficult to create a nice looking layout using this framework, although that is something that would probably be more natural to a Swing developer, and there are a lot of things that could easily be done to create the layout based on xml files and stylesheets (this framework does have support fo stylesheets although I did not use that feature). Once you have a layout that works it is extremely nice and very powerful to have a full event based model that you are in complete control of. It is also blindingly easy to get dynamic updates on a webpage and have those be efficient. Instead of refreshing a whole page or large sections of the page, the framework makes it simple to refresh individual components like a label, or the background color of a table cell, or anything like that, all based on incoming events and notifications.

So there's good and bad to this framework. I think I would consider using it again for applications that don't have overly complex UI layouts. This would be very difficult to use if working with a designer that was handing off designs that were in a state of flux. It does not easily allow for that separation of roles that J2EE was trying for with JSP, EJB, etc. It works great for quick prototypes, but there seem to be some easier toolkits out there. One other thing that concerns me about this framework is that it seems like it would be difficult to utilize some of the other AJAX UI component toolkits out there, like the Google toolkit and others that provide client side components.

One final note on this framework, is that NextApp does have some sort of GUI designer tool that I did not try out. It presumably makes a lot of the layout issues I talk about here, moot. Posted by mikedav ( Sep 15 2006, 10:27:10 AM PDT ) [Listen] Permalink