Enhance Your Web-Based GUI with Java
Arthur Donkers The Java language has broken through as one of the standards for creating truly interactive Web pages (see sidebar "The Java Environment"). Because of its independence of the underlying hardware and software, Java's applets can run on any platform with a Java-capable browser. The number of browsers that support the Java language is also growing. In the March 1996 issue of Sys Admin, I explained how to use your web browser as a GUI; and in this article, I will show how to give that GUI more interaction. By using Java and a number of precompiled applets, the control over the underlying application can be greatly enhanced (see sidebar "The Java Development Kit"). Furthermore, data from the application can be presented more clearly. This article presents a number of ways that Java can update your existing web-based GUI. (All the applets shown in this article are copyrighted by their original authors.) Introduction If you have used a "normal" Web browser, you are certainly aware of how it interacts with the user. It can display text and graphics in a platform-independent manner. Interacting through such a browser is a different story. As explained in the previous article, a normal Web browser has very limited means of sending data back to the server. If you look at the HTML 2.0 standard, still the most widespread one, you will notice that there are two major ways of interacting with the underlying program. These ways are: search/index entries and input forms. Search/index entries allow you to enter a value in a text field. After entering the data you can press the search button, and the search engine will attemt to find the information you requested. Input forms allow you to enter your data in a number of ways, including text fields, option lists, and simple buttons. After entering your data, you can press a button to send these data back to the server, or press the cancel button to clear the data. However you use them, these input statements are reminiscent of the screen-oriented data processing that may still be found in mainframe shops. You prepare a screen full of data and transmit it to the server. This level of interaction is no longer enough. Users want to interact directly with the server, without resorting to transmit buttons and the like. The only real way to achieve this is to write a dedicated program that interacts with the user on one end and communicates with the server on the other end. Developing such a dedicated program can be a formidable task and takes a lot of effort and resources. However, if the grade of interaction is modest, either by clicking buttons or using other simple GUI techniques, the Java language can be helpful. This language, and its associated applets, can offer a new level of interaction on your web page. How Java Works: A Short Example First, I will show you a couple of examples of Java programming and applets. You probably all remember your first "Hello World" program written in C; here is that same venerable program in Java. This version is as simple as, and maybe even simpler than, its ancestor from the world of C. The code of the Java version is shown in Listing 1. The convention for Java programs is that source files use the extension .java; whereas the "binaries" use the extension .class. Furthermore, the source file must have the same name as its public class, including capitalization. In this example, the source file is called HelloWorld.java. After you compile the file with javac, you end up with a HelloWorld.class file. And, if you run this through the java interpreter you will see the text Hello World! appear on our screen. Note that the text is not displayed in a separate window because we have not used any graphical objects. Java applets are executed by the browser itself. That means the applet runs on the machine the browser is running on and uses the resources from that browser. The browser has a built-in Java interpreter, and as soon as it receives a Java program, the browser will start executing it. The I/O with the applet is all done through the browser, unless you explicitly tell the applet to use something else. This is why security is such a great concern for Java; you are executing an unknown program of unknown origin in your browser when you activate an applet, which is usually considered a great security risk. To access an applet, the browser needs a special tag, embedded in the HTML page. This tag tells the browser the name of the applet, its parameters, and everything else the browser needs to know to run such an applet. When the browser encounters an applet tag in a HTML page, it requests the applet code (the <applet>.class file) from the server. Once the browser has retrieved this binary form of the applet, it will execute it with the associated parameters. Thus, all the GUI intelligence that resides on the server is loaded on demand by the browser. The format of the applet tag is shown in Listing 2. The param lines are used for the parameters of the applet. If the applet has no parameters, this section can be left out. Listing 3 shows the complete HTML page for the HelloWorld applet. To use this simple program as an applet, I had to add some extras, and the new source is shown in Listing 4. The output of this new applet is shown in Figure 1. As shown in Listing 4, adding graphical extras to the applet is simple and straightforward. Adding a Label is as simple as creating an object of the Label class by using the new method. It is beyond the scope of this article to show you how to program in an object-oriented environment. The only thing you have to remember here is that you can create an object by using the new method on an object class. How Can Java Help Your Web-Based GUI? Using the objects from the Abstract Windows Toolkit (AWT) class library, you can add all kind of graphical items to your Web page. You can add buttons, labels, text fields, scrollbars, and lists that give the GUI almost the same options as a "real" GUI written in X11/Motif. However, the advantage of a Java solution is that the GUI runs on all platforms that have a Java capable browser. Another advantage is that the complete works of the GUI are stored in one place, the server. It is loaded when a user needs it. This means that all users will "see" the same GUI when they start the program. You don't have several versions of the GUI scattered across the different platforms on your local area network. Here is another example with a few basic user interface items. This example is a bit simplistic, but it shows a number of techniques involved, and you can build on it for your own user interface. The example uses a few buttons and an item list. Pressing a button adds an item to the item list. Pressing the OK button will cause the applet to build a connection to the netdate service on the local host. The returned data, the current date, and time will be displayed in a text field. This example involves several GUI-related items, including network communications. Unfortunately, I cannot show you a real-life example, as my company is developing a commercial Batch Queuing product with a user interface based on Java. And, I do not want to give away all information just yet. A More Elaborate Example The complete source of the applet is shown in Listing 5. Although it has quite a few features for a such a simple applet, the code is quite short. I will show you the most important highlights of the code. First Iinclude a number of class libraries, both for the AWT and the I/O (both stream and net). Then I declare a number of objects, buttons, textfields, and such, because the applet may need them later. The following code creates list and OK button and glues them to the base panel (which is created by default). Next, the applet creates two extra panels, p and p1, and adds the buttons and message text to these panels. These two panels are then glued to the base panel. This is all done in the init() function, which is called when the applet is created. The fun all happens in the action() routine. This routine is the event handler for the applet, which means that all events, such as clicking on a button, are sent to this routine. A programmer can then decide whether to do something useful with this event or not. To be able to decide this, this action routine has two parameters, an Event, and an Object. The Event parameter describes the type of event and the object that generated this event. This parameter is used in the applet to determine whether it should do something or not. This applet will handle only button events; the initial if causes other events to be ignored. In this example, buttons are identified by their label (see Figure 2). Normal buttons just cause their label to be added to the item list. Adding an item to such an item list is done by calling the addItem method of your favorite List object. The parameter for this addItem method is the string to be added to the list. If a user presses the OK button, something completely different will happen. When the OK button is pressed, the applet will open a connection to the netdate service on the local host. It will obtain the current date and time from that connection and display this information in a specially created TextField (see Figure 2). Programming this network stuff is similar to socket programming in "normal" C and UNIX. Doing network I/O from an applet does have some security implications. Under normal circumstances, an applet is not allowed to touch the network, only the host from which the applet was downloaded. I show you this example, however, because it is often necessary in a GUI to communicate with the server. Using network I/O in an applet has other implications as well. Because of the possibility of errors when using sockets, each of your actions can throw an exception. In UNIX, you will get a return status from the routine that indicates an error (often -1). In Java, however, there is no return value to check. Instead, the object generates an asynchronous event. You can use an eventhandler to take care of this event. In this example, event handling is done by the following construction:
try {
error prone statements
}
catch( Exception e ) {
exception handling
}
The error-prone statements are "marked" with a try block. Whenever an exception occurs in one of these statements, the try block is exited and the exception handler block is entered. This is the catch block. You can force an event by calling the throw function within the try block. If no exceptions occur, the catch block is skipped. If you look at the example in Listing 5, you will see that all Socket I/O is guarded by such a "try and catch" block. For this example, the exception handling simply shows a stack trace. For a real production applet, the error handling should be more sophisticated. Listing 6 shows how to embed this applet in a Web page. This applet does not have any parameters. You can add these parameters as extra lines in the Web page if you wish. Then you can retrieve the value of these parameters in your applet. In this way, you can customize the labels on your buttons or the color of your ItemList. This proves to be a very powerful mechanism when combined with dynamically created pages. Putting It Together By means of a (really simple) example, I will show you how you can adapt the source given in previous article and include applets in your Web pages. This very simple example has one button a user can push. The label on this button is set through a parameter, and this parameter is generated dynamically by the Perl script. I will only show the most important changes to the original script. The complete source is available in the March 1996 issue or from the Sys Admin ftp site. In that article, I used a dynamically generated page that showed all the Internet service providers I could dial in to. I have adapted this page so it shows applets (a button and a text field) for each of these ISPs. Thus, the isps.pl program has been changed to include an applet tag for each ISP. This new code is shown in Listing 7. As shown in this listing, the isps.pl script uses the codebase attribute to tell the browser where the applet MyButton.class can be found. This codebase can be specified like a normal URL. In this case, the URL points to a special web daemon that will take care of transferring the applet as well. This applet needs to be sent to the browser as is (as a binary file), so the do_req function of the original program also had to be changed. That function will now detect when a request is made for an applet, and if it detects an applet request, it will call the special do_applet function. This function will transfer the applet file (as is) to the browser. These adaptations to the original program are shown in Listing 8. The changes have been marked with an "!." When you start the new program, the new web page should look like the one in Figure 3. Conclusions Apart from some security problems, applying these Java techniques looks very promising. You can build an architecture-independent user interface and offer it to anyone who is "talking" to your application through a Java-capable Web browser. The fact that the GUI is independent of the underlying architecture means that you only have to develop it once, and only support one version. This can be a big time and cost saver. Writing a user interface in Java is reasonably simple and straightforward. You have the power of an object oriented-environment, without the overhead. By using and reusing the standard class libraries, you can quickly create an applet. And by saving your own applets in a class library as well, you can easily build your own set of GUI metaphors to give your applications a consistent look and feel.
About the Author
Arthur Donkers graduated from the Delft Universiy of Technology with a degree in Electrical Engineering and a major in Computer Architecture. Since then he has worked for a number of major software houses in the Netherlands and participated in several major projects. His primary field of interest in these projects has been, and still is, datacommunications, especially the integration of multivendor networksystems. For the last four years he has worked as an independant consultant for his own company, Le Reseau (french for "The Network").
|