An In-Depth Look at the Workings of an Applet - Continued

This week we're taking apart an applet that we brought up a little while ago. If you're just joining us, you should read this and this before you go on.

Last week, we looked at the applet class of our applet at some length. This time, we're going to be taking a look a the other two classes we used, and talking about how they all work together.

Let's start small. If you remember, our applet remembers bits of information about every HTML tag in whatever document it's loaded. Specifically, we keep track of where each tag begins, where they end, and what their names are - in this case, the name being whatever the first word in the tag happens to be. "A" for "A HREF" or "IMG" for "IMG SRC" and so on.

All of that information is parceled up - we want to keep all these bits of information together for each tag. If we were writing this in C, we'd probably make a struct - which, for those that don't know, is nothing more than a way of grouping several variables together into one. Since we're thinking in terms of objects (which accomplish that as well), we make an object instead.

So how do we do it? Relax, it's simpler in Java than in most any other language. If you're writing your applet, and you suddenly suffer an epiphany, allowing a mysterious understanding that it would be a good idea to make another class, all you have to do is figure out what to call it (we called ours Tag), and create the .java file with that name (i.e. Tag.java). Write whatever you need into your class, compile it (javac Tag.java)... and then just use it as necessary in your other code.

Most likely, if you haven't done much programming already, this seems perfectly obvious and (relatively) straightforward - and if you have, it probably seems like I'm leaving something out. People who program in C and C++ regularly are used to having to take special measures to interconnect the objects they write; "including" the proper header files, and insuring that all of the necessary "object files" are linked together into the final product, for example. Not to mention that just trying to organize a large number of objects in C++ can be potentially confusing, since there's no rule that says you can't put 20 objects into one file, or stretch a single object across a dozen files.

Java's design obviates the need for these hassles. Java actually forces us to keep every object in its own, discrete file - which is probably for the best in many projects. Since programs are always sets of classes that are assembled when you run them, you never have to worry about linking them all together yourself. And because Java is relatively smart about locating resources it needs (like classes), it's not necessary to "predefine" everything you plan to use in every class. If you make reference to an object in your code, like we did in our applet class:

  private void readtags(String input,Vector output)
  {
     // We created a simple Tag object to keep all the relevant information
     // about a tag.
     Tag current;

...Java just looks for it when the time comes to run the routine. It looks in several places. There are directories on your machine right now which Java thinks might have classes you're interested in (listed in what's called your CLASSPATH). It also looks at the source of the class it's working from (for instance). In this case, the Java interpreter in your web browser eventually figures out that it needs to get Tag.class from the same directory on our web server that the applet itself came from. It loads it, the two match up, and that's it - in an automated nutshell.

In this case, Tag itself is very, very simple. Just as we described, all it does is hold three pieces of information.

// This is the class for Tag objects; they hold all the information we might
// be interested in knowing about tags in HTML.

public class Tag
{
  // What's it called?
  public String tagname;
  // And where's an example of one?
  public int startindex;
  // And where does the example end?
  public int endindex;
}

Syntactically speaking, it works just like that struct we mentioned earlier. When we want to make one, we instantiate it just like any other object:

  Tag ourtag = new Tag();

And if we want to retrieve or store information in any of the Tag's variables, we just call them by name (object_name.variable_name):

  ourtag.tagname = "a name";
  System.out.println(ourtag.tagname);

If at some point we wanted to keep track of more things about our HTML tags, we could just add something extra to this object, and then use it in our other classes. And the same goes for our other class - the TagButton.

This class is brutally simple. It's a subclass of the existing Button class that we get in the Abstract Window Toolkit. It holds three variables:

// This is our specially constructed subclass of Button. It's designed
// to remember things about the tag it's associated with, and do something
// specific if it's pressed.

import java.awt.*;

public class TagButton extends java.awt.Button
{
  // We keep track of all this information in our button:
  TextArea sourcebox; // Where the HTML is.
  TextField highlightbox; // Where we can display something.
  Tag ourtag; // And what our Tag is.

Notice that one of the three variables is a Tag. Then, we wrote our own constructor - the method that's used to create objects of this class. All it does is require a Tag, a source, and a destination text box - and store them in the variables you see above.

  // When we're created...
  public TagButton (Tag ot,TextArea sb,TextField hb)
  {
    // We just reccord everything.
    sourcebox = sb;
    highlightbox = hb;
    ourtag = ot;

    // And we make our own label what the name of our Tag is.
    setLabel(ourtag.tagname);
  }

Oh yes... and uses the setLabel() routine, which we've inherited from a normal Button, to display the Tag's name as it's own. The last part of this class is its event handler:

  // Also, we watch for events. Specifically:
  public boolean handleEvent(Event e)
  {
    // If someone has clicked on us:
    if (e.id == Event.MOUSE_UP)
    {
      // We use the information about where the tag starts and ends...
      sourcebox.select(ourtag.startindex,ourtag.endindex + 1);
      // to pull the text of the tag from the HTML,
      String temp = sourcebox.getSelectedText();
      // and display it for the user.
      highlightbox.setText(temp);
    }

    // (This is necessary for any ordinary handleEvent method you'll write:)
    return(super.handleEvent(e));
    // (Don't forget to do this!)
  }

Feel free to skip back to one of our issues on event handling if you want to brush up on this technique. Rather than having the applet watching all the events and deciding what to do depending on which button originated them, each button handles its own events.

And in the event (ahem) that someone presses it, it uses several methods that are common to text interface objects in Java (check out TextComponent - which both TextArea and TextField inherit from) to pull out text from the source box, starting at the beginning of the Tag and ending at its end, and paste it into the "highlightbox" with setText.

And that's really all it takes. Once the applet sets up the environment and puts a lot of these on the screen, the rest takes care of itself.

So that's it... that's how we got to what you see on the screen. But we're not quite done. Coming up next week, we're going to talk about what's missing from this applet, what's wrong with it, and how it could be done better.

Past installments of Java Jolt