This page demonstrates the use of SpiralGlyphics in applet form. Originally implemented as a stand-alone Java application, SpiralGlyphics now supports the ability to run directly from any web browser featuring Java 1.1 functionality. Such browsers include Netscape Navigator, Microsoft Internet Explorer, or Sun's HotJava. Without an appropriate browser, or if your browser has Java disabled, the applets will not appear on this page.
Below are three instances of the SpiralGlyphics applet, each passed a different data set in its PARAM tag. The next three instances show how various error conditions are handled.
BackHTML used to place the applets
The Java Plug-in HTML converter was used to convert the applet tags to use the Java Plug-in. The resulting HTML code is too big and hairy to reproduce here, but inspection of this page's HTML source will satisfy curiosity. Notice that the lists of plugins are whitespace delimited, and that the Plugin.class suffix is removed from each plugin name.
Differences between application and applet versions
Immediately you'll notice that the applet embedded in the browser is only a button. This button will launch a SpiralGlyphics window. The reason for this is that applets cannot have frames (including menubars) embedded in the browser window. An alternative would have been to move all GUI menubar components into the work area, but the clutter would have been unbearable, especially with a large number of plugins. Another benefit of this is that a web page can harbor many such applets when they are in button form. If several full-size SpiralGlyphics windows were embedded, page real-estate as well as overall performance would suffer greatly.
The SpiralGlyphics application allowed for the loading of data sets directly from the local filesystem. This behavior is not allowed for applets. However, the applet may request a file from the same server that is serving the applet. In this way, the applet may load any data set available on the server. Similarly, an applet cannot scan the filesystem for available plugins. Instead, we pass the applet a list of available plugins via <PARAM> tags.
For simplicity, all dynamic data set handling has been disabled when running in applet mode. When an instance of the applet is started, it is given the URL of a single data set, which it will then attempt to load. The user may neither save the data set nor load a new one. It is up to the HTML code to specify the data set URL. However, a user-specified data set URL can still be passed to the applet by means of a CGI script. If the applet encounters a URL that does not exist on the same server, the applet will indicate this and do nothing further.
If importation of other data set file formats is ever implemented, the same mechanism can be used for loading the files into applets. Server support for saving modified data sets or for retrieving data sets from foreign servers could also be implemented in the future. These could be handled via CGI scripts or Java servlets, or by implementing a custom security manager for the applet that is less strict.