|
|
JavaBoutique : Articles :
| Contents |
| Introduction |
| Persistence: Method 1 |
| Functionality |
| Persistence: Method 2 |
| Illustration: Example 1: Applets |
| Illustration: Example 2: Active X |
| Illustration: Example 3: Pseudo-Constructor |
| The Code |
| Extended Examples |
| Shopping Cart and Database |
| Checkout |
| Multiple Merchants |
| Conclusion |
Open Source Shopping Cart
Directives for Browser-based Memory and Multiple Merchants on One Cart With a Dumb Server and No Cookies
by Lane Friesen
Every browser contains a JAVA virtual machine that remains unchanged no matter where the user jumps in cyberspace. I have developed a way to link data and program elements to the JAVA virtual machine so that they can be accessed from one HTML page to another as a kind of HTML "memory." In another technique, I instantiate GUI elements that break free from the launching page and persist until the browser is closed. Both methods use standard JAVA, and respect security limits. I have combined these two methods to write a shopping cart front end that I am releasing as Open Source.
I watched, recently, as a small web service provider developed commercial sites for small businesses. The biggest expense was a shopping cart - a good one cost hundreds of dollars per site. It placed large amounts of JavaScript on each HTML page. The designer's creativity was restricted. Some months later, I spoke with a Seattle-based company that is preparing to host multiple corporate sites on the same shopping cart. Large Sun computers maintained memory at the server. Thousands of JAVA threads were left open for up to an hour. Design freedom was available, but only at the expensive cost of an superstructure beyond the financial means of smaller corporations.
The Open Source shopping cart solves these problems. It comes in two versions-- one for the small web designer, the other for the large company. We will first examine the small business version.
Any existing web site can be transformed into a commercial site through the addition of two lines of boilerplate code-- the first line loads an applet, the second line defines a JavaScript function called " buy." These two lines launch a frame which persists for as long as is desired, no matter where you browse, and which keeps a running total of purchases, from page to page within a site. If another merchant uses the same cart, then a separate frame is launched. There are no delays when purchases are made, because everything occurs on the client browser. Except for a one-time initial download of the applet and its classes (14K of code), there are also no delays when jumps are made from one commercial page to another. This is because the applet (414 bytes in size) and its memory are simply transferred without a reload. An optional database of price updates is downloaded from the server, cached on the browser, and also carried from page to page. Again, there are no delays, except for the initial download. In the current version, orders are finalized by sending them to a fixed address. Open Source modifications could easily be made that allow the merchant to process his own order.
The purchaser need not finalize his order straight off, since the shopping cart travels with him throughout cyberspace. When he finally does choose to check out his cart, he still has the option of changing his mind; he can later restore the cart and send out another finalization.
Items are sold by triggering a JavaScript event which calls the pre-defined function "buy," giving a web designer total freedom. Suppose that a merchant has already spent several thousand dollars on a web site and wishes to make it commercial. His web site designer can now do this for him, using his existing pages, probably in less than one hour. Since the shopping cart is Open Source, an hour's charge for labor will be the merchant's only cost. This design freedom is possible with a host that is completely "dumb," because memory is maintained on the browser, through links to the JAVA virtual machine. The merchant will not need to change his hosting or use active server pages.
The cart can be run off-line. For instance, large mail order companies presently distribute expensive catalogs by mail. In place of a $5 catalog, and associated mailing costs, these companies could send out 50 cent CD-ROMs, for much lower mailing charges, containing the artwork for their catalogs, converted to web pages and then commercialized through the insertion of the two lines of boilerplate code and appropriate event triggers. CD-ROMs for different areas of the country could contain differing "update.txt" files to allow for regional price variations. Since the CD-ROM would be run on a local computer, large update files could be used and would be loaded almost instantaneously. The customer could browse at his leisure, on a fast local connection, and then finalize his order by going on-line briefly and checking out.
I look forward to seeing commercial sites that are fast and clever, and go beyond the grid-like lists that are currently generated by our present shopping carts.
|
Applet Index (sorted alphabetically) A B C D E F G H I J K L M N O P Q R S T U V W X Y Z #s |
The Java Source (applets w/source code) A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
Find out about becoming a Java Boutique sponsor.
All Rights Reserved. Legal Notices.
