Полезная информация

Exploring Java

Previous: 3.3 The Java CompilerChapter 3
Tools of the Trade
Next: 3.5 Packaging: Java Archive (JAR) Files
 

3.4 The Applet Tag

Applets are embedded in HTML documents with the <APPLET> tag. The <APPLET> tag resembles the HTML <IMG> image tag.[1] It contains attributes that identify the applet to be displayed and, optionally, give the Web browser hints about how it should be displayed. The standard image tag sizing and alignment attributes, such as height and width, can be used inside the applet tag. Unlike images, however, applets have both an opening <APPLET> and a closing </APPLET> tag. Sandwiched between these can be any number of <param> tags that contain application-specific parameters to be passed to the applet itself:

[1] If you are not familiar with HTML or other markup languages, you may want to refer to HTML: The Definitive Guide, from O'Reilly & Associates, for a complete reference on HTML and structured Web documents.

<applet attribute [ attribute ] ...  > 
[<param parameter >] 
[<param parameter >] 
... 
</applet> 

3.4.1 Attributes

Attributes are name=value pairs that are interpreted by a Web browser or appletviewer. (Many HTML tags besides <APPLET> have attributes.) Attributes of the <APPLET> tag specify general features that apply to all applets, such as size and alignment. The definition of the <APPLET> tag lists a fixed set of recognized attributes; specifying an incorrect or nonexistent attribute should be considered an HTML error.

Three attributes are required in the <APPLET> tag. Two of these attributes specify the space the applet occupies on the screen: not surprisingly, they're named width and height. The third required attribute may be either code or object; you must supply one of these attributes, and you can't specify both. The code attribute specifies the class file from which the applet is loaded; the object attribute specifies a serialized representation of an applet. Most often, you'll use the code attribute; the tools for creating serialized applets aren't quite there yet. (Serializing an applet, or any Java class, means saving it, perhaps after customizing it, for use later. You can use appletviewer to create serialized applets, but that feature isn't really useful yet. Serialized applets will become interesting when the next generation of integrated development environments for Java are available.)

The following is an HTML fragment for a hypothetical, simple clock applet that takes no parameters and requires no special HTML layout:

<applet code=AnalogClock width=100 height=100></applet> 

The HTML file that contains this <APPLET> tag must be stored in the same directory as the AnalogClock.class class file. The applet tag is not sensitive to spacing, so the above is therefore equivalent to:

<applet 
    code=AnalogClock 
    width=100 
    height=100> 
</applet> 

You can use whatever form seems appropriate.

3.4.2 Parameters

Parameters are analogous to command-line arguments; they provide a way to pass information to an applet. Each <param> tag contains a name and a value that are passed as strings to the applet:

<param name = parameter_name value = parameter_value> 

Parameters provide a means of embedding application-specific data and configuration information within an HTML document.[2] Our AnalogClock applet, for example, might accept a parameter that selects between local and universal time:

[2] If you are wondering why the applet's parameters are specified in yet another type of tag, here's the reason. In the original alpha release of Java, applet parameters were included inside of a single <app> tag along with formatting attributes. However, this format was not SGML-compliant, so the <param> tag was added.

<applet code=AnalogClock width=100 height=100> 
    <param name=zone value=GMT> 
</applet> 

Presumably, this AnalogClock applet is designed to look for a parameter named zone with a possible value of GMT.

Parameter names and values can be quoted to contain spaces and other special characters. We could therefore be more verbose and use a parameter value like the following:

<param name=zone value="Greenwich Mean Time"> 

The parameters a given applet expects are determined by the developer of that applet. There is no fixed set of parameter names or values; it's up to the applet to interpret the parameter name/value pairs that are passed to it. Any number of parameters can be specified, and the applet may choose to use or ignore them as it sees fit. The applet might also consider parameters to be either optional or required and act accordingly.

3.4.3 ¿Habla Applet?

Web browsers ignore tags they don't understand; if the Web browser doesn't interpret the <APPLET> or <PARAM> tags, they should disappear and any HTML between the <APPLET> and </APPLET> tags should appear normally.

By convention, Java-enabled Web browsers do the opposite and ignore any extra HTML between the <APPLET> and </APPLET> tags. This means we can place some alternate HTML inside the <APPLET> tag, which is then displayed only by Web browsers that can't run the applet.

For our AnalogClock example, we could display a small text explanation and an image of the clock applet as a teaser:

<applet code=AnalogClock width=100 height=100> 
    <param name=zone value=GMT> 
    <strong>If you see this you don't have a Java-enabled Web 
    browser. Here's a picture of what you are missing.</strong> 
    <img src="clockface.gif"> 
</applet> 

3.4.4 The Complete Applet Tag

We can now spell out the full-blown <APPLET> tag:

<applet 
    code = class name    --or
    object = serialized applet name 
    width = pixels wide 
    height = pixels high 
    [ codebase = location URL ] 
    [ archive = comma separated list of archives files ] 
    [ name = instance name ] 
    [ alt = alternate text ] 
    [ align = alignment style ] 
    [ vspace = vertical pad pixels ] 
    [ hspace = horizontal pad pixels ] 
> 
[ <param name = parameter name value = parameter value> ] 
[ <param name = parameter name value = parameter value> ] 
... 
[ HTML for non Java aware browsers ] 
</applet> 

Either the code attribute or the object attribute must be present to specify the applet to run. The code attribute specifies the applet's class file; you'll see this most frequently. The object attribute specifies a serialized (pickled) representation of an applet. When you use the object attribute to load an applet, the applet's init() method is not called. However, the serialized applet's start() method is called.

The width, height, align, vspace, and hspace attributes have the same meanings as those of the <IMG> tag and determine the preferred size, alignment, and padding, respectively. The width and height attributes are required.

The codebase attribute specifies the directory in which the applet's class file (or archive file) is located. If this attribute isn't present, the browser looks in the same directory as the HTML file. The archive attribute specifies a list of JAR or ZIP files in which the applet's class file is located. To put two or more files in the list, separate the filenames by commas; for example, the attribute below tells the browser to search three archives for the applet:

archive=Part1.jar,Part2.jar,Utilities.jar
The archive attribute must be present if you have packaged your applet in one of these archives. When searching for classes, a browser checks the files listed in the archives attribute before searching any other locations on the server.

The alt attribute specifies alternate text that is displayed by browsers that understand the <APPLET> tag and its attributes, but can't actually run applets. This attribute can also describe the applet, since in this case any alternate HTML between <APPLET> and </applet> is ignored.

The name attribute specifies an instance name for the executing applet. This is a name specified as a unique label for each copy of an applet on a particular HTML page. For example, if we include our clock twice on the same page (using two applet tags), we could give each instance a unique name to differentiate them:

<applet code=AnalogClock name="bigClock" width=300 height=300></applet> 
<applet code=AnalogClock name="smallClock" width=50 height=50></applet> 

Applets use instance names to recognize and communicate with other applets on the same page. We could, for instance, create a "clock setter" applet that knows how to set the time on an AnalogClock applet and pass it the instance name of a particular target clock on this page as a parameter. This might look something like:

<applet code=ClockSetter> 
    <param name=clockToSet value="bigClock"> 
</applet> 

3.4.5 Loading Class Files

The code attribute of the <APPLET> tag should specify the name of an applet. This is either a simple class name, or a package path and class name. For now, let's look at simple class names; I'll discuss packages in a moment. By default, the Java run-time system looks for the class file in the same location as the HTML document that contains it. This location is known as the base URL for the document.

Consider an HTML document, clock.html, that contains our clock applet example:

<applet code=AnalogClock width=100 height=100></applet> 

Let's say we retrieve the document at the following URL:

http://www.time.ch/documents/clock.html

Java tries to retrieve the applet class file from the same base location:

http://www.time.ch/documents/AnalogClock.class

The codebase attribute of the <APPLET> tag can be used to specify an alternative base URL for the class file search. Let's say our HTML document now specifies codebase, as in the following example:

<applet 
    codebase=http://www.joes.ch/stuff/ 
    code=AnalogClock 
    width=100 
    height=100> 
</applet> 

Java now looks for the applet class file at:

http://www.joes.ch/stuff/AnalogClock.class

3.4.6 Packages

Packages are groups of Java classes. A package name is a little like an Internet hostname, in that they both use a hierarchical, dot-separated naming convention. A Java class file can be identified by its full name by prefixing the class name with the package name. We might therefore have a package called time for time-related Java classes, and perhaps a subordinate package called time.clock to hold classes related to one or more clock applications.

In addition to providing a naming scheme, packages can be used to locate classes stored at a particular location. Before a class file is retrieved from a server, its package-name component is translated by the client into a relative path name under the base URL of the document. The components of a class package name are simply turned into the components of a path name, just like with classes on your local system.

Let's suppose that our AnalogClock has been placed into the time.clock package and now has the fully qualified name of time.clock.AnalogClock. Our simple <APPLET> tag would now look like:

<applet code=time.clock.AnalogClock width=100 height=100></applet> 

Let's say the clock.html document is once again retrieved from:

http://www.time.ch/documents/clock.html

Java now looks for the class file in the following location:

http://www.time.ch/documents/time/clock/AnalogClock.class

The same is true when specifying an alternative codebase:

<applet 
    codebase=http://www.joes.ch/stuff/ 
    code=time.clock.AnalogClock 
    width=100 
    height=100> 
</applet> 

Java now tries to find the class in the corresponding path under the new base URL:

http://www.joes.ch/stuff/time/clock/AnalogClock.class

One possible package-naming convention proposes that Internet host and domain names be incorporated as part of package names to form a unique identifier for classes produced by a given organization. If a company with the domain name foobar.com produced our AnalogClock class, they might distribute it in a package called com.foobar.time.clock. The fully qualified name of the AnalogClock class would then be com.foobar.time.clock.AnalogClock. This would presumably be a unique name stored on an arbitrary server. A future version of the Java class loader might use this to automatically search for classes on remote hosts.

Perhaps soon we'll run Sun's latest and greatest Web browser directly from its source with:

% java com.sun.java.hotjava.HotJava

3.4.7 The OBJECT Tag

The <APPLET> tag that we described in the previous section is currently the standard for embedding Java applets into HTML, but many other kinds of embeddable objects, in addition to applets, are on the Web. There are new multimedia types like audio, video, and VRML, and there are browser plug-ins that also need to be recognized in Web documents. It is logical that as the Web matures, HTML standards will come to adopt a more generic (less Java-specific) method for embedding objects like Java applets into Web documents.

The universal <OBJECT> tag[3] that is being defined by the World Wide Web Consortium (W3C) in cooperation with Sun, Netscape, Microsoft, and others is the ordained successor to the <APPLET> tag. The <OBJECT> tag supersedes <APPLET>, along with Netscape's <EMBED> tag, Microsoft's <DYNSRC> tag, and even the generic HTML <IMG> element tag. It unifies syntax for embedding all kinds of multimedia objects into HTML.

[3] The <OBJECT> tag is currently defined by the W3C draft: "Inserting Objects into HTML." See http://www.w3.org/TR/.

The <OBJECT> tag has many similarities with the <APPLET> tag. We'll just give a few brief examples here. These work in the latest versions of Netscape Commmunicator and Sun's HotJava browser and appletviewer.

As simple applet is embedded like so:

<object classid="java:time.clock.AnalogClock" codebase="time1.jar,time2.jar" 
	height=100 width=100>
</object>

The classid attribute specifies the object's class, like the code attribute of the <APPLET> tag. But the classid attribute also requires a colon-separated prefix specifying what kind of object code it is. For an applet this is "java:". As with the <APPLET> tag, the optional codebase attribute can be used to specify a URL for loading class files. But the <OBJECT> tag's codebase attribute can also take the place of the <APPLET> tag's archive atttribute. In the above we have specified two JAR files to be loaded with our applet.

As with the <APPLET> tag, you can place HTML for backward compatability inside the opening and closing <OBJECT> tags. A browser that doesn't recognize the <OBJECT> tag will ignore it and use the HTML inside.

<object classid="java:time.clock.AnalogClock" codebase="time.jar"
    height=100 width=100>
<applet code=time.clock.AnalogClock archive="time.jar"
    height=100 width=100>
<h3>You're browser does not support Java</h3>
<img src="whatyouremissing.gif">
</applet>
</object>

You can also use the <OBJECT> tag to load a serialized Java object. This feature is especially important for support of Java Beans.

<object codebase="time.jar"
    data="time/clock/AnalogClock.ser"
    type="application/x-java-serialized-object"
</object>

The above uses the data attribute to specify a serialized Java object in the JAR file. In this case a serialized Java object is treated more as a data type than an application. type specifies the MIME type of the object.

3.4.8 Viewing Applets

Sun's JDK comes with an applet-viewer program aptly called appletviewer. To use appletviewer, specify the URL of the document on the command line. For example, to view our AnalogClock at the URL shown above, use the following command:

% appletviewer http://www.time.ch/documents/clock.html 

appletviewer retrieves all applets in the specified document and displays each one in a separate window. appletviewer is not a Web browser; it doesn't attempt to display HTML. It's primarily a convenience for testing and debugging applets. If the document doesn't contain <APPLET> tags, appletviewer does nothing.


Previous: 3.3 The Java CompilerExploring JavaNext: 3.5 Packaging: Java Archive (JAR) Files
3.3 The Java CompilerBook Index3.5 Packaging: Java Archive (JAR) Files

Other Books in this LibraryJava in a NutshellJava Language ReferenceJava AWTJava Fundamental ClassesExploring Java