Depth-First: Tag objecttag

Building WebSpex: Putting Custom Data Types In Their Place

Rich Apodaca — Thu, 24 Jul 2008 16:40:00 +0000

The previous article in this series introduced WebSpex, a spectroscopic data visualization tool being designed especially for use in a Web browser. Previously, the platform on which the user interface would be built was discussed. This article will discuss the question of where to put the spectroscopy data that WebSpex will display.

Tag Soup

We've decided to target WebSpex for use on the Web, which means that spectroscopy data would need to be referenced or embedded in a Web page. How should we do this? The answer, it turns out, is far from obvious.

If we knew that WebSpex were going to be created as a Java or Flash applet, which is not the current plan, we might be tempted to pass a reference to the data (or the data itself) as a parameter in the <object> tag. For an applet, this might look something like:

<object type="application/x-java-applet;version=1.4.2" width="520" height="350">
  <param name="code" value="com/metamolecular/webspex/applet/FullApplet.class">
  <param name="archive" value="http://metamolecular.com/applets/webspex.jar">
  <param name="jcamp" value="http://base-url/spectrum.jdx">
</object>

In the example above, the parameter jcamp would encode the path to a JCAMP-DX file for WebSpex to load.

Alternatively, if we were going to develop WebSpex as a Flash applet, we might use an object tag like this:

<object type="application/x-shockwave-flash" width="520" height="350">
  <param name="movie" value="webspex.swf">
  <param name="FlashVars" value="filename=http://spectrum.jdx">
</object>

In this example, we associate the parameter filename with the value "spectrum.dx" using FlashVars.

This works well enough, but what if we need to load a custom data type in a Web page without a plugin?

Some Options

There are a few options for including custom data in an HTML document:

Invent our Own Tag Browsers are designed to ignore content they don't understand. We could just hack our own tag, let's call it <spectrum>. But for a variety of reasons, this is a bad idea. Most importantly, we'd be breaking with conventions used worldwide, which is never a good idea without a very good reason. For another, any developer tools we'd use would probably complain about a mis-formed HTML document. Still another reason might be that browsers could parse our invented tag in unpredictable ways. We may also run into problems with search engines not indexing our content properly.
Use XHML We could try inventing a tag the right way: with XHTML. This might be a worthwhile option if our data type (JCAMP-DX) were XML-based, but it's not. At best we'd expend a lot of effort learning about namespaces, schema, and HTTP response headers only to end up with an amorphous flat <spectrum> tag containing freeform text.
Use JSON We could encode our JCAMP-DX files as JSON. JSON is a markup language like XML, but with the difference that it can be evaled directly by the JavaScript interpreter. This has the advantage that either a filename, or the actual data could be encoded. We could, in fact, create the entire object model for our spectrum, ready to be displayed, if we had software that could make the conversion from JCAMP-DX to JSON. This approach has the disadvantage that it could require significant amounts JavaScript code to be mixed in with our HTML, a less than ideal solution.
Use the Object Tag Given that none of the three options above are especially appealing, we might ask ourselves whether we've really tried everything possible to use plain old HTML to encode our data. More specifically, what if we were to use the object tag itself, without actually having a plugin?

Encoding Custom Data Types With The Object Tag

The HTML 4 specification has this to say about the object tag:

Most user agents have built-in mechanisms for rendering common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To render data types they don't support natively, user agents generally run external applications. The OBJECT element allows authors to control whether data should be rendered externally or by some program, specified by the author, that renders the data within the user agent.

In the most general case, an author may need to specify three types of information:

The implementation of the included object. For instance, if the included object is a clock applet, the author must indicate the location of the applet's executable code.

The data to be rendered. For instance, if the included object is a program that renders font data, the author must indicate the location of that data.

Additional values required by the object at run-time. For example, some applets may require initial values for parameters.

The OBJECT element allows authors to specify all three types of data, but authors may not have to specify all three at once. For example, some objects may not require data (e.g., a self-contained applet that performs a small animation). Others may not require run-time initialization. Still others may not require additional implementation information, i.e., the user agent itself may already know how to render that type of data (e.g., GIF images).

In other words, we could place a reference to a spectrum object in an HTML page with code like this:

<object width="520" height="350">
  <param name="data" value="http://base-url/spectrum.jdx">
</object>

After loading the document, we could have WebSpex walk the DOM looking for object tags that could be replaced with an instance of WebSpex. That instance could actually be placed inside the original object tag like this:

<object width="520" height="350">
  <param name="data" value="http://base-url/spectrum.jdx">
  <div class="webspex">
    <!-- WebSpex visual presentation -->
  </div>
</object>

The HTML 4 documentation states that any content contained within object tags not recognized by the user agent will be rendered (fallback content). So dynamically inserting the div into the object tag as shown above would have the effect of giving the browser something to display in place of the object tag.

Advantages of Using This Approach

This approach has several advantages worth mentioning:

It's fully compliant with the HTML 4 specification.
It provides a natural anchor point to attach both the custom data and the visual presentation of that data.
It's pure HTML, requiring minimal mixing in of JavaScript content.
Web spiders can be taught a single method to associate a spectrum with a URL, regardless of how the viewer is implemented.
It's technology-agnostic. This approach lets us implement WebSpex as a Java or Flash applet (or some other plugin technology) just as easily as a pure JavaScript UI. To change our viewer implementation, we just change a JavaScript file.
It allows spectra to be inlined, or place directly into the HTML. Using a Data URI, we could replace "http://base-url/spectrum.jdx" with something like "data:chemical/x-jcamp-dx;base64,iVBORw0KGgoAA...". This would be important in those situations in which a public URL to a JCAMP file was not feasible and/or desirable. It could also accelerate the rendering of multiple spectra in the same page by eliminating the need to create a separate HTTP request for each file.

The method carries an imporant limitation: if a user has disabled JavaScript, they may see nothing to indicate a problem. We could address this issue by always placing fallback content in the object tag that would then be overwritten by the JavaScript code.

Implementation Detail

This approach relies on Onobtrusive JavaScript techniques to keep JavaScript as separate from HTML as possible. One way to implement such a scheme would be to include a single reference to the relevant JavaScript somewhere in the document, probably withing the <head> tag or right after the opening <body> tag:

  <script type="text/javascript" src="webspex.js"></script>

The file webspex.js would then execute code to place a function into the document's onLoad queue that would scan for object tags containing JCAMP-DX content and insert the needed viewer.

Previous Uses

I'm unaware of any previous applications of this technique, although is seems like something that may have been used before.

Conclusions

Encoding and displaying custom data types in HTML is possible by using the HTML 4 object tag coupled with client-side JavaScript to rewrite the DOM. It offers the potential to create HTML documents that are both human- and machine-readable. Although the approach described here was developed for the special case of spectroscopy data, it could in principle be used for any data type requiring a visual presentation.

Image Credit: mdezemery

Demystifying Java Applets, Part 1: Cross-Browser, Standards-Compliant, Pure HTML Deployment Using the Object Tag

Rich Apodaca — Wed, 20 Feb 2008 09:41:00 +0000

A 2006 survey on java.net posed a simple question to developers: What's wrong with applets? By a significant margin, the number one complaint was that they are "too hard to deploy." This article, the first in a series, takes a look at the issue of Java applet deployment and in particular how using the <object> tag can radically simplify and enhance both the developer and end user experience.

Applets? You Must Be Joking!

Applets got a well-deserved bad reputation in the early days of Java. They were slow, difficult to deploy across browsers, and over-hyped. The situation has signficantly changed for the better, but the bad reputation lingers.

There are many situations in which applets are inappropriate. The most important of these is when simple interactivity can be achieved through HTML or JavaScript (Ajax).

But in many situations, HTML and JavaScript make a poor platform choice. As a specific example, consider Web-based chemical structure editors. The high level of graphical manipulation, sophistication of data processing, and responsiveness required by these components, coupled by their ubiquity, means that it will be a long time indeed before Ajax (or Flash for that matter) is up to the challenge - and they may never be, given their design constraints.

For a large number of specialized Web components, applets are the only platform.

Regarding the "uncool factor", it's worth pointing out that not more than four years ago JavaScript was one of the most loathed, ridiculed, and ignored technologies around. Now it finally works - meaning it's reliable enough to be used on all modern browsers. The result is Ajax and a host of interactive Web technologies that played a major role in redefining what the Web was all about.

Whether a similar renaissance happens for applets is anybody's guess, but most of the prerequisites have already been met.

Deployment with the `<applet>` Tag

If you decide to develop Web applications with applets, a major consideration will eventually become how to deploy them. Unfortunately, a bewildering array of often contradictory advice is available on the subject - most of it outdated.

Many sources recommend using the <applet> tag. It's the oldest method, and will generally work on most browsers. For example, to deploy my company's structure editor applet ChemWriter, the following code could be used:

<applet code="com/metamolecular/chemwriter/applet/EditorApplet.class"
        archive="/path/to/applets/chemwriter.jar"
        width="600" height="300">
  <param name="persistState" value="false" />
</applet>

Unfortunately, the <applet> tag has some very important strikes against it. The first is that its use is now deprecated in HTML. In other words, whatever support browsers now have for it is living on borrowed time.

The second problem with the <applet> tag is an insidious bug in Internet Explorer (as if there were any other kind). Most hardware suppliers pre-install Java onto their Microsoft-based machines, which is a good thing. The bad thing is that at least one major manufacturer disables the Java console in IE 7 at the same time. Under IE 7, disabling the Java console renders all <applet> tags invisible. Counterintuitive as it may seem, this is what happens. The insidious part is that perplexed users know they have Java installed because they can see the plug-in, are being told by IE that it's active, can find some applets that *do* work and - well, you get the idea.

The third problem with the <applet> tag is that, by itself, it has no mechanism to indicate which version of Java is required. This can be a very important consideration for applets that take advantage of the major advances in functionality and performance of the Java platform in recent years.

A Better Way: Deployment with the `<object>` Tag

All major browsers support the <object> tag, and this is the preferred method for deploying applets. Provided that Internet Explorer's peculiarities are accounted for, a single piece of valid HTML can render applets on all major browsers including:

IE 6/7
Firefox 1.5/2
Safari

As a specific example using ChemWriter, the <applet> tag above can be re-written with the <object> tag:

<!--[if !IE]> -->
<object classid="java:com/metamolecular/chemwriter/applet/EditorApplet.class" 
              type="application/x-java-applet"
              archive="/path/to/applets/chemwriter.jar" 
              height="350" width="550" >
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <!-- For Konqueror -->
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>

    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<!--<![endif]-->
<!--[if IE]>
<object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
                codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0"
                height="350" width="550" > 
  <param name="code" value="com/metamolecular/chemwriter/applet/EditorApplet.class" />
  <param name="archive" value="/path/to/applets/chemwriter.jar" />
  <param name="persistState" value="false" />
  <center>
    <img src="/path/to/images/chemwriter_logo.png" />
    <p><strong>ChemWriter content requires Java 1.4.2 or higher, which your browser does not appear to have.</strong></p>
    <p><a href="http://www.java.com/en/download/index.jsp">Get the latest Java Plug-in.</a></p>
  </center>
</object>
<![endif]-->

Before explaining the code, here's what the verbosity buys:

It works with both IE 6/7 and standards-compliant browsers such as Firefox.
It avoids the use of JavaScript JVM detection methods.
It prompts the user to download the correct JVM, without immediately directing them away from the current page.
Firefox and IE users can opt to install the Java plugin without ever leaving their current page.
It works in IE 7 with the Java console disabled.

You've Got Some 'Splainin' to Do

The code above is based on documentation found on this site, which also details the meaning of the codebase and classid attributes.

The main idea is that Internet Explorer handles the <object> tag in its own idiosyncratic, lovable way. Most of this difference is in the <object> element itself and the classid attribute in particular. By taking advantage of Internet Explorer's support for conditional comments, we can handle both IE and the rest with one chunk of HTML.

A Live Demonstration

For a live demonstration of the above technique, see the ChemWriter Home Page. If you have Java 1.4.2 or higher installed and activated in your browser, you'll see the most recent version of the ChemWriter editor applet. If not, you'll see the ChemWriter logo and a link to install Java. Firefox and IE will also display an "Install Plugin" bar at the top of the browser for in-place installation of the JVM.

Click to Activate: Working Around Eolas

A recent Depth-First article discussed the problem that IE 6 and 7 have involving a "click to activate" (or "Eolas") message that appears with applets and all other browser plugins. To eliminate this issue, the ChemWriter Home Page uses the excellent jActivating library. This JavaScript library, which is included in the HTML <head> tag, obviates the need to write the <object> tag using JavaScript. All that's left is pure, standards-compliant HTML to debug, deploy, and maintain.

Conclusions

Applet deployment, like Java itself, has come a long way in the last ten years. This article has shown one method to deploy applets into highly heterogeneous computing environments with relatively little effort.

But deployment is only one aspect of interactive Web development using applets. Future articles will discuss some of the others.

Image Credit: oskay

Depth-First: Tag objecttag

Building WebSpex: Putting Custom Data Types In Their Place

Tag Soup

Some Options

Encoding Custom Data Types With The Object Tag

Advantages of Using This Approach

Implementation Detail

Previous Uses

Conclusions

Demystifying Java Applets, Part 1: Cross-Browser, Standards-Compliant, Pure HTML Deployment Using the Object Tag

Applets? You Must Be Joking!

Deployment with the <applet> Tag

A Better Way: Deployment with the <object> Tag

You've Got Some 'Splainin' to Do

A Live Demonstration

Click to Activate: Working Around Eolas

Conclusions

Deployment with the `<applet>` Tag

A Better Way: Deployment with the `<object>` Tag