Persistence: Method 2
Let us now look at the second method for developing persistence between HTML pages. Although it uses abstract classes, we will see that this limitation can be bypassed. In nature, we observe objects like robins and crows, but never things such as "birds." Robins and crows are birds, but birds as such do not exist; they are an abstraction. Similarly, abstract classes in JAVA are a tool for dealing with things that are common to various objects (in nature, for example, commonalities would be wings or beaks)-- they are not themselves instantiated. What we are going to do, in general terms, is take an abstract class which is an abstraction of nothing, and inject code into it, just as a virus inserts its DNA into a cell and takes over the machinery for its own purposes. An infected cell turns out copies of the virus; the abstract class, in our case, simply chooses to "live forever." It is all done, as you will see, with completely standard JAVA coding. The principle will then be extended through standard coding, to classes which are not abstract.
If one looks at abstract classes in JAVA, one notices that they are tied very closely to the JAVA virtual machine. If they could be instantiated, then certainly they would persist; programs could then be remembered along with data, even when the applet was inactive. However, abstract classes cannot contain constructors.
Suppose that applet code is composed solely of pointers to static variables defined in some abstract class (sample code is presented further on). Suppose further that static components for a frame (buttons, etc.), as well as the static name of the frame itself, are also defined in the abstract class. Then, suppose that init() or start() in the applet calls a static function in the abstract class which instantiates the static frame and assigns the static components to it. It then sets a flag in the abstract class that tells it not to do this again. One now has a kind of pseudo-constructor for the abstract class. The resulting frame and its components, are tied through the abstract class, to the JAVA virtual machine itself, and they persist from HTML page to HTML page, even when the applet is not being loaded. The applet that originally launched both the frame and the abstract class may move back and forth from an active to an inactive state, as the user browses from one HTML page to another. This makes no difference to the frame itself, for it is no longer dependent upon the applet.
Now, how do we enable events within this "terminate and stay resident" frame so that it will carry out actions when "off site?" It is done in the following manner (sample code follows):
Events must be caught in the frame itself, but all variables and interrupt methods are contained as static variables and static methods in the abstract class. The frame event handlers simply make jumps to these static variables and methods. Through a use of these two separate persistence techniques-- loading a program repeatedly, and forming a pseudo-constructor for an abstract class-- we have now created a program that lives beyond the page in which it was launched. It also remembers data that is collected from page to page for as long as a page accesses the launching applet through a relative call, and carries out event handling within the frame itself, on applet data, when off-site.
The JAVA program has now broken away from the launching page, and it "lives forever." It is interesting to reduce the browser to a partial window, and to place the shopping cart frame on the desktop beside it. Browse from page to page, and watch the frame: it doesn't flicker, and the buttons continue to work. JAVA in the frame is fully enabled at all times.
There appears to be a small restriction. If you are running JAVA off-site (if you force the cart to do something by pressing a button), and if the resulting event-handling uses "new" to create a variable, and if at the same time the browser is working very hard at carrying out programming in a page, then it is theoretically possible to crash the browser. In plain language, suppose that the shopping cart frame breaks free of the launching site and you go to some other point in cyberspace, such as the Mars Lander site, starting some big VRML program. Then, as it is in the middle of calculations, and things are changing on the screen, if you bring up the persistent shopping cart frame and begin pushing buttons, you can probably provoke a crash. However, it takes a good deal of careful manual dexterity.
The solution here is simple: Avoid the use of "new" in any JAVA programming that is triggered when off-site. I have tested this, and it appears to make it impossible for even the most obnoxious person to crash the cart. This step has not been taken in the current code because it can involve the use of global static variables, and these make further program development very difficult. Also, the slight potential instability off-site does not appear to be a problem at all for this shopping cart in every-day usage.
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.
|
