Direct Ajax - Goodbye to Ajax Deadly Sins

Java Development News:

Direct Ajax - Goodbye to Ajax Deadly Sins

By Robbie Cheng

01 Oct 2008 | TheServerSide.com

Deadly Sins of Rich Internet Application!

Let me begin with a story about my friend, a tech lead at a small business company. He was assigned to enrich his company's "Expense Claim" application with Ajax technologies. At first, he planned to deliver the application in 3 months, but it wound up taking him 6 months. Here are some of Ajax deadly sins that delayed his project:

  • Browser Incompatibility Firstly, he decided to develop in-house JavaScript codes for the UI, the first draft of which took his team 2 months to finish. Then he discovered that the layout was a mess on different browsers. Due to a lack of JavaScript knowledge, he then decided to adopt an off-the-shelf Ajax widgets framework along with a Java-to-JavaScript framework in order to overcome this browser incompatibility issue; that, of course, meant re-building the UI from scratch.
  • Tedious Client Server Communication Codes Just when it appeared that his team had escaped from the nightmare of JavaScript, there came an even bigger challenge related to integration between the UI and the back-end. The Java-to-JavaScript framework required RPC calls to get data from the server, and handle the returned data manually. It produced numerous files to communicate between the client and the server. Though developing in pure Java, his team spent a few more months finishing the integration.
  • Slow Performance During testing by their users, it was discovered that the performance was unacceptable; users had to wait for more than 10 seconds for 10,000 records to be loaded. Even worse, some old computers actually stalled. Unfortunately, they had to implement load-on-demand to improve the performance issue. But, load-on-demand was never an easy job. It required determining the visible area at the client side, prompting required data from the server side, and rendering the data on the browsers. To fulfill this requirement, his team had to delay the project a few additional months.
  • Maintenance Headache Later in the project cycle, he was informed that extra fields would be added to the data model. This was really a nightmare for his team since they not only had to modify the back-end codes, but also the associated client codes. They spent another month on maintaining the consistency of business logic between client and server codes.

Trouble Maker: Primitive Programming Model

Most of these problems seemed to be caused by a primitive programming model which separates the UI and the back-end of the application into two sides, as illustrated:

The two-sides programming model brings a lot of troubles for developers since they have to take care of the following process-unrelated works by themselves:

  • Browser incompatibility No longer an issue, solved by any modern Ajax frameworks
  • Client-server communication Displaying data on the client by retrieving data from server
  • Slow performance Developers tend to put too much data on the client
  • Business logic inconsistency between client and server Replication of business logic on the client

The ideal programming model should save developers from these cumbersome works. To resolve all of the above issues at once, the UI and the back-end of an application should never be separated. Instead, they should run on the same side, either the server-side, or the client-side. To improve developer productivity, and easier access to server resources, the application should run on the server only. The ideal programming model should look as follows:

Developers should simply focus on the business logic of their application, and the rest of job should be handled by the adopted framework, automatically. Ultimately, the best way to use Ajax is to not even know it exists! I will name the framework Direct Ajax because application can access user interfaces, database, and all kinds of resources directly. Direct Ajax provides developers an easier way to create rich Internet applications without being bothered by process-unrelated jobs.

Direct Ajax

The architecture of Direct Ajax looks as follows:

The UI and the back-end of an application are integrated seamlessly, and Direct Ajax is responsible for rendering the content to the client, and automatically synchronizing the state between client and server. Direct Programming Direct programming should fulfill the following three criteria:

Direct UI Access The application can get and set values from UI directly. Here is the pseudo code,

 <zscript>
 void draw(int x1, int y1, int x2, int y2) {
  LiveImage li = new LiveImage(400, 300, LiveImage.TYPE_INT_RGB);
  Graphics2D g2d = li.createGraphics();
  Line2D line = new Line2D.Double(x1, y1, x2, y2);  
  g2d.draw(line);
  image.setContent(Images.encode("test.png", li));
 }
 </zscript>
<image id="image">
<button onClick='draw(10,10,10,10)'/>

Once the user clicks the button, there appears an image on the browser. It's straightforward. No more XMLHttpRequest, and RPC call. No more pitcher-and-catcher game between client and server.

Direct Database Access

Secondly, the application can access the database directly. The following example illustrates a simple scenario to get data from database.

Hi. <label id="name"/>
<button>
  <attribute name="onClick">
  User usr = Database.getUserById(1);
          name.setValue(usr.getName());
  </attribute>
</button>

Once the user clicks the button, there appears a welcome message. The UI and backend are integrated seamlessly.

Direct Live Data

With live data, developers could separate the data from the view. Developers only provide the data by implementing the ListModel interface rather than manipulating the grid directly.

<zscript>    
    String[] data = new String[1000];        
    for(int j=0; j < data.length; ++j) {        
        data[j] = "option "+j;            
    }        
    ListModel strset = new SimpleListModel(data);        
</zscript>    
<grid width="100px" height="100px" model="${strset}">    
    <columns>        
        <column label="options"/>            
    </columns>        
</grid>

The grid sends the data to the client only if it is visible. It saves a lot of network traffic if the amount of data is huge.

With direct access with UI, database, and live-data, Direct Ajax keeps you from the following nightmares,

  • Slow Performance
  • Tedious Client Server Communication Codes
  • Maintenance Headaches

Which framework to use (how to do Direct Ajax)

After introducing the benefits of Direct Ajax, let's examine currently available Ajax frameworks to determine how many of them satisfy the requirements of Direct Ajax.

A Comparison Matrix of Ajax Frameworks

In the above matrix, there are four frameworks that support server-side programming, namely: ZK, Backbase, Echo2, and Icefaces.

5 Reasons you should use Direct Ajax

Building an enterprise application is never an easy task, not to mention enriching its user experience at the same time; Direct Ajax is designed to help developers deliver the project on time without working over-time. Here are the five reasons you should use Direct Ajax.

  • Boost Productivity of Developers Developers Focus on application itself instead of Ajax stuffs;
  • Fast Prototyping The UI, and the backend of an application are no longer separated..
  • Quick and Easy Learning No more JavaScript, XMLHttpRequest.
  • Secure Communication No danger of exposure of business logic to the client, and data over the Internet.
  • Easy Maintenance No more client codes.

Biography

Robbie Cheng is the author of, ZK: Ajax without the Javascript Framework, from Potix Corporation.