Source: Dr Dobbs Journal

The technique I use to circumvent this problem is simple but effective--I use the functions setAppletsReady and appletsReady and a hidden input field in a form called appletmonitor. The field's value is initially set to 0.1 then install the function setAppletsReady (which sets the field's value to 1) as the onload handler for the page. Since the onLoad event is not fired until the applets on that page are loaded, setAppletsReady is not called until all applets on that page are loaded. Subsequent calls to appletsReady return the value of the hidden field, indicating whether or not the onLoad event has fired. If appletsRead returns 1, then it is safe to call the applets, otherwise not. The current operation can then block until the applets load, or return an appropriate status message to the user. It may be true that your worker applets are called for the first time only after the user provides some form input, which gives the applet extra time to load. In these cases it may be safe to omit checking whether onLoad has fired. Checking the status of the appletmonitor form, however, is the safer route. It is also possible that you will encounter a browser in which the semantics of the onLoad event don't include waiting for applets. In this case, the technique won't work, and you'll have to find another way of guessing whether the applet is there without actually calling it.

The Data Store The purpose of the Data Store pattern is to provide an efficient way to store and retrieve state or session data during a web session, such as is commonly tracked in shopping-cart applications. If you want to collect data during a web session, and then perhaps operate on that data and use it to make decisions later in the session, you will be implementing a data store of some kind. The Data Store pattern describes how to build a reusable data storage class, and is applicable when the state data needn't persist between sessions. If the data must persist between browser sessions, you can either use JavaScript cookies or a tool like the Java Persistent Storage Engine (PSE) from Object Design (http://www.odi.com/). The PSE provides for persistent storage of objects on the client machine, and has the advantage over cookies that objects need not be flattened out by the programmer for storage. (PSE is soon to be bundled with Netscape Navigator.) The benefits of the Data Store pattern are encapsulation of data storage and retrieval functionality (such as returning data based on filters or sort-orders). A liability of a Data Store class (or applet) is the fact that as data storage, it can only persist as  long as its containing web page is active. In other words, when the page is gone, the applet is gone; and when the applet is gone, your data is gone. When implementing a Data Store, as in Example 1, consider the following criteria:

• Do you need between-session persistence? If so, consider cookies instead of an applet.
• Do you need to retrieve the session datain a special way (sorted, filtered or otherwise operated on)? You will want to provide auxiliary methods for performing these operations on your data.

Notice in Example 1 that the applet does not provide implementations for most of the standard applet methods like start() and stop( ). The applet does not perform any continuous processing nor does it need to be stopped by the browser when it is scrolled beyond the current viewport. This Data Store applet implements two custom methods that are minimally required of any Data Store. The put and get methods store and retrieve respectively session data in the HashMap. These two custom methods can be overloaded to handle other complex data types. Keep in mind however that JavaScript takes HTML form field values to be strings, and that some conversion may be necessary. If you want to apply a filter to session data before retrieving it you could implement one or more methods like the applyFilter method in Example 1 (which includes methods for retrieving the name of the current filter and resetting filtering). Filters would be applied by the get method during subsequent calls. Which would return only entries that meet the filter criteria. A sort order could be applied using a similar set of methods. Other implementation decisions about a Data Store include issues like duplicate keys, which can be accommodated by choosing an appropriatedata structure.

Example 1: Data Store applet

public class DataStore extends Applet 
{
private HashMap hmap;
public void init() { /* initialize hmap */ } 
public void put(String strKey, String strValue) { /* add to hmap */ } 
public String get(String key) { /* retrieve from hmap */ } 
public void applyFilter(Filter f) { /* ? */ } 
public String currentFilter() { /* ? */ } 
public void resetFilter() { /* ? */ }