Thankfully there are some good discussions and solutions by Drew McLellan and Florian Jenett. However, there are also a lot of people (including me) still having problems embedding applets in CMS pages from WordPress and Drupal, among others. Based on Drew and Florian’s articles, and with a fair bit of trial and error, you should now be seeing a large red interactive graph immediately below. If you can’t see this graph, then my solution is obviously completely wrong so you can save yourself some time by not reading any further…
Example Applet: This is an example of an embedded java applet.
When I started, I had concerns about depending on
I therefore decided to use server-side PHP for browser detection and serving pages with only the embedding code appropriate to the requesting browser. This seemed to be working absolutely fine most of the way through the development process, working mainly on a Mac and switching to my Windows machine for testing. However, I began to notice that, just occasionally, the applet wouldn’t load properly. Of course, even though I had site-wide caching disabled, it turns out that Drupal 6 still caches filtered content pretty aggressively and I had implemented my code as a filter module (most of my previous experience was with Drupal 4.7 and this was my first project with Drupal 6 in which this is a new feature).
Thus, the content being served to all subsequent browsers was the content generated for the very first bowser that had accessed it after a modification or cleared cache. Of course most of the time I’d be making changes and checking them in the same browser that prompted the change in the first place. On the occasions it didn’t load, I’d assume it was a local cache issue and just clear the cache.
Thus, for static web pages, the server-side PHP approach would work fine. Within a CMS server it’s a fight not worth having. Thus, I removed the browser detection switch and embedded the appropriate
<!--[if !IE]> <![endif]--> conditional comments in the PHP output. The benefit is that the page content is always the same so is perfectly happy being cached.
Embedding an Applet
Based on templates created by Florian Jenett, the following is an xhtml1-strict standards compliant format for embedding a Java applet within all browsers except Microsoft Internet Explorer.
The following is the xhtml1-strict standards compliant format for embedding a Java applet within Microsoft Internet Explorer.
Whilst most of it is the same, there are some important differences - the main ones being different attribute values. You can see that
classid has two completely different values,
codebase is added and
archive removed. The value of the
test_string param is different and IE requires an additional
code parameter. Also, with IE it is possible to embed some HTML within the
<object> </object> tags that is only displayed if the embedding fails.
Using Conditional Comments
In order to generate HTML that will work in both IE and all other browsers, it is possible to embed one
<object> inside the pass-through code of another. Thus, if the first one works, you never see the second. As IE handles conditional comments and most other browser’s ignore them, you can make the outer object appropriate for non-IE browsers and wrap that in a conditional comment so that IE will ignore it. Then, place the IE-specific code inside the outer object - as shown below:
OpenGL for 3D Content
In order to embed a java applet that uses the JOGL OpengGL wrapper, you must actually run the JOGLAppletLauncher applet instead and pass the name and class of the actual applet you want as sub-applet parameters.
The following is an xhtml1-strict standards compliant format for embedding a JOGL Java applets using conditional comments.
The rest of this post refers to CMS and server technology no longer used on this site.
Automatically Generating the Required Code
The above code is pretty laborious to type every time you need to embed an applet, and there is a lot of scope for error or omission in manual copy/paste operations. Thus, I opted to add a custom tag that I could add to the text of a document that could be parsed and converted to the format most appropriate to the requesting browser.
To embed custom data in a served page, I use my own
[tag] construct using square brackets as these tend not to be used in standard writing and are database-friendly (which is exactly why WIKI text uses them). Also, rather than doing lots of different tests for many kinds of tag, I use a very simple yet flexible nomenclature of the form:
This means that I can also use a fairly standard regular expression in PHP to parse and process all occurrences of
[tag=XXX]Some HTML[/tag] pairs within any document text.
The callback function used above is detailed below. It gets passed two arguments: all the parameter text between the
[tag= and the first ] brace; and then all the content text between the enclosing
[ braces. The key here is the use of the PHP parse_str() function which parses all the parameter text into an associative array of any ‘param=value’ pairs. This means that the text in the first argument needs to be formatted in exactly the same way as parameters in a HTTP GET command.
Once we have the parameter array, the function that does the real work processes them into a formatted HTML <object> tag.
'; $output .= "
You can find more details about using conditional comments within the Browser Detection Methods page.
huyz 1 July, 2011 - 18:50
For WordPress, you can install the plugin that I just created for embedding Java applets using a shortcode. No coding required.
Click here to comment on this page.