If either A or B fails, there is no point in continuing. Test C is exactly the same, except the URL contains "?query=test". If D and E succeed, then we've got a winning environment. If D or E fails, open up "search.html" and change the tenth line from:
var testInnerFrame = true;
to
var testInnerFrame = false;
Mac OS X 10.2.8 / Safari 1.0.3
A (Test OK)
B,C,D,E (Success)
Mac OS X 10.2.8 / Firefox 1.0
A (Test OK)
B (Success)
C,D,E (never loads or java.lang.ClassNotFoundException)
Windows XP / IE 6.0 SP2
A (Test OK)
B,C,D,E (Success)
Windows XP / Firefox 1.0
A (Test OK)
B (Success)
C,D,E (Success)
(non-repeatable NullPointerException once)
Communicate with a Java Applet through the underlying HTML. Find the best solutions for the most platforms and browsers.
Firefox/Mac craps out when there is a "?" in the URL over the "file://" protocol. No work-around.
Firefox/Mac doesn't like to have applets writen after the page has loaded. No work-around.
Safari/Mac has odd behavior regarding IFRAME. Changing the location applies to the parent DOM. Manipulating the DOM inline might work better than either IFRAME or document.(over)write. It's a bug but not a problem.
IE 6 / SP2 blocks applet because certificate is not verifiable. I wonder if that's really a feature. But of course, the work-around is shelling out some cash for a cert.
In most cases, the reload takes over top frame rather than the IFRAME as expected. Why is that? What is the codebase/scope of the applet? The frame it's in or the top parent?
internalframe.document.write( strHtml )
The Mac (and other platforms/browsers) does not support LiveConnect nor a scriptable JVM. The only way I can think of to pass arguments to Java is by dynamically adding an applet to the DOM, passing applet/object params.
A feature requirement is to preserve state (new search or navigation through various hit pages (next, previous)) to be stored in the browser history. This can either be accomplished by generating a unique temp file (as in this example) or by Http/Get (when the user clicks "search" as opposed to "runInLine").
I've decided to try temp files again because (1) Lucene is doing it also ("He started it, Mommy!") and because (2) JApplet and JEditorPane are too slow (particularly with Mac/Firefox -- although I am open to the possibility I'm not handling threads correctly). There is no state preserved using JEditor, unless we pass the arguments via Http/Get, which doesn't get us any closer to the solution. Finally, since I can both access Java from Javascript and fully manipulate the DOM in Windows, temp files will only be an issue for Mac and Linux users (who, sorry to say, will have to deal with these minor inconveniences).
I'm only using the IFRAME because I thought we could get around Firefox/Mac's fear of the dangerous "?". Although, I think it's a nice feature if we do preserve the ?query=search URL.
The javascript is a bit overkill for these tests, but they are simply cut from the full Vicaya source and model the real situation. If you want to play with the Java applet, you will need to sign the jar because we jump out of the sandbox to make the temp file (Vicaya both reads and writes to disk). I have a README.txt about the whole process in previous Vicaya releases.
There's an ANT build script that does everything but sign the jar. If you have a certificate:
jarsigner Reloader.jar CERTNAME
I would love to hear feedback: alexgenaud@yahoo.com
Alex