URL: http://www.uburst.com/cgi-bin/dcforum/dcboard.cgi
Forum: ushop_applets_shopcart
Thread Number: 89
[ Go back to previous page ]

Original Message
"Netscape 6.1 for Macintosh random applet displays"

Posted by Ben Menix [Admin@MidniteTease.com] on at 03:02 PM
Here's what's going on. As documented elsewhere, I would like to be able to give mac users the ability to shop at my uShop 3 site. Which means IE is out, as well as any browser that uses the Macintosh Runtime for Java. This leave the big N as the best alternative. Unfortunately, it leaves 4.xx versions out at the same time, because of their "interesting" methods of table processing. Thankfully, Netscape 6 for Mac displays my site beautifully, AND runs the applets (albeit slowly...it takes several minutes for my site to load, about the same amount of time as it takes for the uShop demo site to load). However...

When you select a product category from my main menu, or click on one of the specials links, products are returned via a third party cgi program 7 per page. In netscape, USUALLY only the first applet will display, the rest will just be an empty rectangle. Sometimes more than one will display, in no particular order. I have checked this behavior against the uShop demo store. Multiple applets in the demo store work properly.

I originally suspected the problem might be related to the fact that applets for my store are kept in a database record, and there may be errors in the record. I have checked repeatedly, and can't find any errors in the records. Also, since none of the applets consistently refuse to work, I don't think that is the root of the problem.

I quite possibly may need to just alter a few parameters. If anyone is interested, feel free to take a look at www.midnitetease.com.

Ben @ MidniteTease

Table of contents

Messages in this discussion
"RE: Netscape 6.1 for Macintosh random applet displays"
Posted by Bill Weiner on at 05:24 PM
I noticed that you are using a relative codebase of:


... for your database/dynamically generated pages.

What you may have to do is try using the full URL of your classes as the codebase of your applets:


Which (because you would no longer be using the default codebase) would also require that make a couple other changes... as described in Section 3 on the following reference page:


NOTE: I'm not sure if this (using a relative codebase on dynamically generated pages) will cause such "random applet displays" as you mention, but maybe try using the full URL as the codebase on a couple pages first... and if that works out for your Macintosh Netscape 6 browser... then make the change to your other store pages as well.

"Netscape 6.1"
Posted by Ben Menix [Admin@MidniteTease.com] on at 11:20 AM
Thanks, Bill. I hadn't even thought of that. I'll give it a try and post the results.

BTW, in the "egg on my face" department, I did a little (it didn't take much) research and discovered a gaping hole in my hypothesis about MacOS Runtime for Java...Netscape 6.x uses it, as well, not just Explorer, Opera, and iCab. And since Netscape 6 actually works...I finally know who I need to start griping at!

Thanks for your help,
Ben Menix

"Tried that with interesting results..."
Posted by Ben Menix [Admin@MidniteTease.com] on at 05:03 PM
I tried everything you suggested with the codebase parameter. It didn't help Netscape at all, but it sure shortened the amount of time it takes Macintosh IE 5 to load the main site and product listings. IE now loads almost as fast as windows ie, and seldom causes a system freeze or slow-down.

Netscape, however, is still the same. Loading input applets basically makes the machine unusable for the duration of the load, and the output is still random. The worst problem is the cart3 applet on my main page. (Displays subtotal). It takes 3-5 minutes to load, and the computer is "waiting" the entire time, except for brief (1-2 seconds) spurts.

FWIW, I also have Netscape 4.76 loaded on my machine. While it doesn't render my tables properly, it works fine (last I checked...). Of course, 4.x uses a different JRE, which is the most likely explanation right there.

Thanks for the help, Bill,

Ben @ MidniteTease