 |
Chapter 5 |  |
|
Chapter 5 | |
One of the more exciting developments in Web technologies is the ability to deliver applications directly to the user's browser, where they are executed on the client machine. These applications are typically small tools, hence the term ``applet,'' that enhance the HTML page being displayed.
Although currently supported only by Netscape Navigator version 2.0 and HotJava from Sun Microsystems,[4] applets, particularly those prepared with the Java language, will become a sizeable part of mainstream Web activity. Many other browser vendors have promised support for Java.
[4] Sun released an alpha version of HotJava in 1995. That version is now obsolete, but a new version has not been released as of March 1996.
Applets, like client-side image maps, represent a shift in the basic model of Web communications. Until recently, all computational work on the Web was performed by the server, with the browser being nothing more than a glorified terminal. With applets and client-side image maps, some or all of the computational load is shifted to the client and browser.
They also represent a way of extending a browser's features without forcing users to purchase or otherwise acquire a new browser, as is the case when developers implement new tag and attribute extensions to HTML. Nor do users have to acquire and install any special application, as is required for helper or plugin applications. This means that once users have a browser that supports applets, you can deliver HTML display and multimedia innovations immediately.
Applets are like other accessory parts of an HTML document. When the page is loaded by the browser, it may contain special tags that identify applets to be downloaded and executed by the browser. Like other Web resources, applets are identified by a URL and retrieved via the normal HTTP protocol.
Once downloaded, the browser provides a portion of the document for the applet to use as its display space. The author may control the size and position of this display area; the applet controls what is presented inside.
After arriving on the browser, the applet begins execution. It has access to a restricted environment within the user's computer. Several applets may be placed in a single document; they all execute in parallel and may communicate with each other.
Applets have access to the mouse and keyboard, and may receive input from the user. They can initiate network connections and retrieve data from other servers on the Internet. In sum, applets are full-fledged programs, complete with a variety of input and output mechanisms, along with a full suite of network services. While the browser may limit their access to its computer system, applets have complete control of their virtual environment within the browser.
There are several advantages of applets, not the least of which is providing more compelling user interfaces within a Web page. For instance, an applet might create a graphical user interface and present the user with menus, choices, text fields, and similar input tools. When the user clicks a button within the applet's region, the applet can respond by displaying results within the region, signalling another applet, or even by loading a completely new page into the browser.
Without applets, interactions between the user and the HTML document are more restricted and less responsive--such as with forms--principally because a server and its incumbent Internet connections are involved. By allowing the action to occur locally via an applet, responsiveness is greatly improved, thereby opening up a wealth of interactive opportunities.
We don't mean to imply that the only use of applets is to enhance the user interface. An applet is a full-fledged program that can perform any number of computational and display tasks on the client computer. An applet might implement a real-time video display, or perform circuit simulation, or engage the user in a game, for instance.
An applet is nothing more than another tool you may use to produce compelling and useful Web pages. Keep in mind that an applet uses computational resources on the client to run and therefore places a load on the user's computer. It can degrade system performance.
Similarly, if an applet uses a lot of network bandwidth to accomplish its task (a real-time video feed, for example), it may make other network communication unbearably slow. While such applications are fun, they do little more than annoy your target audience.
To use an applet correctly, balance the load between the browser and the server: For each page, decide which tasks are best left to the server (forms processing, index searches, and the like) and which tasks are better suited for local processing (user interface enhancements, real-time data presentation, small animations, and so on). Divide the processing accordingly. Remember that many users have slower network connections and computers than you do and design your applets to satisfy the majority of your audience.
Used the right way, applets seamlessly enhance your pages and provide a satisfying experience for your audience. Used improperly, applets are just another annoying bandwidth waster, alienating your users and hurting your pages.
Creating applets is a programming task, not necessarily a job for the HTML author, and certainly way beyond the scope of this book. For details, we recommend you consult any of the many applet programming texts that have recently appeared on bookshelves everywhere, including Java in a Nutshell from O'Reilly & Associates.
Today, one language dominates the applet programming world: Java. Developed by Sun Microsystems, Java is a restricted form of C++ and supports an object-oriented programming style wherein classes of applets can be used and reused to build complex applications. JavaScript, from Netscape Communications, is a simpler and compatible form of Java that makes programming somewhat easier. And, surely, other Java-like applet development environments will emerge as the technology catches on.
By invention, applets built from the same language should run with any browser that supports them. So far, that is the case for Java applets. But the technology is so new it's hard to predict whether cross-platform integrity and universal support for all common browsers and computers will prove a reality or a pipe dream. If the confusion of browsers is any indication.... Well, be forewarned.
The <applet> tag extension currently is supported only in Netscape 2.0 and HotJava. Use it within your HTML document to name an application to be downloaded and executed with the current document and to define a region within the document display for the application's display area. You may also supply alternative content within the <applet> tag for display by browsers that do not support applets.
The <applet> tag defines an application that is downloaded and executed within the current document with its display in a discrete region in the document window. One required attribute identifies the class name of the applet program. Optional attributes let you control the alignment and dimensions of the applet display region and specify an alternative URL for the class' code.
The browser inserts the applet display region into the containing text flow exactly like an inline image--without line breaks, as a single large entity.
Most applets require one or more parameters to control their execution. These parameters are placed between the <applet> tag and its corresponding </applet> end tag using the <param> tag. The browser retrieves the applet program from the server when the HTML document is displayed by the user. It then executes the applet, feeding it parameters from inside the <param> tag. Execution continues until the code terminates itself or when the user stops viewing the page containing the applet.
Like an image, you may control the alignment of an applet's display region with respect to its surrounding text. In fact, the <applet> tag's align attribute honors all the alignment values used by Netscape's <img> tag, including top, texttop, middle, absmiddle, baseline, bottom, and absbottom, as well as left and right alignments for wrapping text. [image alignment, 5.2.6.4]
The alt attribute gives you a way to gracefully tell users something is missing if, for some reason, the applet cannot or will not run. Its value is a quote-enclosed message string that, like the alt attribute for images, gets displayed in lieu of the applet itself.
The alt message is only for browsers that support applets and is there to let the user know that they've disabled applet execution, that the applet may not be accessible, or that the applet may have executed incorrectly. See 5.6.5.8 to find out how to inform users of other browsers why they can't view an applet.
The code attribute is the only required one and defines the class of <applet> program code to be executed. Its value may be either a simple class name or a fully qualified package. Use a conventional name to specify a class. Define packages using a hierarchy of package names separated by periods (.).
For example, to execute an instance of a class named Clock, you might use:
<applet code=Clock> </applet>
Similarly, if the Clock class is part of a package, you might use that package's fully qualified name:
<applet code=time.clock.Clock> </applet>
The browser will locate the code for the applet using the current document's base URL. The browser automatically appends the suffix ``.class'' to the class name. Hence, if the current document's URL is:
http://www.kumquat.com/harvest_time.html
the browser would retrieve the applet code for our Clock class example above as:
http://www.kumquat.com/Clock.class
Package names get handled slightly differently. Each element of the package name becomes a directory within the URL path. Hence, the browser will retrieve our time.clock.Clock package example as:
http://www.kumquat.com/time/clock/Clock.class
The code attribute value is not a URL. Use the codebase attribute to provide an alternative base URL from which the applet code is to be retrieved. The value of this attribute is a URL pointing to a directory containing the class defined by the code attribute. The codebase URL overrides, but does not permanently replace the document's base URL, which is the default if no codebase is used. [URLs, 6.2]
Continuing with our previous example, suppose the Clock class is kept in a separate directory named classes. You could retrieve the applet by specifying:
<applet code=Clock codebase="http://www.kumquat.com/classes/"> </applet>
which resolves to the URL:
http://www.kumquat.com/classes/Clock.class.
Although we used an absolute URL in this example, you also can use a relative URL. For instance, in most cases the applets are stored on the same server as the host HTML documents, so we'd usually be better off, for relocation sake, specifying a relative URL for the codebase, such as:
<applet code=Clock codebase="/classes/"> </applet>
The name attribute lets you supply a unique name for this instance of the code class. This attribute is not required unless you need to reference the applet instance elsewhere in your document via another applet.
For example, suppose you have two clock applets in your document, along with two applets used to set those clocks. You provide unique names for the clocks using the name attribute, then pass those names to the setting applets using the <param> tag, which we discuss below:
<applet code=Clock name=clock1> </applet> <applet code=Clock name=clock2> </applet> <applet code=Setter> <param name=clockToSet value=clock1> </applet> <applet code=Setter> <param name=clockToSet value=clock2> </applet>
Since we have no need to distinguish between the Setter applets, we choose not to name their instances.
Identical to the counterparts for the <img> tag, the height and width attributes define the size of the applet's display region in the document. They both accept values indicating the size of the region in pixels. [<img> height and width, 5.2.6.9]
The display region's dimensions often must match some other applet requirement, so be careful to check these values with the applet programmer. Sometimes, the applet may scale its display output to match your specified region.
For example, suppose our example clock applet should grow or shrink to fit nearly any size display region. Hence, we might create a square clock 100 pixels wide by 100 pixels tall:
<applet code=Clock height=100 width=100> </applet>
As with an image, surrounding text tightly abuts the applet display region. The hspace and vspace attributes let you interpose some empty space around the applet region to set it off from the text. Both attributes accept a value that indicates pixels of space, with the hspace attribute creating a space to the left and right of the region; the vspace attribute adding space above and below the region.
For example, to give our clock some breathing room on the page, we could place an additional five pixels of space around it:
<applet code=Clock height=100 width=100 hspace=5 vspace=5> </applet>
Since most of today's browsers do not support applets or the <applet> tag, you may sometimes need to tell readers what they are missing. You do this by including HTML body content between the <applet> and </applet> tags.
Browsers that support the <applet> tags ignore the HTML content inside. (Use the alt attribute to notify applet-enabled browser users when the applet doesn't display for some reason.) Of course, browsers that don't support applets don't recognize the <applet> tags. Being generally tolerant of apparent HTML mistakes, they will usually ignore the unrecognized tag and blithely go on to display whatever content may appear inside. It's as simple as that. The following fragment tells applet-incapable browser users they won't see our clock example:
<applet code=Clock> If your browser were capable of handling applets, you'd see a nifty clock right here! </applet>
Remember that this contained text is different from the text supplied by the alt attribute of the <applet> tag. The alt text is displayed by browsers that support the <applet> tag but cannot execute or display the specified applet. The contained text is displayed by browsers that do not support the <applet> tag at all. In order to accomodate both classes of browsers, the considerate author supplies both for each <applet> tag:
<applet code=Clock height=100 width=100 alt="[ Clock applet not available ]"> <param name=style value=analog> If your browser were capable of handling applets, you'd see a nifty analog clock right here! </applet>
The <param> tag supplies parameters for the containing <applet> tag.
The <param> tag has no content and no end tag. It appears, perhaps with other <param> tags, only between an <applet> tag and its end tag. Use the <param> tag to pass parameters to the applet program as required for it to function correctly.
The <param> tag has two required attributes: name and value. Both attributes accept strings as their value and together define a name/value pair that is passed to the applet.
For instance, our Clock applet example might let you specify the time zone by which it sets its hour hand. To pass the parameter named ``timezone'' with the value ``EST'' to our example applet, you would specify the parameters as:
<applet code=Clock> <param name=timezone value=EST> </applet>
Since both attributes had simple strings for values, we did not enclose the values in quotes. For values with embedded punctuation and spaces, be sure to delimit the strings accordingly.
The browser will pass the name/value pairs to the applet, but that is no guarantee that the applet is expecting the parameters, that the names and values are correct, or that the applet will even use the parameters. Correct parameter names, including capitalization, and acceptable values are determined by the applet author. The wise HTML document author will work closely with the applet author or have detailed documentation to ensure that the applet parameters are named correctly and assigned valid values.
