Struts meets Swing (2)
by Keld H. Hansen
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.
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.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
