Question:
I have an applet with dialog boxes, text fields and buttons.
What can I do with the user input? How do I get it out of the applet?
What else can I do with this data?
Answer:
Perhaps the applet is a query for information. Then you need to find
out what the user wanted and display it. But perhaps the user is
entering information that you want, an order or a request for more
information by, perish the thought, mail or phone. Then you need to
get that information out of the applet into your possession. That is
the focus of this question.
There is one thing an applet can't do--save information onto the
user's local disk. For example, you couldn't write an applet that
lets the user do some calculation (say taxes, account records or
retirement calculations) and then save the information on the user
disk, so that it can be reloaded next time they visit your site and
run the applet again. Some people view this as a limitation, but
quite obviously it is a security measure. If an applet could save
information on the user's disk, it could also overwrite existing
files and create executable files with viruses in them. If you need
to store user profiles, they must be stored on your server.
Any information that an applet saves must be saved on the site
from which the Java applet originates. How do you get it from the
user's computer to your server? In a word, with sockets. A socket is
a network connection between the applet and a server program running
on your server. Let's suppose your applet takes an order from the
customer. You naturally want to capture the information so you can
fulfill the order.
The applet needs to open a socket to a server socket that is
constantly running on your computer. You may have a server socket
program such as an SQL interface that is ready to accept queries and
transactions. If not, you can either write your own server program,
or you can use the Common Gateway Interface (CGI) that is a standard
part of the Hypertext Transport Protocol (HTTP), the protocol of your
Web server. It is actually quite easy to write a simple server
program using Java--much simpler than the same chore with C. But it
takes quite a bit of expertise to turn the simple prototype into a
reliable and secure production program, so it seems wiser to deal
with CGI, byzantine as it may be. Netscape and other vendors are
working on adding security (such as the secure socket layer) to their
browsers, and they will will focus their efforts on CGI.
To send your customer's order information back to the server, your Java
applet needs to contact a CGI script. That script must reside on the same
Web server as the Java applet. A CGI script receives data that are sent
back from the viewer of a Web page, and it can optionally send a response
back to the user. CGI scripts can be written in just about any programming
language. For historical reasons, Perl is commonly used, but you can
certainly write a Java application (not an applet) if there is a Java
interpreter running on the server.
Up to now, CGI scripts were used mainly to process HTML forms, not to
interact with Java applets, and they work well with forms. So why
don't you just take your customer's order with an HTML form? There
are advantages to using a Java applet. The applet can compute totals,
taxes and shipping charges. It can check if an item is in stock or if
a credit card is valid. All this is much more tedious with
forms--you'd have go generate a maze of forms to cover each
situation.
Unfortunately, right now CGI does not interact particularly well with
applets, and you have to program the interaction by hand. You have two
methods of getting information from the Java program to the CGI script. For
a small amount of information, the command line argument is simpler.
Suppose you want to find out whether an article is in stock. If the
script that can check stock is called /cgi-bin/order.pl, then you
need to execute the following Java code:
Query q = "STOCK:" + item_name; // depends on your CGI script
URL u = new URL("www.where.com/cgi-bin/order.pl?" + q);
DataInputStream in = new DataInputStream(u.openStream());
String s = in.readLine(); // contains the first line of the answer
The CGI script then sends the answer back in some agreed format. This
can be text format and need not be HTML, so it can be designed to be
easy to parse. If you need to send more complex information, you
need a two-way socket connection, as follows:
Socket s = new Socket("www.where.com/cgi-bin/order.pl", 80);
// 80 is the standard port number for http
DataOutputStream out = new DataOutputStream(s.getOutputStream());
DataInputStream in = new DataInputStream(s.getInputStream());
String outData = . . .;
// whatever you want to send to the script
// can be many lines
out.writeBytes("POST " + script + " HTTP/1.0\r\n");
out.writeBytes("Content-type: " + ctype + "\r\n");
out.writeBytes("Content-length: " + sdata.length() + "\r\n");
out.writeBytes("\r\n"); // end of header
out.writeBytes(outData);
// now listen to response
String inData = new String();
String line = null;
while ((line = datain.readLine()) != null)
inData += line + "\n";
Now you know how to establish a two-way communication. You still need
to design a protocol for the information to be sent back and forth,
and, of course, you need to worry how to interface between the CGI
script and the database on the server side. Java, at least in its
initial release, does not solve these problems.
