launch applet with APPLET or PLUGIN

[Thomas Weidenfeller]

With 1.2 Swing was not part of the distribution, but you could add
your own jar if you wanted to experiment.

1.2 already included Swing. The separate download was for 1.1.x.

/Thomas

 

[Andrew Thompson]

With 1.2 Swing was not part of the distribution,

Yes it was. Most definitely 1.2.

..but you could add
your own jar if you wanted to experiment.

No, that was 1.1. But I have never seen on applet that
attempted to run Swing in 1.1, using the external Swing jar.

 

[Andrew Thompson]

1.2 already included Swing. The separate download was for 1.1.x.

And just in case Roedy does not believe either of us,
I hunted down this info. 'straight from the horse mouth'.
<http://java.sun.com/products/archive/j2se/1.2.2_017/compatibility.html#api>

 

[cym tronik]

Very few Java developers would dare risk running Swing
using Java 1.2*, but would probably specify 1.4 as the
minimum Java required. * Though the Swing classes were
incorporated in the 1.2 core classes, a lot of them had
quirky bugs, as I understand.

I have just written that JSP file that is supopsed to launch an
applet. The actual HTML code, including the Java version and all, was
generated by Tomcat 5.5.9, the latest version (!), not me. Is it naive
from my part to let Tomcat handle JSP files ? Surely not, it is
precisely its purpose.

Cym

 

[Andrew Thompson]

..Is it naive from my part to let Tomcat handle JSP files ?

<long answer>
It is naive to presume that plain old HTML will render
reliably in UA's. Let alone HTML with applets. Let
*alone* applets within HTML being generated by JSP.
</long answer>

<short answer>
Yup.
</short answer>

Continue 'letting' Tomcat serve your JSP files.
Use the APPLET element and the JavaVersionApplet if this
whole OBJECT/EMBED mess is too much for you, or specify a
version in the jsplugin tag.

But there is nothing more, or less magical about
either Tomcat or JSP. HTML breaks, browsers break,
s**t happens. This is the internet.

Use every resource you have and presume nothing, and
when things do break (as will happen), find a way
around it and move on (or go insane). I am moving on.

 

[Chris Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Thompson wrote:
[snip]

If you want to 'blame' anybody for this mess, put the
blame where it belongs, Mozilla. It is the Mozilla
family of browsers that introduced the <EMBED> element.

Despite the common acceptance of the <OBJECT> element
(including by the W3C, the HTML recommendation group
that decides what will, and will not, be considered
valid HTML), Mozilla is still pushing this idiotic
structure some.. 6, 7(?) years after it should have
been considered a lost battle.

The Mozilla family of browsers are generally good
user agents, but that aspect of them, irk's me no end.

Hi,
I heartily agree. W3C recommendations are exactly what the Web should
work on. HOWEVER, I discovered a couple of years ago that Mozilla and
Firefox have, at least for those past couple of years, supported the
<object> element, at least for embedding Flash in a page. I haven't
tried it with applets, so I don't know if it works. In fact, it's
possible to use a single <object> element to embed a Flash file that
works in both Mozilla and IE. What's more... it's valid HTML!

In case you were wondering:

<object type="application/x-shockwave-flash" data="movie.swf"
width="500" height="500">
<param name="movie" value="movie.swf">
</object>

does the job. I don't think this'll prompt the user to download the
plugin (at least not in some browsers), but it DOES get the movie
playing if the plugin's already there.

I have to say I was pretty impressed when I found this out. It was on a
page called Flash Satay, at

http://www.alistapart.com/articles/flashsatay/

In fear of being off-topic for cljp: I would be interested to know if
anyone's figured out an equivalent for Java applets.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDC9MS6ZGQ8LKA8nwRAtsqAKCjRbOOOvG7fEPvkh6xVLvmXqvf2wCgoceD
XuiFwl5Hf+vGdgBF4F/WEzo=
=QKOb
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

...I discovered a couple of years ago that Mozilla and
Firefox have, at least for those past couple of years, supported the
<object> element, at least for embedding Flash in a page. I haven't
tried it with applets, so I don't know if it works.

Nope. Check the single call to 'object' - last list item.
<http://www.physci.org/test/appletcall/>

 

[Chris Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nope. Check the single call to 'object' - last list item.
<http://www.physci.org/test/appletcall/>

Hi,
Damn, I'm _ALMOST_ there. The following code is valid HTML and works in
both Firefox and IE. The ONLY problem is that it displays a broken image
icon in IE beside the real applet. Switching which <object> is inside
the other doesn't help either (yes, I stole your applet for testing...
hope you don't mind):

- --- CUT ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Foo</title>
</head>
<body>
<object type="application/x-java-applet" data="LabelApplet.class"
width="80" height="30">
<param name="code" value="LabelApplet.class">
<param name="message" value="Foo!">
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
type="application/x-java-applet" data="LabelApplet.class" width="80"
height="30">
<param name="code" value="LabelApplet.class">
<param name="message" value="Foo!">
</object>
</object>
</body>
</html>
- --- CUT ---

If an <object> element _has_ a classid, it works with IE but not Firefox.
If it _doesn't_ have a classid, it works with Firefox but not IE.
Go figure. It's *so* close. IE seems to ignore the rule that an
unrenderable <object> should be replaced with its contents (rather than
its contents displayed beside it... damn IE). It ALSO ignores the rule
that an <object>'s contents should NOT be rendered if the <object>
itself is rendered. If either of those rules were followed, a perfect
solution would be possible.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDDBdt6ZGQ8LKA8nwRApTVAJ9MRLi7d9OVqIXIFhEVUMTUgvq+cACgsR2y
kE7LAA6Fu+V13Aa0KXyI9DE=
=6pBX
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

(yes, I stole your applet for testing...
hope you don't mind):

LOL! You are welcome. Please get back to us once you have
got it as good as you feel it can be*, it might be worth
adding to the list of test cases.

* %100 working, or not.

 

[Chris Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

LOL! You are welcome. Please get back to us once you have
got it as good as you feel it can be*, it might be worth
adding to the list of test cases.

* %100 working, or not.

BLAH! I did it! It's a painful hack which I am not proud of, BUT:

1. The applet displays in Firefox 1.0.6 and IE 6.
2. There are no broken object icons in either browser.
3. It's valid HTML 4.01 Transitional.

This relies on IE having buggy CSS support (specifically not supporting
the > selector).

- --- CUT HERE ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Foo</title>
<style type="text/css">
..notieapplet {
display: none;
}
..appletcontainer > .notieapplet {
display: inline;
}
</style>
</head>
<body>
<div class="appletcontainer">
<object type="application/x-java-applet" data="LabelApplet.class"
width="80" height="30" class="notieapplet">
<param name="code" value="LabelApplet.class">
<param name="message" value="Foo!">
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
type="application/x-java-applet" data="LabelApplet.class" width="80"
height="30">
<param name="code" value="LabelApplet.class">
<param name="message" value="Foo!">
</object>
</object>
</div>
</body>
</html>
- --- CUT HERE ---

Feel free to put this code on your test page. Obviously, in production
code, it may be desired to move the stylesheet rules into an external file.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDDQqP6ZGQ8LKA8nwRAhRiAJ9aG8dapAmppXg6d9PA+9uknD+s4ACeISmG
M+iY5/QVkgOAETw9n9jFmRc=
=nPZ3
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

..This relies on IE having buggy CSS support (specifically not supporting
the > selector).

Huh! Browser import hacks to support web page functionality!

You are truly a denizon of the art, Chris.
I will have to look into your solution..

Do I have your permission to include it in the
'appletcall' page?

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
"I don't wanna' be like other people are. Don't wanna' own a key, don't
wanna' wash my car.."
New Order 'Turn My Way'

 

[Andrew Thompson]

Do I have your permission to include it in the
'appletcall' page?

(Chris earlier)
(slaps self) I should have read you earlier post all the
way to the bottom before I asked.

 

[Dag Sunde]

BLAH! I did it! It's a painful hack which I am not proud of, BUT:

1. The applet displays in Firefox 1.0.6 and IE 6.
2. There are no broken object icons in either browser.
3. It's valid HTML 4.01 Transitional.

This relies on IE having buggy CSS support (specifically not supporting
the > selector).

<snipped/>

This is Fantastic, Chris!
With the modifications below, I am able to script my applet in the
different browsers too (Opera 8.0, Netscape 7.2, FF 1.0.6 and IE 6)...

The "if (window.XMLHttpRequest) {..." is just a dirty hack to diff
IE from the others...

<style type="text/css">
.notieapplet {
display: none;
}
.appletcontainer > .notieapplet {
display: inline;
}
</style>

<script type="text/javascript">

function setName( name ) {
var myApplet;

// IE does NOT have 'window.XMLHttpRequest'
if (window.XMLHttpRequest) {
myApplet = document.getElementById("helloFF");
} else {
myApplet = document.getElementById("helloIE");
}

myApplet.setName(name);

return true;
}

</script>
</head>

<body>
<div class="appletcontainer">
<object
id="helloFF"
type="application/x-java-applet"
data="no.orion.hello.HelloApplet.class"
width="150"
height="75"
class="notieapplet">
<param name="code" value="no.orion.hello.HelloApplet.class">
<param name="greetName" value="there">
<param name = "mayscript" value ="true"/>
<param name = "scriptable" value = "true">

<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
id="helloIE"
type="application/x-java-applet"
data="no.orion.hello.HelloApplet.class"
width="150"
height="75">
<param name="code" value="no.orion.hello.HelloApplet.class">
<param name="greetName" value="there">
<param name = "mayscript" value ="true"/>
<param name = "scriptable" value = "true">
</object>
</object>
</div>
<br />
<input type="button" value="Change Name" onclick="setName('Dag');" />
</body>

 

[Andrew Thompson]

BLAH! I did it! It's a painful hack which I am not proud of,

LOL! You would not believe the things I have done in
attempts to get this stuff to work. It makes me feel
...dirty.

...BUT:

1. The applet displays in Firefox 1.0.6 and IE 6.

(crashes NN 4.8 - I am beyond caring)

2. There are no broken object icons in either browser.
3. It's valid HTML 4.01 Transitional.

It validates as strict, actually.

This relies on IE having buggy CSS support (specifically not supporting
the > selector).

Brilliant! I tip my hat to you..

Feel free to put this code on your test page.

You can see it here..

Obviously, in production code, it may be desired
to move the stylesheet rules into an external file.

Batteries not included, huh? I want my money back! [ ;-) ]

Or, to put that another (less funny) way. Done.

 

[Andrew Thompson]

With the modifications below, I am able to script my applet in the
different browsers too (Opera 8.0, Netscape 7.2, FF 1.0.6 and IE 6)...

Took me a while to get what you meant, but yes.. that is a
nice refinement. I will probably add it as '# 8' if that is
OK with you Dag?

 

[Dag Sunde]

Took me a while to get what you meant, but yes.. that is a
nice refinement. I will probably add it as '# 8' if that is
OK with you Dag?

Of course you can add it...

Sorry for the confusion... I made my own JApplet with a public method
explicitly to test cross-browser scripting of the applet.

I've been struggling with the object/embed combination for years now,
and can finally get rid of it. If this can save anybody else from the
hassle, I'm glad...

Do you have a "better" solution for me than using the
"window.XMLHttpRequest" to check which id to use in the script?

TIA...

 

[Andrew Thompson]

On Thu, 25 Aug 2005 11:16:35 GMT, Dag Sunde wrote:

...

Of course you can add it...

Cool. Thanks.

Sorry for the confusion... I made my own JApplet with a public method
explicitly to test cross-browser scripting of the applet.

I had not looked closely at the actual code, it just
took me a few moments to understand why you were bothering,
then it clicked.. the duplicate ID'd would mess up scripting.

I've been struggling with the object/embed combination for years now,
and can finally get rid of it. If this can save anybody else from the
hassle, I'm glad...

I think this generally is a good solution.

It crashes NN 4.8. We might need to redirect old NN
to a pure <APPLET>* page if supporting it is necessary.

* An applet needs to be 1.1 compatible to work in NN
anyway (it runs Symantec's Java 1.1.5). So you might
as well use the <APPLET> element in (valid) HTML 3.2
for it and be done with it.

The attempt to use scripting in IE to correct the ID's
might fail if scripting in IE is disabled. But then..
- If that fails, so would 'scripting' an applet -
so there is no 'loss' of funtionality.
- 'the guy' who uses..
- IE with
- Java enabled, but
- JS disabled,
..is hardly your average end user.

Do you have a "better" solution for me than using the
"window.XMLHttpRequest" to check which id to use in the script?

I have not looked at it closely yet ..possibly.
It might be better to iterate the existing ID's(?)..
I'll report back here if I come up with anything,
or with an URL to your version as is, in any case.

 

[Dag Sunde]

On Thu, 25 Aug 2005 11:16:35 GMT, Dag Sunde wrote:

..

Cool. Thanks.


I had not looked closely at the actual code, it just
took me a few moments to understand why you were bothering,
then it clicked.. the duplicate ID'd would mess up scripting.


I think this generally is a good solution.

It crashes NN 4.8. We might need to redirect old NN
to a pure <APPLET>* page if supporting it is necessary.

* An applet needs to be 1.1 compatible to work in NN
anyway (it runs Symantec's Java 1.1.5). So you might
as well use the <APPLET> element in (valid) HTML 3.2
for it and be done with it.

The attempt to use scripting in IE to correct the ID's
might fail if scripting in IE is disabled. But then..
- If that fails, so would 'scripting' an applet -
so there is no 'loss' of funtionality.
- 'the guy' who uses..
- IE with
- Java enabled, but
- JS disabled,
..is hardly your average end user.

I use this in two "Web-apps" written for a client that has
his potential users "by the balls", and he can pretty much
dictate the UA requirements of his users.

So my scenario is that I *know* my users will, as a minimum
have:
* Transient cookies ON
* Minimum Sun JRE Plugin v 1.4.2_06
* Scripting Enabled
* IE 6.0 || Opera 8.0 || NN 7.2 || FF 1.0.6

(I know, I'm lucky!)
;-)

 

[Chris Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dag Sunde wrote:
[snip]

Do you have a "better" solution for me than using the
"window.XMLHttpRequest" to check which id to use in the script?

TIA...

What if you were to use DOM to find some element of the "notieapplet"
class and then access its properties to determine whether its CSS
display property was set to "none" or "inline" (basically instead of
exploiting a SECOND IE bug which might be fixed at a different time,
you're now just exploiting the side-effects of the bug which is already
being exploited).

I don't like exploiting bugs, so it seems like it's always good if you
can use just one bug to control lots of things that need controlling thus.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDDolB6ZGQ8LKA8nwRAtymAKCJTkT/IJDFUEUSzX3GiodCSesnQwCgxJCm
aoZPTTCBW1/3yBFqK74vEH8=
=jolN
-----END PGP SIGNATURE-----

 

[Dag Sunde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dag Sunde wrote:
[snip]

Do you have a "better" solution for me than using the
"window.XMLHttpRequest" to check which id to use in the script?

TIA...

What if you were to use DOM to find some element of the "notieapplet"
class and then access its properties to determine whether its CSS
display property was set to "none" or "inline" (basically instead of
exploiting a SECOND IE bug which might be fixed at a different time,
you're now just exploiting the side-effects of the bug which is already
being exploited).

Thats what I tried to do first, but I messed up somewhere, and couldn't
get it to work so I just jumped onto something that did there and then.

But now that you suggest the same as my first idea, I will go back and
do it that way. (Two people intuitively getting the same idea can't be bad)

I don't like exploiting bugs, so it seems like it's always good if you
can use just one bug to control lots of things that need controlling thus.

Neider do I, but with CSS it is sometimes neccessary...

Thanks for your input...