Should I use <applet...> or <object...> tag?

C

Chris Berg

Should I use <applet...> or <object...> tag? I always use <applet...>
today, but for some reason that I don't quite understand it is
deprecated by w3c. I guess they want to put all code-like content
(applets, flash, activex etc) into the same framework. I wish to be a
well-behaved boy, so I am considering using <object...> instead.

Looking at the options and output of Sun's HtmlConverter.exe, I wonder
if converted HTML has a lesser chance of running on non-windows/ie
type browsers? For example, the <object..> tag includes

codebase="http://java.sun.com/update/1.5.0/jinstall-1_5-windows-i586.cab#Version=5,0,0,7"

which appears to be a windows installer file (by the way, the link
doesn't work - why can that be?)

My conclusion is that <object...> is a much more platform-specific tag
than <applet...>, some kind of server- or client-side script appears
to be necessary to give the user the right version, whereas <applet..>
seems to run almost anywhere. If there is a VM version issue, I can
address that after the applet has loaded, and issue to the user a
detailed dialog explaining why she should update the VM or whatever.

Chris
 
A

Andrew Thompson

My conclusion is that <object...> is a much more platform-specific tag
than <applet...>, some kind of server- or client-side script appears
to be necessary to give the user the right version, whereas <applet..>
seems to run almost anywhere.

Once you start to use the OBJECT element for versioning,
Mozilla family browsers will ignore it.

Check this thread, (especially the sub-thread started by Chris Head)
<http://groups.google.com.au/group/c..._frm/thread/10c5b264bb1193c9/cd41d58faa86d8f0>
...for further details.

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
"Don't just take me for tryin' to be heavy. Understand, it's time to get
ready.."
Stevie Ray Vaughan and Double Trouble 'Couldn't Stand The Weather'
 
R

Roedy Green

Should I use <applet...> or <object...> tag? I always use <applet...>
today, but for some reason that I don't quite understand it is
deprecated by w3c. I guess they want to put all code-like content
(applets, flash, activex etc) into the same framework. I wish to be a
well-behaved boy, so I am considering using <object...> instead.

the advantage of <applet is you can read and proofread the code. It
supported by everything.

OBJECT and EMBED are new creations ugly as a pimply ass, requiring
many variants to work in different browsers.

They have but one advantage. They can arrange to download and install
Java if it is missing.
 
C

Chris Berg

They have but one advantage. They can arrange to download and install
Java if it is missing.

... which I can also do 'by hand', using a combination of text before
the final </applet> tag, and version-detecting code inside the applet.
I feel that I have much better control that way.

So I'll be a bad boy and stick to <applet> - I guess chances are very
small that <applet> will ever be taken out of service, so why bother?
 
A

Andrew Thompson

.. which I can also do 'by hand', using a combination of text before
the final </applet> tag, and version-detecting code inside the applet.

How?* Got an URL?

* I have a combination of alt HTML and use the JavaVersioningApplet
to ensure a minimum Java is installed, but if minimum Java is missing,
all the JVA can do is redirect to another page, which does not achieve
as much as the nested <OBJECT>/<EMBED> structure.

Have you achieved more in your altenrate HTML, and how is it invoked
if the browser has a Java version lower than what is required?
 
R

Roedy Green

How?* Got an URL?

package com.mindprod.common11;

import java.awt.Color;
import java.awt.Container;
import java.awt.TextArea;

/**
* VersionCheck.java Check that Java version is sufficiently recent
copyright
* (c) 1997-2005 Roedy Green, Canadian Mind Products #327 - 964
Heywood Avenue
* Victoria, BC Canada V8V 2Y5 mailto:[email protected]
http://mindprod.com
*
* @version 1.5 2005-07-14 split off from Misc, allow for compilation
with old
* compiler. version 1.4 2002 August 17, add quoteSQL version
1.3 1999
* August 24, add leftPad, rightPad, smarter rep.
isJavaVersionOK now
* handles 1.3beta. version 1.2 1998 December 14, add
isJavaVersionOK
* version 1.1 1998 November 10, add dates version 1.0 1997
March 23,
* initial.
*/

public class VersionCheck {

/**
* true if you want extra debugging output and test code
*/
static final boolean DEBUGGING = false;

/**
* VersionCheck contains only static methods.
*/
private VersionCheck()
{

}

/**
* Ensures Java runtime version e.g. 1.1.7 is sufficiently recent.
Based on
* code by Dr. Tony Dahlman <[email protected]>
*
* @param wantedMajor
* java major version e.g. 1
* @param wantedMinor
* Java minor version e.g. 1
* @param wantedBugFix
* Java bugfix version e.g. 7
* @return true if JVM version running is equal to or more recent
than
* (higher than) the level specified.
*/
public static boolean isJavaVersionOK ( int wantedMajor, int
wantedMinor,
int wantedBugFix )
{

try
{
try
{
// java.version will have form 1.1.7A, 11, 1.1., 1.1,
1.3beta,
// 1.4.2_05 or 1.4.1-rc
// It may be gibberish. It may be undefined.
// We have do deal with all this malformed garbage.
// Because incompetents run the world,
// it is not nicely formatted for us in three fields.
String ver = System.getProperty( "java.version" );

if ( ver == null ) { return false; }

ver = ver.trim();

if ( ver.length() < 2 ) { return false; }

int dex = ver.indexOf( '.' );

if ( dex < 0 )
{
// provide missing dot
ver = ver.charAt( 0 ) + '.' + ver.substring( 1 );
dex = 1;
}

int gotMajor = Integer.parseInt( ver.substring( 0, dex
) );
if ( DEBUGGING )
{
System.out.println( "major:" + gotMajor );
}
if ( gotMajor < wantedMajor ) return false;
if ( gotMajor > wantedMajor ) return true;

// chop off major and first dot.
ver = ver.substring( dex + 1 );

// chop trailing "beta"
if ( ver.endsWith( "beta" ) )
{
ver = ver.substring( 0, ver.length() -
"beta".length() );
}
// chop trailing "-rc"
if ( ver.endsWith( "-rc" ) )
{
ver = ver.substring( 0, ver.length() -
"-rc".length() );
}
// chop any trailing _nn
dex = ver.lastIndexOf( '_' );
if ( dex >= 0 )
{
ver = ver.substring( 0, dex );
}
// chop any trailing letter as in 1.1.7A,
// but convert 1.1.x or 1.1.X to 1.1.9
char ch = ver.charAt( ver.length() - 1 );
if ( !Character.isDigit( ch ) )
{
ver = ver.substring( 0, ver.length() - 1 );
if ( ch == 'x' || ch == 'X' ) ver += '9';
}
// check minor version
dex = ver.indexOf( '.' );
if ( dex < 0 )
{
// provide missing BugFix number as in 1.2 or 1.0
ver += ".0";
dex = ver.indexOf( '.' );
}

int gotMinor = Integer.parseInt( ver.substring( 0, dex
) );
if ( DEBUGGING )
{
System.out.println( "minor:" + gotMinor );
}
if ( gotMinor < wantedMinor ) return false;
if ( gotMinor > wantedMinor ) return true;
// was equal, need to examine third field.
// check bugfix version
ver = ver.substring( dex + 1 );
int gotBugFix = Integer.parseInt( ver );
if ( DEBUGGING )
{
System.out.println( "bugFix:" + gotBugFix );
}
return ( gotBugFix >= wantedBugFix );

}
catch ( NumberFormatException e )
{
if ( DEBUGGING )
{
System.out.println( "number format" +
e.getMessage() );
}
return false;
} // end catch

}
catch ( StringIndexOutOfBoundsException e )
{
if ( DEBUGGING )
{
System.out.println( "out of bounds:" + e.getMessage()
);
}

return false;
} // end catch

} // end isJavaVersionOK

/**
* use in a paint routine if Java version is not ok, usually
tested
* statically.
*
* @param wantedMajor
* java major version e.g. 1
* @param wantedMinor
* Java minor version e.g. 1
* @param wantedBugFix
* Java bugfix version e.g. 7
* @param container
* container to add an error message component.
* @return true if version is ok
*/
public static boolean isJavaVersionOK ( int wantedMajor, int
wantedMinor,
int wantedBugFix, Container container )
{

if ( isJavaVersionOK( wantedMajor, wantedMinor, wantedBugFix )
)
{
return true;
}
else
{
String error = "Error: You need Java "
+ wantedMajor
+ "."
+ wantedMinor
+ "."
+ wantedBugFix
+ " or later to run this Applet.\n"
+ "You are currently running under Java "
+ System.getProperty( "java.version" )
+ ".\n"
+ "Get the latest Java from
http://java.com/en/index.jsp";
TextArea complain = new TextArea( error, 3, 42,
TextArea.SCROLLBARS_NONE );

complain.setEditable( false );
complain.setBackground( Color.white );
complain.setForeground( Color.red );
complain.setSize( 300, 50 );
container.setLayout( null );
container.add( complain );
System.err.println( error );
return false;
}
}

} // end class VersionCheck
 
A

Andrew Thompson

....
/**
* VersionCheck.java Check that Java version is sufficiently recent

Yes, but you miss the point. I have the JavaVersionApplet that
can do versioning, but that means the applet must load before
it does it's work. Obviously any 'alt' attribute in the <applet>
element, as well as any 'alternate HTML' between the params/close
tag will be ignored.

Once the applet has loaded, the 'alt/alternate HTML' parts
of the applet element are useless.

If the user does not have the required minimum Java, you then
have a limited number of options,
- inform the user via text area as your code does.
- redirect the applet to a new page (quite unreliable
in this day and age)
...neither of which will directly prompt the end user to
install the necessary Java, as the nested OBJECT/EMBED
element can.

While the nested elements have their downside, the ability
to perform Java versioning is a strong point in their favor.

The applet element cannot achieve that, and the alternatives
designed to assist the applet element are merely an attempt
to keep the user informed.

Of course, if all you intend to do is 'keep the user informed'
as opposed to 'prompt the user to install the necessary Java',
the applet element, combined with a version checker like
VersionCheck.java or the JavaVersionApplet, can do just fine.
 
D

Dag Sunde

Andrew Thompson said:
Yes, but you miss the point. I have the JavaVersionApplet that
can do versioning, but that means the applet must load before
it does it's work. Obviously any 'alt' attribute in the <applet>
element, as well as any 'alternate HTML' between the params/close
tag will be ignored.

Once the applet has loaded, the 'alt/alternate HTML' parts
of the applet element are useless.

If the user does not have the required minimum Java, you then
have a limited number of options,
- inform the user via text area as your code does.
- redirect the applet to a new page (quite unreliable
in this day and age)
..neither of which will directly prompt the end user to
install the necessary Java, as the nested OBJECT/EMBED
element can.

While the nested elements have their downside, the ability
to perform Java versioning is a strong point in their favor.
<snipped/>

Didn't Chris Head come up with a very good solution using two
nested OBJECT elements instead?

After reading that trick of his, I'm using that for versioning/
DL-prompting for all (major) browsers, and avoiding the EMBED
alltogether...

The thread was named: "launch applet with APPLET or PLUGIN"
 
C

Chris Head

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

Dag Sunde wrote:
[snip]
Didn't Chris Head come up with a very good solution using two
nested OBJECT elements instead?

After reading that trick of his, I'm using that for versioning/
DL-prompting for all (major) browsers, and avoiding the EMBED
alltogether...

The thread was named: "launch applet with APPLET or PLUGIN"


Hi,
I sure did. The juicy details are all on Andrew Thompson's page, which
shows his many experiments into this field plus my hackish solution
involving nested OBJECT elements plus some CSS.

http://www.physci.org/test/appletcall/

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

iD8DBQFDJlt46ZGQ8LKA8nwRAhA9AJ9U2VhqtzOVrSc58eQ4ijkZ1StdUgCeMpFC
SAzqpbwwtEQl1GEgnd++lUg=
=2EWf
-----END PGP SIGNATURE-----
 
C

Chris Berg

How?* Got an URL?
In the first line of the applet's init(), I check for the Java version
with System.getProperty("java.version"). If it is too low, I pop-up a
Dialog telling the user to go to http://www.java.com and update the
VM, and then I stop initializing the applet.

It can be made more or less informative, with a Button labelled "Go to
www.java.com", and a label on top of the applet saying "Update VM and
re-load" etc. etc.

I've had no complaints from users over this, in fact, I find that
users generally (even 'dumb' ones) like to be 1) told exactly what is
going on, 2) manually change/update their PC, and 3) be told what to
do next.
 
R

Raymond DeCampo

Chris said:
In the first line of the applet's init(), I check for the Java version
with System.getProperty("java.version"). If it is too low, I pop-up a
Dialog telling the user to go to http://www.java.com and update the
VM, and then I stop initializing the applet.

It can be made more or less informative, with a Button labelled "Go to
www.java.com", and a label on top of the applet saying "Update VM and
re-load" etc. etc.

I've had no complaints from users over this, in fact, I find that
users generally (even 'dumb' ones) like to be 1) told exactly what is
going on, 2) manually change/update their PC, and 3) be told what to
do next.

This is not equivalent functionality to the code generated by
HTMLConverter / <jsp:plugin> which will a) prompt the user to install
Java even if it is missing, b) invoke the installer automatically. This
means the user just has to keep clicking "OK" until their machine is up
to date.

Ray
 
C

Chris Berg

Java even if it is missing, b) invoke the installer automatically. This
means the user just has to keep clicking "OK" until their machine is up
to date.

Ray

Exactly, that is my point: I am not dependent on how the <object..> /
<embed..> tags are interpreted on the specific platform, nor am I
relying on the user having enabled scripting.

Device/platform-independence has always been a main goal for Java;
<object..> appears to be absolutely NOT that.

And, if the user doesn't have Java, he gets the text that's embedded
before the final </applet> tag, which will contain a direct link to
Sun's page.

I am convinced users would rather click 'OK' once too often than have
things installed behind their back without knowing what's going on.
Especially with all the malicious auto-dialer and spyware plugins that
many sites try to impose on them these days.

Chris
 
R

Raymond DeCampo

Chris said:
Exactly, that is my point: I am not dependent on how the <object..> /
<embed..> tags are interpreted on the specific platform, nor am I
relying on the user having enabled scripting.

Device/platform-independence has always been a main goal for Java;
<object..> appears to be absolutely NOT that.

<OBJECT>, <EMBED> and <APPLET> are not Java, they are HTML. There are
browsers that do not support any of these tags. True platform
independence across web browsers is very difficult to obtain.
And, if the user doesn't have Java, he gets the text that's embedded
before the final </applet> tag, which will contain a direct link to
Sun's page.

I am convinced users would rather click 'OK' once too often than have
things installed behind their back without knowing what's going on.
Especially with all the malicious auto-dialer and spyware plugins that
many sites try to impose on them these days.

Nothing happens behind the user's back in this technique. The user is
prompted to install the plug-in. That is why they have to click OK.

Note that I wasn't criticizing your solution, I was merely pointing out
that it is not equivalent to the HtmlConverter / <jsp:plugin> technique
and does not "download and install Java if it is missing." (The quote
here is from Roedy Green's post.)

Let me refresh your memory:

Roedy Green> OBJECT and EMBED are new creations ugly as a pimply ass,
Roedy Green> requiring many variants to work in different browsers.
Roedy Green>
Roedy Green> They have but one advantage. They can arrange to download
Roedy Green> and install Java if it is missing.

Chris Berg> which I can also do 'by hand', using a combination of text
Chris Berg> before the final </applet> tag, and version-detecting code
Chris Berg> inside the applet. I feel that I have much better control
Chris Berg> that way.

Andrew Thompson> How?* Got an URL?

To which you described your solution where the user must manually
install the Java plug-in if it is missing and that is the difference.

Ray
 
R

Roedy Green

Exactly, that is my point: I am not dependent on how the <object..> /
<embed..> tags are interpreted on the specific platform, nor am I
relying on the user having enabled scripting.

But object and embed are so disgusting surely even JavaScript is the
lesser of three evils. Can you detect if Java of the right version is
installed and if not direct them to a page that explains in English
what the problem is and how to fix it?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,607
Members
45,240
Latest member
pashute

Latest Threads

Top