Tutorials : Struts meets Swing 2 :

Struts meets Swing (2)

Introduction

In my first article I presented a scenario like this:

"You're a Java programmer working in your company's Internet technology department, and as member of a project team you've participated in building a Java servlet application utilizing the Jakarta Struts framework. The application runs in a browser. It's a simple application--no EJBs or other advanced technologies.

The application has been running for some time now, and the users are happy about it. Now your boss comes along and asks if the application can run without a browser--he's got a customer that doesn't trust browsers and he also prefers this cool Java Swing look. If you're an honest man you'll have to tell your boss that a Swing client wasn't part of the old requirements specs, so unfortunately, the application only runs in a browser. After your boss has gone you start thinking about if and how a Swing client could be added."

The results of this query were presented in the first article. To test our theories we took a small browser application with only two pages: one for showing a list of DVDs in a collection, and one for presenting all the details for a single DVD. Despite it's simplicity it still contains the common CRUD (Create, Read, Update and Delete) operations. You can see the application screenshots here.

To summarize our thoughts about the two-client solution:

entry to the DVD applications is through the Struts servlet. From a Java program this interface is available through the URLConnection class.
cookies are used to preserve the "state" of the application, so we'll have to manage them in the same way as a browser does.
we'll have to identify our client as a Swing client. If we don't do this we'll get an answer in HTML format (which could be handled in some way, of course, but isn't exactly what we prefer)
output from Struts is through a jsp-page (or a servlet), so we need a set of new jsp-pages for the Swing client.
We decided to let the output from the new jsp-pages be in XML-format.
the Struts configuration file--struts-config.xml--will have to be changed by adding new actions for the Swing client. You may see the new configuration file here.

That's basically it. In the first article a few test programs were built, which demonstrated that the technology was working.

What we need to do now is to:

code a component that will make the request to the web server and receive the response
find out how to transform the XML replies from the web server
design an error handling strategy
decide upon the GUI of the Swing client
implement the Swing client

The WebRequest component

In the first article the essential code for making the request and receiving the response was shown. I've packed this into the WebRequest class, which also includes some code for handling the session cookie, and which stores the XML reply as a JDOM tree structure:

. . . get ready to receive response �
SAXBuilder builder = new SAXBuilder();
try {
  doc = builder.build(conn.getInputStream());
  root = doc.getRootElement(); // save the root Element
}  
catch (JDOMException j) {error handling. . .}
. . .

The JDOM root Element can then be retrieved from WebRequest through the getRoot method.

Handling the XML replies

There are only two "normal" replies:

when the Swing application starts it must request the list of DVDs from the server. This is done by the list.do action.
every time we select a DVD to have the details for it shown, we use the detail.do action.

Having received the list of DVDs the Swing client has no problem in maintaining the list--or rather the list of titles--locally. This is of course only true if there are no other users working on the same list of DVDs. Another user might add or delete DVDs from the list, and it's actually an important design question, if such modifications to the list should be visible in "our" list.

The right solution will--as always--depend on the application at hand. One solution could be to manage the DVD list locally, and add a "Refresh" action (maybe a button the user could press?) which would go to the server and get an updated list of DVDs. In our simple example we'll simply manage the list of DVDs locally.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.