The Codist

In my last two jobs I worked on three java applications, all ajax web applications using no web framework whatsoever. All three were for an intranet, so there was no need to worry about about Javascript being turned off.

It might not be possible for everyone, but it sure made development much easier and each application was well received by the user base.

Typically when developing a Java web application you would use a web framework, either using J2EE (JSP) and usually an additional framework such as Struts/Tiles, or perhaps avoiding most of J2EE by using Spring, either by itself or with another web framework, or even using a servlet-based framework like Tapestry or Wicket. However you do it, the framework supplies the environment, generates HTML, processes form data, and all the other usual web workings. In your code you interact with the framework and also interact with some kind of database framework, such as plain JDBC, EJB, Hibernate or iBatis.

In a naked web application, the web framework and its (usually heavy) configuration is replaced by a much leaner architecture.

In my case the ajax framework was DWR. DWR (Direct Web Remoting) is a popular framework for Java which allows calls to be made to Java beans on the server from dynamically generated Javascript objects in the browser. Essentially it provides a pipeline from your code on the client to your code on the server. In the upcoming version 2, DWR will all support reverse ajax, where server objects can asynchronously call client objects.

You could argue that I am simply replacing one web framework with a lighter one. I wouldn't complain, that's the whole point.

The three applications I worked on were an employee directory, a field office and staff information application (a sort of super directory with a lot of query options); and for a different employer, a digital printing press room management console.

The directories used Oracle and iBatis. The employee directory was a single HTML page, and the field application had a single HTML page and about 1500 supplementary static pages generated daily. The main HTML "page" held only the static areas of the application, and onload obtained information via DWR from Java beans on the server. As the user typed or chose various options, the interface and data display updated on the fly as needed. There were several alternate views of data which were made visible/hidden as needed. For these applications I used mostly DWR's javascript utilities.

The press application called an existing API and a bit of JDBC for data, and also interacted via a REST interface to other systems. This application was used to manage the companies digital presses, displaying all related print jobs in a large grid (updated in real time as orders came in), with various optional details and controls (deleting, pausing, restarting, etc), and allowed the operators to drag and drop jobs to the targeted press.

Development in all three cases was rapid and the details and functionality were constantly in flux. Spending a lot of time configuring a traditional web application, especially one with lots of XML to edit, would have been doable but far less productive. In two weeks I wrote 3 complete versions of the press application. It made testing new interfaces much easier, since I could easily build a functional prototype.

Now if I had to build an huge application with a large team, this approach might not be so easy. Of course readers might point out that I could have used Ruby On Rails but that wasn't an option for either employer. In any case this technique allowed my to get some of the benefits of the ROR approach without having to give up the Java environment.