Checkout
When the client operator is ready to finalize his purchases, then, in our implementation, he presses "CHECKOUT..." This sends the purchase information, as name-value pairs appended to a hard-coded HTTP address, to a central server that is equipped to ask for name, address, and credit-card information. The codebase of the applet or object is also included; this is used to check that the merchant's site has registered with the central server, and that it is authorized to do business.
When the said "CHECKOUT.." button is pressed, the cart is automatically cleared. Pressing "RESET", however, brings the information back, in case the user wishes to change his mind.
In our implementation, one of the fields in the "onClick=buy(a,b,c,d)" event handler is a string that encodes every possible variation of tax and shipping instructions. This information is passed, when a purchase is made, to the said applet or object, which in turn passes it through unaltered to a central server, when the order is finalized, and the said central server processes the order accordingly. I would imagine that there will need to be a table of hundreds of strings; the merchant, in programming the HTML, would flip through the choices and choose the right one, for each item. For instance, one string might means: "Charge $10 shipping and send by UPS." It seems logical that each particular merchant's location-- country, and then state or province-- would be recorded initially when he signed up with the order-processing company. That would be one less thing to encode. If it was done that way, then access to a database at the central computer could work out the proper taxes. The important point is that people at the central location would not ever need to talk to the various multiple merchants. It would then be cost effective for them to provide quality services for a low price.
This shopping cart front end is Open Source. Any commercial company that wishes to provide back end checkout services is free to adapt it to its use, in whatever manner it wishes. However, the techniques of applet reloading and pseudo-constructors used to generate persistence are covered by patent. I give unlimited permission for anyone to use the patents for a shopping cart, and an associated database cache. Any extension of these methods beyond a shopping cart and an associated database cache not only destroys bandwidth for the shopping cart, but is also a violation of my patent rights.
If some company requires a more formal arrangement, before committing resources, I can sign a legal form guaranteeing non-exclusive permission to exploit the patents, as the company wishes, for a shopping cart, and an associated database cache.
In closing, let me suggest one alteration that allows a company to handle multiple merchants on the same cart, at the same time that it also handles orders from the previous small business cart.
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.
