Persistence: Method 1
Examine the cart at http://209.87.142.42/shopcart/Page1.htm. It uses JDK 1.1, and thus requires Explorer 4 or 5, or versions 4.5 and higher of Netscape. Try pressing Reset when the cart comes up. On Explorer, the cart will even survive a Shift-Reset. You can press Reset fast and repeatedly, and you probably won't crash the cart.
Let's look at how it's done. There are two methods, one that involves applet reloading: JAVA applets are in an active state for as long as the HTML page in which they are loaded is on the browser screen. When a jump is made to another page, then the applets that were loaded on the previous page become inactive.
Unless there is a shortage of memory, they are not unloaded. Whenever the browser returns to an applet's page, then the particular applet for that page is not usually reloaded, but rather it is changed from an inactive state back again to an active state. Variables that were set in a previous active stage are remembered during times of inactivity, and can be accessed when an applet again becomes active.
Now, what happens if the same applet (same name, same codebase) is loaded by two separate pages? An applet is identified only by its name and codebase. Thus, if a page loads an applet with the same name as one that was loaded by a previous page, and if this involves a relative (in contrast to an absolute) call to the same codebase, then the applet for the previous page becomes active again - just as if it had been called by the previous page. A new instance of the applet is not usually loaded. This feature is used by the shopping cart to store information between HTML pages. It works much better than cookies.
An applet, however, contains program code as well as variables. Thus, since it is a program that is being re-activated, persistent processing can be carried out on the persistent memory. A program can thus be written that appears to live on from page to page: all that is necessary is to reload the same code. When the user leaves the applet's page, this exit alters the page's applet from an active to an inactive state, and when the user enters a different page that reloads the previous applet through a relative call. This entry changes the applet back again to an active state which uses its previous memory. The new page, as part of the applet's life cycle, calls the applet's init() and start() methods; apart from that, applet program function picks up at the point where it left off on the previous page. If one desires to keep certain variables, then it is enough to declare them as static, and make sure they are linked to static entities - the garbage collector will then leave them alone.
If an applet with the same name but a different codebase is loaded, then, for security reasons, it is assigned a new address space. The same shopping cart code, even when it is run simultaneously on separate commercial sites from the same browser, can therefore develop and maintain distinct shopping carts for the separate merchants. JAVA security, which we exploit here to our advantage, takes care of all the details!
If an HTML document in a subdirectory of a site wishes to participate in the persistence, then it is sufficient to add the line CODEBASE=../ to the APPLET tag. This technique can be extended throughout a directory and subdirectory structure, so that persistence spreads freely throughout any given site. Alternatively, it is often possible to access the applet absolutely, as in CODEBASE=http://www.myserver/myAppletDirectory as long as the applet and the HTML pages are located on the same server. This absolute call is then treated as relative. The boilerplate code now becomes independent of directories and sub-directories.
Applet download time is of course decreased greatly when all classes are placed into a single uncompressed .zip file. It is my understanding that earlier versions of Explorer 4 can find .zip files confusing; the solution is to place the unzipped classes in the same directory as the .zip file. Most browsers simply ignore these extra files, and they may in fact no longer be necessary.
NEXT ->
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
