Inter- (and Intra-) applet Communication Tips
The background for this topic is discussed elsewhere in the context of describing the evolution of this website. Here the implementation of a general approach for communication among Java applets is outlined.
The approach capitalizes on Java's object orientation and in particular on the fact that the language allows one to define class as well as instance variables. The more common instance variables allow an (instance of) an object to encapsulate its data; that is, to maintain varying degrees of privacy with respect to the values of its properties. Class variables, on the other hand, provide a vehicle for sharing data among objects.
EarthStones' class library includes a WebSite class which is never instantiated and whose sole purpose is to supply shared memory that can be accessed by any other class. This class has three private static (i.e., class) variables: applets, webs, and sites. Each of these is an index (actually, a Java Hashtable object) which allows storage and retrieval of key-value pairs using a set of public static methods.
Interapplet Communication
The applets index is the key to communication between applets. An applet which is to serve as a commuications host must be deployed with the following <param> tag:
<param name="id" value=12345>
where the value can take any integer value. When the applet's initialization method encounter this tag it register's itself with the WebSite object by invoking the following method:
WebSite.registerApplet(id, this)
This method makes an entry into the applets index using id, the integer value passed in the <param> tag, as the key and the applet object itself as the value. Because the webs and sites indices use an applet object as their keys, any other applet that knows the (unique) id of the host applet will be able to communicate with it.
To pass the host's id to another applet, simply put an identical <param> tag in its <applet> tag. When this client applet is initialized it will make the following method call
WebSite.applet(id)
which returns a reference to the host applet.
This approach attempts both to allow any applet to allow another applet to talk to it while at the same time preventing unwanted communication. The use of the WebSite object with its static index variables means that any applet running on the same Java Virtual Machine has potential access to a host applet simply by used a static reference to the WebSite class. Notice than it does not matter whether the applets reside in the same HTML document, in different documents running in different frames in the same browser window, or even in completely separate browser instances running on the same machine. As long as the client applet knows its host's integer id, it can establish contact.
The host applet can, in turn refuse all communication by simply omitting the id <param> tag entirely. In this case it is never registered in the applets index and any attempt to reference it using any id value will be refused. It would also be possible to implement another level of security by using a client id as well as host id. In that case, even if a client applet has the correct host id, the host could refuse communication with an applet whose client id was not on an approved list. At present this additional step appears unnecessary.
Transparent Communication Within and Between Applets
Having established that a client applet can communicate with a host applet, it remains to be demonstrated how this can be used to permit the host to talk to the client and how this communication channel can be used to allow transparent communication both within and between applets. The key to this issue is the Web object.
When a host applet is initialized it creates an instance of Web which it registers with WebSite through the method call:
WebSite.registerWeb(this, aWeb)
The registerWeb method adds an entry to WebSite's webs index using the applet itself as the key (i.e., this refers to the host applet itself) and the instance aWeb of Web as the value. The Web class, in turn, defines instance variables which store references to the major elements of the user interface: banner, footer, graphic, document, and altDoc. When each of these interface elements is created, the object is registered with aWeb by setting is corresponding instance variable. For example, the method FooterPanel.init() includes the statement
WebSite.aWeb.setFooter(footer)
Subsequent to this method call, any class has access to the instance footer of class FooterPanel simply by invoking the method
WebSite.webs(webApp).footer()
which will return a reference to footer.
In the case that footer is a panel of the host applet itself webApp is just a reference to that applet and any other component (e.g., a document panel with hyperlinks) can then talk to theFooter as long as it also has access to a reference to the host applet webApp. Thus intra-applet communication is established.
However, the same mechanism permits communication among components of different applets. In this case, the client applet does not create its own instance of the Web object. Rather it uses its reference (call it webApp obtained as described above) to get access to the instance of Web already registerd by the host. In this manner, the client applet can actually implement the footer panel and can register it with the host's Web object by calling
WebSite.webs(webApp).setFooter(footer)
As a result, the host applet can transparently reference the footer object and the same code can be used regardless of whether the footer panel resides in the host applet itself or in a client applet. To see a demonstration of this in a separate browser window, click here.1
In Version 2 of this website, the banner and footer (as well as graphic) panels are deployed as separate applets. In Version 3, JSite incorporates all of them in a single applet.
One final object should be mentioned briefly before concluding this topic. Although the Web object is the central clearing house for information about the current website's user interface, another Java object Site is the workhorse when it comes to the site's behind-the-scene's structure. An instance of the Site class encapsulates the structure of the website as a whole and includes all the information necessary to get it up and running in the user's browser, from general parameters such as defaultLinkColor and footerIcons through lists of sections, chapters, and pages that make up its hierachical organization. See documentation for the Site class for more information.
As with the Web object, an instance of Site is created only by the host applet, is registered in WebSite using parallel methods, and is thus available to any client applets.
1This demo cannot be run from your local file system. You can access it from EarthStones' website. Or you may copy the file EarthStones/html/InterappletCommunicationDemo.htm to your server and run it from there. In the latter case, make sure the codebase references in the <applet> tag are correct for the server's file system.