Now that you have some idea how you can add Java applets to your Web pages, you need to discover how applets are handled on the Internet. After all, it is an applet's ability to hitch a ride on the Information Superhighway that makes it so unique. In fact, applets are really the first step towards making the Internet a true extension of your computer's local storage system. When you view a Web page containing applets, those applets may be coming to you from just about anywhere on the Web-from the office down the street or from a software distributor in Hong Kong. In this chapter, you discover just how this interaction works.
One of Java's major strengths is that you can use the language to create dynamic content for your Web pages. That is, thanks to Java applets, your Web pages are no longer limited to the tricks you can perform with HTML. Now your Web pages can do just about anything you want them to. All you need to do is write the appropriate applets.
But writing Java applets is only half the story. How your Web page's users obtain and run the applets is equally as important. It's up to you to not only write the applet (or use someone else's applet), but also to provide users access to the applet. Basically, your Web pages can contain two types of applets: local and remote. In this section, you learn the difference between these applet types, which are named after the location at which they are stored.
A local applet is one that is stored on your own computer system (Figure 3.1). When your Web page must find a local applet, it doesn't need to retrieve information from the Internet-in fact, your browser doesn't even need to be connected to the Internet at that time. As you can see in Listing 3.1, a local applet is specified by a path name and a file name.
Figure 3.1 : Local applets are stored on and loaded from your computer system.
Listing 3.1 LST3_1.TXT: Specifying a Local Applet.
<applet
codebase="tictactoe"
code="TicTacToe.class"
width=120
height=120>
</applet>
In Listing 3.1, the codebase attribute specifies a path name on your system for the local applet, whereas the code attribute specifies the name of the byte-code file that contains the applet's code. The path specified in the codebase attribute is relative to the folder containing the HTML document that references the applet. (See the "Optional Attributes for Applets" section of Chapter 2for more information.)
A remote applet is one that is located on another computer system (Figure 3.2). This computer system may be located in the building next door or it may be on the other side of the world-it makes no difference to your Java-compatible browser. No matter where the remote applet is located, it's downloaded onto your computer via the Internet. Your browser must, of course, be connected to the Internet at the time it needs to display the remote applet.
To reference a remote applet in your Web page, you must know the applet's URL (where it's located on the Web) and any attributes and parameters that you need to supply in order to display the applet correctly. If you didn't write the applet, you'll need to find the document that describes the applet's attributes and parameters. This document is usually written by the applet's author. Listing 3.2 shows how to compose an HTML <applet> tag that accesses a remote applet.
Listing 3.2 LST3_2.TXT: Specifiying a Remote Applet.
<applet
codebase="http://www.myconnect.com/applets/"
code="TicTacToe.class"
width=120
height=120>
</applet>
The only difference between Listing 3.1 and Listing 3.2 is the value of the codebase attribute. In the first case, codebase specifies a local folder, and in the second case, it specifies the URL at which the applet is located.
If a required applet is not located on your system, it can be downloaded automatically to your system and then run. To the user, this exchange of applets over the Internet is mostly transparent. All the user knows is that she's looking at a page that contains a game of TicTacToe, an animated image of Duke, or some other Java-based content. In this way, the Internet becomes almost an extension of the user's basic system, sort of a gigantic hard drive that contains a practically infinite number of accessible applets and applications.
Currently, there's a client/server relationship between a browser that wants to display an applet and the system that can supply the applet. The client is a computer that requires services from another system; the server is the computer that provides those services. In the case of a Java applet, the client is the computer that's trying to display an HTML document that contains a reference to an applet. The server is the computer system that uploads the applet to the client, thereby allowing the client to use the applet. In Figure 3.2, you could call the local computer the client and the remote computer the server.
It won't be long, however, before the difference between a client and a server begins to get muddy. When Java browsers can send as well as receive applets, computers will constantly switch between being a client and a server. For example, suppose a user loads up his favorite Java-compatible browser and connects to a Web site. The home page on the Web site contains an animated title, so your system downloads the applet that displays this title. For the time being, your system is the client and the remote system is the server.
Now, however, you decide that you want to search the remote system's public databases for a particular file. Because you've just written a handy search application that can do the job for you, your system transmits the application to the remote computer, where it sets to work finding the file you specified. Suddenly, your computer is the server and the remote computer is the client.
This sort of switching between client and server tasks is a step toward making the Internet a huge extension of your computer. That is, more and more, the Internet will seem to be a part of your own local system, rather than a collection of computers located all over the world. You'll be able to access the Internet almost as easily as your own hard drive. In fact, you might not even need a hard drive at all! You can just run applications located somewhere else on the Internet and store your data in any number of special storage sites.
You may have heard horror stories about people who have downloaded programs from the Internet only to find, after running the program, that it infected their system with a virus or otherwise wreaked havoc with their computer. Therefore, you may be reluctant to jump on the applet bandwagon. After all, with so many applets flying around the Internet, trouble could rear its ugly head like a demon from a Clive Barker movie.
The truth, however, is that Java applets are a secure way to transmit programs on the Internet. This is because the Java interpreter will not allow an applet to run until the interpreter has confirmed that the applet's byte-code has not been corrupted or changed in some way (Figure 3.3). Moreover, the interpreter determines whether the byte-code representation of the applet sticks to all of Java's rules. For example, a Java applet can never use a pointer to gain access to portions of computer memory for which it doesn't have access. The bottom line is that, not only are Java applets secure, they are virtually guaranteed not to crash the system.
Because you bought this book to learn how to write applets, you're probably also interested in setting up your own Web pages. (Of course, you may be interested only in creating applets that other people can use. That's okay, too.) To set up your own Java-compatible Web site, you need to create publicly accessible folders on your hard drive. You also need to gather all the applets you need so you can store them together in one place on your hard drive. That is, you'll want your Web pages to contain local applets. The instructions in this section will get you started on organizing a public folder.
First, create a folder on your hard drive's root directory. Name this folder something like PUBLIC. The PUBLIC folder will contain all of the files that are accessible to Web users who connect to your pages. Inside the PUBLIC folder, create a folder called something like APPLETS. The APPLETS folder will contain the applets that are referenced in your Web pages.
Now that you have your folders created, copy all the applets you need into the APPLETS folder. The applets' .CLASS files should be in the APPLETS directory, with their support files (such as graphics and sounds) in appropriately named folders within the APPLETS directory. For example, if you wanted to use the BouncingHeads applet in one of your pages, you'd copy the contents of the JAVA\DEMO\BOUncINGHEADS folder to your APPLETS folder, ending up with the directory structure shown in Figure 3.4.
Figure 3.4 : You need to set up your public directories properly.
The next step is to create the HTML files for your pages. When you've written these pages, they should be placed in the PUBLIC folder. Listing 3.3 shows the HTML file for a simple home page that displays the BouncingHeads applet and enables the user to view the applet's source code. The corresponding Web page is shown in Figure 3.5. Notice that the user can view the applet's source code by clicking on the link at the bottom of the page. When she does, she sees a window similar to Figure 3.6.
Figure 3.5 : A simple, Java-powered home page.
Figure 3.6 : The user can view the applet's source code by clicking the link.
Listing 3.3 HOMEPAGE.htmL: A Home Page Displaying a Java Applet.
<title>Big Benny</title>
<h1>Welcome to Big Benny's Home Page</h1>
<b>We're hot wired for Java!</b>
<p>
<applet
codebase="applets"
code="BounceItem.class"
width=400
height=150>
</applet>
<p>
<a href="applets/BounceItem.java">The source code</a>
for this applet is available for your viewing pleasure.
| NOTE |
Generally, you do not need to copy Java source code files to your APPLETS folder. Source code is not required in order to load and run applets. |
By placing all the publicly accessible files in one root directory, you can more easily set up your system's security to ensure that the rest of your system is kept safe from prying eyes. Moreover, you know exactly where you need to store any additional files that you may add to your site. Exactly how you create the folders for your Web pages will depend upon the applets and files you need to use, but the previous example should get you going fairly easily.
| NOTE |
Of course, to create a Web site, you need to be connected to the Internet either directly or through an Internet provider that enables you to set up your own Web pages. If you are currently unable to have your own Web site, you can still set one up on your hard drive and then use your Java-compatible Web browser to load and view your Web pages. Then, when you get your Internet access, you'll be all ready to go. To find more information on setting up your own Web site, crank up your browser and log onto the handy Lycos directory at http://www.lycos.com; then fish around under the Computers, Web Publishing & HTML subdirectory. |
Thanks to a Java-compatible browser's ability to download applets, users who log onto Java-powered Web pages can enjoy the Java experience without even realizing what's going on behind the scenes. This is unlike other types of applications on the Internet that the user must explicitly download before they can be run. When more and more applets start running rampant on the Information Superhighway, the Internet will become a virtual extension of your own computer system, one that's almost as easily accessed as your local hard drive. When this happens, the Internet will start living up to its hype.