- Using Visual J++ -

Chapter 7

Reviewing Java's Nature


In this chapter, you again look at some of Visual J++'s sample applets. Instead of just viewing the applets, however, you'll extend them. This chapter gives you a glimpse of Java's true capabilities: You can extend the capabilities of Visual J++ programs that others write. Unlike non-Java languages, however, you don't need access to the program's source code to make those changes.

You can extend Java programs with many techniques. One of the most powerful extension techniques is called inheriting (or subclassing). You learn about extending through inheritance in chapter 12, "Working with Classes." This chapter does not require that you understand the Java language specifics. You can extend, or change, a program's capabilities through HTML code without knowing much at all about the applet's original program details.

By extending the applet's capabilities through HTML, you can send information to the applet that determines how the applet will perform. Although you may not understand all the terminology presented here (you will before the end of the book), you will get a lot of hands-on experience with the Visual J++ editor and you'll work once more with Visual J++'s environment and your Web browser.

Speeding Up Mr. Duke

Load and run Visual J++'s Animator sample applet once again. Chapter 6's section, "The Animator Sample," describes how to run Animator. The Animator applet sends Duke spinning across the top of your screen after you select Example 1 - Duke Waving from the opening screen's links.

In the previous chapter, you focused on the animated Duke to see what Visual J++ and Java can perform; this time, scroll your applet's screen down to read the text that appears below Duke. Figure 7.1 shows the text.


FIG. 7.1

The sample applets include HTML parameter information.

The text at the bottom of Duke's applet screen (and at the bottom of most of the sample applet screens) lists HTML parameters that are in effect. A parameter is a value sent from one location and received from another. You'll learn a lot about parameters throughout this book and you'll master parameters in part III, "Programming with Visual J++," where you learn about method calling.

 
The text at the bottom of the applet screen appears only because the Visual J++ samples' HTML pages display the text. Microsoft included the parameters so that you can easily locate parameters that are in effect and know what you can change. Normally, an applet developer does not, and should not, display an applet's parameters on-screen for the following reasons:

The parameters at the bottom of Duke's Web page are values that determine the sample applet's behavior. Table 7.1 describes each of the parameters listed.

Table 7.1 The Waving Duke Animator Applet's Parameter Descriptions

Parameter Description
imagesource Directory location of the images that comprise Duke's movement.
endimage The number of .Gif files used for the animation. The files are named T1.gif through T10.gif (assuming there are 10 images that comprise the animation).
soundsource Director location of the audio files.
sounds Name of the audio files played during the animation.
pause The number of milliseconds the animator pauses between each .Gif image's display.
 
Keep in mind that the text showing the parameters is there for informational purposes only. Most Web sites do not include such parameter displays.
 
 
If you display parameters at the bottom of your applet so that users can change the applet's behavior, consider putting comments next to the parameter list so your end-users have a better idea of each parameter's purpose. These sample HTML pages don't describe the applet's parameters but only list the parameters.

Suppose you want to change the way the Animator sample works. Duke makes his way a little too slowly across the screen. If you were to decrease the pause value used by the applet, Duke would speed across the screen much faster.

There are two ways to change the pause parameter:

Obviously, the HTML file is easiest to change and that's exactly what Animator's authors intended. Listing 7.1 shows the HTML file that displays the Animator applet before you make any changes to the file.


Listing 7.1 Animator's HTML Commands

<HTML>
<title>The Animator Applet - Example 1</title>
<APPLET code=animator.class width=200 height=200>
<param name=imagesource value="images/Duke">
<param name=endimage value=10>
<param name=soundsource value="audio">
<param name=soundtrack value=spacemusic.au>
<param name=sounds value="1.au|2.au|3.au|4.au|5.au|6.au|7.au|8.au|9.au|
[ic:ccc]0.au">
<param name=pause value=200>
</APPLET>
<HR>
&lt;APPLET code=animator.class width=200 height=200&gt;<p>
<BLOCKQUOTE>
&lt;param name=imagesource value="images/Duke"&gt;<br>
&lt;param name=endimage value=10&gt;<br>
&lt;param name=soundsource value="audio"&gt;<br>
&lt;param name=soundtrack value=spacemusic.au&gt;<br>
&lt;param name=sounds
[ic:ccc]value="1.au|2.au|3.au|4.au|5.au|6.au|7.au|8.au|9.au|0.au"&gt;<br>
&lt;param name=pause value=200&gt;<BR>
</BLOCKQUOTE>
&lt;/applet&gt;
<HR>
<A HREF="Animator.html">The main page.</A>

 
Listing 7.1 shows the Example1.html file. The Animator applet requires a total of five HTML files, but Example1.html loads when you request the Waving Duke option that displays the dancing Duke described earlier in this section.

The HTML file seems to duplicate some of its lines. Basically, the parameter list appears twice but you've got to understand why Animator's designers put what appears to be a duplicate set of lines in the HTML file.

The final lines produce the parameter descriptions that appear at the bottom of the Animator's screen (see figure 7.1). This text has no bearing on the applet's execution. Only the few lines, repeated in listing 7.2, affects the applet's execution.


Listing 7.2 The HTML Controlling Code Lines

<param name=imagesource value="images/Duke">
<param name=endimage value=10>
<param name=soundsource value="audio">
<param name=soundtrack value=spacemusic.au>
<param name=sounds value="1.au|2.au|3.au|4.au|5.au|6.au|7.au|8.au|
[ic:ccc]9.au|0.au">
<param name=pause value=200>

If you change the parameter's value from 200 to 30, Duke will tumble much faster across the screen. Perform these steps to change the HTML file and rerun the applet at Duke's new lower pause setting:

  1. Open Animator's project workspace.
  2. Click the FileView tab to display animator's file collection.
  3. Click the plus sign next to Animator files in the FileView window to display the files used in the applet.
  4. Double-click example1.html to open the Example1.html file in the editor.
  5. Change the eighth line to set the pause parameter value to 30. Your screen should look like the one in figure 7.2.
  6. Scroll down to the 18th line (the status bar includes the line and column on which the text cursor rests as you scroll through the file) and change the parameter from 200 to 30.
  7. Select File, Save to save the HTML file.
  8. Rerun the applet. Notice that Visual J++ does not re-compile anything because you did not change any Java source code. Duke runs across the screen at his new speed.


FIG. 7.2

Changing the pause parameter to 30.

 
If you don't change line 18 from 200 to 30 (see step 6), Duke still runs across the screen at the faster value. Remember that the 18th line is part of the parameter display listing that appears at the bottom of the Web page. Duke can fly across the screen at the new value and the parameter can still display the old parameter value but, obviously, you should change the display to reflect the HTML parameter's current value.

Although the HTML contains all the other parameters that you can change, they involve graphics and audio files that you may or may not have access to. So we'll move to another sample applet in a few moments and you can modify more parameters.

Are you getting an idea of Java's Web power? Suppose you wrote several applets for your salespeople across the country. Your salespeople might access your company's Web page for product information and pricing. In each of six divisions, your prices differ based on some location codes. Instead of writing six different applets, you can write one product applet that gets a location code from the Web page's HTML parameters. Your employees could then access their division's Web page, sending your company's distributed applets the local division's parameters. Therefore, each salesperson across the country would run the same applet, using one of several Web pages, and see different results due to the Web page's parameters.

You Don't Need the Class

Notice from where Example1.html gets its applet class (a class, in Java terminology, is loosely an analogy for the compiled program):

<applet code=animator.class width=200 height=200>

The code HTML command tag tells the HTML page, or more accurately your Web browser or the applet viewer, what compiled class to use for the program code.

The biggest news to hit the Internet in some time, however, is this: You don't have to have the class on your computer to use the class! In addition, you don't have to have access to the source code. All that you need to know is the location of the class, even if that location is on a computer in another country!

If all of this seems too good to be true, consider the following change to the <APPLET> command tag:


<APPLET Src="http://www.c2mcp.com/pgms/class"
Class="animator" width=200 height=200>

The Src tag command specifies the applet's bytecode location that comes to your Web browser. In case the class name differs from the applet's name (which is rare but happens), the Class tag command specifies the applet's class. If you embed this applet tag command inside your HTML file, when you run the HTML file inside your Java-aware Web browser, your Web browser will search the listed URL site and locate the class.

Locating the class file on another computer does not limit you from modifying the applet's parameters. For example, you can locate the class on the URL and also modify parameters such as this:


<APPLET Src="http://www.c2mcp.com/pgms/class"
Class="animator" width=200 height=200>
<param name=pause value=30>

Including OPA (Other People's Applets)

The designers of an applet must design the applet so that you and others can grab the class across the Internet. In other words, the applet must be a public applet and the applet's server (the computer at the other end of the URL) must make the applet publicly available. As long as the applet is publicly available, your HTML file can send parameter values to the applet class and you can show the applet's modified execution.
 
All kinds of copyright laws can raise their ugly heads in this Internet environment. You are using bytecodes from someone's applet, but you modify the bytecode's execution from their original intent, and you use your own HTML page to do so. But all this actually executes on someone else's (your Web site's end-user) computer! The applet's designer can generate a non-public applet if the designer does not want to make the applet available, but reasons exist that may require the applet designer to create a public applet.
 
In addition, how do you know which parameters exist to change? As stated in the previous section, most Web sites don't contain the parameter listing that makes the applet's modification simple. You must know the applet designer, get permission to use the applet, get a list of parameters, and locate the applet's URL before you can use the applet and modify its parameters on your own Web page.
 
 
We might see a new business flourish now that Java-aware Web browsers are becoming so prevalent. Visual J++ programmers could develop applets for sale that we could purchase and use on our Web sites. In addition, a comprehensive set of parameters (and good documentation) would make the applet extremely customizable. While Visual J++ is still new, why don't you create your own applet distribution company and beat Bill Gates to early retirement?

Modifying Yet Another Applet

Let's try modifying another one. Load the Blinking Text sample and rerun the applet to remind you what the applet does. The applet continuously blinks words from a phrase. The applet displays a parameter's phrase in various changing colors, showing one or more random words at a time with each blink's iteration. Table 7.2 lists the Blinking Text sample applet's parameters that you can change from within your HTML page.

Table 7.2 The Blinking Text Applet's Parameter Descriptions

Parameter Description
lbl The phrase that blinks on and off at random.
speed The speed, from 1 to 10, of the blinking applet's execution. A speed value of 1 slows the blinking to its slowest speed, and a speed value of 10 causes the applet to blink the text quickly.

Just to see a difference in the applet, load the Blinking Text project workspace. Edit the BLINK.HTML file and change the lbl parameter's value to Do right and risk the consequences. The line's command tag now appears like this:

<param name=lbl value="Do right and risk the consequences.">

In addition, you should also change Line 11's parameter display to your new value so the description at the bottom of the screen matches the current parameter values. When you subsequently execute the Blinking Text applet, you'll see the new blinking message as shown in figure 7.3.


FIG. 7.3

A new phrase now blinks.

Summary

The goal of this chapter was to show you how easy it is to take an existing Java program and extend the program with Visual J++'s help. You don't have to access the source code file. Even your Web page's end-users don't need to know Java to change our applet's behaviors as long as they can change simple HTML parameter values.

The applet's HTML parameters work like communication links to the outside world. When someone modifies the HTML parameters and views the Web page again, the parameter values determine how the applet behaves.

The next chapter dives deeper into Visual J++ and into the Java language by showing you how to use the debugger. The debugger helps you pinpoint problems in the programs you write. By learning how to use the debugger early, you'll be able to correct programs as you learn to write them.

Here are the points this chapter covered:


Previous Page TOC Next Page

| Previous Chapter | Next Chapter |

| Table of Contents | Book Home Page |

| Que Home Page | Digital Bookshelf | Disclaimer |


To order books from QUE, call us at 800-716-0044 or 317-361-5400.

For comments or technical support for our books and software, select Talk to Us.

© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.