Depth-First: Tag javascript

Building ChemWriter: What to Do When Requesting Applet Keyboard Focus Leads to Disappearing Popup Windows

Rich Apodaca — Thu, 06 Nov 2008 19:35:00 +0000

Recently a customer reported a problem in which mousing over an instance of the ChemWriter editor applet caused browser popup windows to disappear behind the parent window. Although many view browser popup windows as bad UI design, there are situations in which no alternative exists. This article describes the window focus problem in detail and outlines one solution.

Background

One of the ways ChemWriter makes chemists more efficient at drawing chemical structures is through the use of keyboard shortcuts. Rather than having to mouse back and forth between a tool palette and drawing canvas to put in atom labels, simply hover the mouse over the atom to label, and press a key on the keyboard. In addition to atom labels, there are keyboard shortcuts for chains (keys 1-9 while hovered over atom), for benzene rings ("a" key), and to edit bond order (1-3 while hovered over bond). A short movie explains the feature in more detail.

Although quite helpful to users, this feature requires some behind-the-scenes magic. Keyboard focus is one of those topics at the boundary between applet and browser for which very little documentation exists and, not surprisingly, one sees the most variation in platform and browser behavior.

The approach ChemWriter takes is to wait for a signal that the mouse cursor has entered the canvas area. When this happens, keyboard focus is requested through Component.requestFocus().

Scope of the Problem

It turns out that on Windows, Component.requestFocus() also causes the hosting window to be pulled to the top of the windows stack, explaining the behavior described above. On Linux and OS X, this doesn't happen, which is the behavior you'd expect.

All Windows browsers, except the much maligned Internet Explorer 6, show this behavior. This includes Internet Explorer 7, Firefox 3, and Google Chrome. Internet Explorer 8 beta 2 also shows the behavior, but only once per popup window.

Minimizing, then maximizing the popup window eliminated the problem some of the time. But a new popup window would still show the behavior.

The Solution

The root of the problem is that on Windows, keyboard focus is granted to an object regardless of whether the object's hosting browser window is focused. What's needed, therefore, is a way for the applet to implement a window focus check.

Apparently, nothing in the Applet API itself can solve this problem. The Applet, JApplet, and AppletContext classes only deal with much higher-level considerations.

However, it's possible to take advantage of support for LiveConnect technology on Windows, which is actually quite good. Using LiveConnect in combination with JavaScript's Document.hasFocus() method offers the makings of a solution. For example, the following code can be used as a starting point within a Java applet to determine if the containing browser window is focused:

netscape.javascript.JSObject js = netscape.javascript.JSObject.getWindow(this);
Object result = js.eval("document.hasFocus();");

if ("true".equals(result.toString()))
{
  requestFocusMethod();
}

Of course, requestFocusMethod() needs to be defined, we need to check for null, and we need to handle exceptions that could arise from a missing netscape.javascript package. You'll also need to ensure that non-windows browsers such as Safari/OS X never even try to execute the LiveConnect code due to a very buggy implementation.

Issues

I've seen mixed signals about the status of LiveConnect in the next major release of the Java plugin. Regardless of the specific way it's implemented, it seems safe to say that Java-Javascript communication is far too valuable to abandon. The only question is what form support for this feature will take going forward.

Conclusions

ChemWriter's ability to accept keyboard input is a helpful user interface feature, but one that resulted in window focus issues on Windows. Using LiveConnect in combination with some simple JavaScript in the focus-management code offered an effective solution.

Crazy Idea #6,349: JavaScript in PDF

Rich Apodaca — Thu, 18 Sep 2008 18:04:00 +0000

In reading through Bruno Lowagie's excellent book iText in Action, I noticed several references to JavaScript. I knew it was possible to do a lot of interesting things with PDF to promote interactivity. But JavaScript?

It turns out Adobe has even published about 1,000 pages worth of documentation on the subject in the form of the Acrobat JavaScript Scripting Guide and the Acrobat JavaScript Scripting Reference.

iText, the premier Java library for creating and manipulating PDF documents, supports JavaScript out of the box. The extent of this support is not clear to me yet, but the API does exist.

JavaScript has a lot of untapped potential for enhancing interactivity in cheminformatics. Similarly, PDF has a lot of untapped potential, which will be the topic of future articles.

What kinds of things could you do in cheminformatics by combining PDF and JavaScript?

Chrome and a V8: JavaScript Takes a Giant Leap Forward?

Rich Apodaca — Fri, 05 Sep 2008 01:42:00 +0000

Back when I started writing Java software in 1997, the Java Virtual Machine was slow. It was so slow that for years, many developers abandoned all hope of using the language for "serious" work once it became clear how much slower it was than C and C++. Eleven years of Moore's Law compounding, and countless JVM optimizations later, Java is so fast today that relative speed is rarely even considered when developing client and server applications.

Today, JavaScript occupies a similar position to that held by Java in 1997: a ubiquitous language with a basically good design that has significant performance issues.

The Next Big Thing? JavaScript Virtual Machines

This situation may be about to change - radically. Several groups are going to great effort to improve the performance of JavaScript by creating JavaScript Virtual Machines. The most recent entry into this increasingly crowded field is Google Chrome. Among Chrome's many innovations is the introduction of one of the first JavaScript Virtual Machines (V8) into a production browser. A virtual machine works fundamentally differently from traditional JavaScript interpreters, with the potential for greatly reduced memory requirements and speed increases.

Put a V8 in Your Browser

How fast is Chrome's V8 engine? We can get an idea by running some benchmarks.

The chart below shows the results of running Google's V8 Benchmark Suite (bigger bars mean faster execution):

As you can see, Chrome leaves both Firefox 3 and IE 7 in the dust, at least according to this benchmark. Another popular benchmark is SunSpider, where the results are qualitiatively similar; Chrome's execution time surpasses that of IE 7 by over two orders of magnitude.

My system consisted of an Ubuntu Linux machine running a clean install of Windows XP on Sun's excellent virtualization product, VirtualBox. Your mileage may vary. Note: it's important to disable Internet Explorer's warning prompt that reads "This page contains a script which is taking an unusually long time to finish. To end this script now, click Cancel." (the presence of which is telling in itself).This can be done by following the instructions here.

Conclusions

JavaScript is in the middle of a textbook Marketplace Disruption. Just four years ago, few even thought about the language. Today it's the centerpiece of Web interactivity. Perhaps the biggest issue remaining, performance, is now the focus of intense research that is beginning to bear fruit. Many of the key technologies now starting to appear, such as V8, are modular and open source; other browser vendors can adapt them for use in their own products. It's an offer few can afford to refuse.

Sooner than many might have thought possible, JavaScript may stop being viewed as the slow language. Then what?

JavaScript for Cheminformatics: Atom Typing with Prototype and Iterators

Rich Apodaca — Thu, 28 Aug 2008 19:08:00 +0000

The previous article in this series discussed the use of Prototype to build a simple cheminformatics model. But there's much more to Prototype than an improved class-like syntax. This article discusses one specific way that Prototype enhances JavaScript collections through iterators.

The Problem

Let's say we have an instance of Molecule, as defined in the previous article, and we'd like to group the carbon atoms separately from the heteroatoms. In many languages, including Java, we'd have to write a for-loop complete with logic for comparing atoms and then placing them into bins. Prototype makes possible a more modular approach with iterators.

Functional Programming and Iterators

JavaScript is a multi-paradigm programming language that offers tools for both object-oriented and functional programming approaches. In practical terms, this simply means that even functions in JavaScript behave as objects: they can be created dynamically and passed as parameters. Prototype takes advantage of this to extend collections instances such as Arrays with built-in iterators that are analogous to iterators found in languages such as Ruby.

A Simple Test

The JavaScript below builds a pyridine molecule:

function createPyridine(){
  var pyridine = new Molecule();
  var c1 = pyridine.addAtom("C");
  var c2 = pyridine.addAtom("C");
  var c3 = pyridine.addAtom("C");
  var c4 = pyridine.addAtom("C");
  var c5 = pyridine.addAtom("C");
  var n6 = pyridine.addAtom("N");

  pyridine.connect(c1, c2, 1);
  pyridine.connect(c2, c3, 2);
  pyridine.connect(c3, c4, 1);
  pyridine.connect(c4, c5, 2);
  pyridine.connect(c5, n6, 1);
  pyridine.connect(n6, c1, 2);

  return pyridine;
}

Saving this code in a file called molecules.js, we can use Firefox with Firebug to test it with the following HTML:

<html>
  <head>
    <script type="text/javascript" src="prototype.js"></script>
    <script type="text/javascript" src="chem.js"></script>
    <script type="text/javascript" src="molecules.js"></script>
  </head>
  <body></body>
</html>

With the Firebug console, we create a Molecule of pyridine:

>>> m = createPyridine();

To separate carbons from heteroatoms, we use the Prototype partition iterator:

>>> m=createPyridine();
Object atoms=[6] bonds=[6]
>>> m.atoms.partition(function(atom){return atom.label == "C"});
[[Object label=C neighbors=[2] bonds=[2], Object label=C neighbors=[2] bonds=[2], Object label=C neighbors=[2] bonds=[2], 2 more...], [Object label=N neighbors=[2] bonds=[2]]]

The partition iterator accepts a function as a parameter and returns an array containing two sub-arrays: the first contains the elements for which the function evaluated to true (carbons) and the second contains the elements for which the function evaluated to false (heteroatoms).

Conclusions

Although the example shown here is rather simple, it's possible to extend the general principle to more complex atom typing systems. By creating a single function that evaluated atom type, we could pass it as a parameter to any number of collection iterator functions.

JavaScript for Cheminformatics: Using the Prototype Framework

Rich Apodaca — Tue, 26 Aug 2008 14:01:00 +0000

If you want to do the kind of cheminformatics that involves manipulating atoms, bonds, and molecules, object-oriented programming works well as a development paradigm. Although perhaps not readily apparent, JavaScript offers everything needed to create object-oriented models just as intricate at those written in languages like C++ and Java. This article discusses one approach that makes use of the Prototype Framework.

About Prototype

Prototype is a set of extensions to the JavaScript language that make developing in it less painful. Some of the extensions relate to DOM manipulation. Other have to do with the way Strings and Arrays behave. For the purposes of this article, we'll be using Prototype's syntax support for classes and inheritance.

Atoms, Bonds, and Molecules

To start, we'll need classes that define the basic behavior of atoms, bonds, and molecules. Although we may ultimately need to consider issues such as multicentered bonding, for now, we'll stick to a simplified view of chemistry that has bonds connecting two and only two atoms.

Creating the Classes

We could use JavaScript's built-in method for creating objects from class-like structures, but Prototype's approach is cleaner.

In the following library, we define a Molecule as a collection of Atoms and Bonds with useful relationships:

var Molecule = Class.create({
  initialize: function(){
    this.atoms = [];
    this.bonds = [];
  },

  addAtom: function(label){
    var atom = new Atom(label);

    this.atoms.push(atom);

    return atom;
  },

  connect: function(sourceAtom, targetAtom, bondType){
    var bond = new Bond(sourceAtom, targetAtom, bondType);

    sourceAtom.neighbors.push(targetAtom);
    sourceAtom.bonds.push(bond);
    targetAtom.neighbors.push(sourceAtom);
    targetAtom.bonds.push(bond);

    this.bonds.push(bond);

    return bond;
  }
});

var Atom = Class.create({
  initialize: function(label){
    this.label = label;
    this.neighbors = [];
    this.bonds = [];
  }
});

var Bond= Class.create({
  initialize: function(source, target, type){
    this.source = source;
    this.target = target;
    this.type = type;
  },

  getMate: function(atom){
    if (atom == this.source) return this.target;
    if (atom == this.target) return this.source;

    return null;
  },

  contains: function(atom){
    return (atom == this.source || atom == this.target);
  }
});

Testing the Library

We can test the library interactively by saving it in a file called chem.js and creating some simple HTML:

<html>
  <head>
    <script type="text/javascript" src="prototype.js"></script>
    <script type="text/javascript" src="chem.js"></script>
  </head>
  <body></body>
</html>

We can then use the Firebug console to test the library interactively:

>>> m = new Molecule();
Object atoms=[0] bonds=[0]
>>> c = m.addAtom("C");
Object label=C neighbors=[0] bonds=[0]
>>>n = m.addAtom("N");
Object label=N neighbors=[0] bonds=[0]
>>> m.connect(c, n, 3);
>>> c.neighbors.size()
1

Conclusions

Although the cheminformatics library discussed here is far from being useful, it's not difficult to see how to extend it. Prototype offers a several possibilities for doing so.

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

JavaScript for Cheminformatics: An Introduction to WebSpex, a Spectroscopy Tool for the Internet

Rich Apodaca — Thu, 17 Jul 2008 12:18:00 +0000

The previous article in this series discussed the untapped potential of JavaScript for building rich, chemistry-oriented Web applications. This article will describe the design of WebSpex, a spectrum viewer designed for the Web and written entirely in JavaScript.

Warning: Potential Vaporware Ahead

WebSpex can't yet be download or deployed, and it may never be finished. Articles like this one will document the tool's transition from concept to hopefully something more substantial. There may be false-starts and dead-ends along the way. But I'm hoping that there will also be feedback from readers like you. Feel free to chime in, regardless of your background.

This process will be necessarily non-linear. But I believe that being able to incorporate feedback in real-time increases the chances of creating a better product, and seeing mistakes, false-starts, and dead-ends in context can be useful to everyone.

The Problem

Of all the forms of chemical data generated in labs around the world today, spectra are one of the most common. Although several tools can display and manipulate these data, few are capable of being used on the Web. If you agree with the hypothesis that the Web is fast becoming the only information exchange platform that matters, this presents a significant problem (or opportunity, depending on your perspective).

Recently, a series of articles on the Web-based spectroscopy tool JSpecView appeared here. JSpecView is one of the only free tools currently available that enables spectra to be displayed and manipulated on the Web.

JSpecView is written in Java and deployed as an applet. In very many situations, applets are the best technology for delivering interactive Web content of the kind required by spectroscopy.

But no technology is perfect. One of the biggest limitations of applets is that they require the correct version of the Java plug-in to be installed on a users' machine (a limitation shared by all plug-in technologies, including Flash). In situations where users either can't or won't install the plugin, or in which adequate resources are not available to ensure smooth applet deployment, Java applets may not be the best technology platform.

What if there were a spectroscopy tool that worked on any browser without any plugin dependencies?

Scenarios

For a better idea of what WebSpex will be about, consider some scenarios:

Viewing Sally logs into her research group's spectroscopy archive website. She clicks on the link to her most recently-collected IR spectrum and is taken to a page displaying an image of her spectrum along with textual metadata.

Zooming Fred is viewing an IR spectrum published on a chemical supplier's Website. Wanting a better view of the fingerprint region, he uses the mouse to zoom the spectrum.

Peak Picking Victor is using a publisher website to view the IR spectrum of a compound described in a recent paper. Wanting to match the carbonyl stretching frequency of the material he prepared, he uses the mouse to pick the peak.

Data

WebSpex will use as its input format JCAMP-DX, the de facto standard for spectral data encoding. Although JCAMP-DX has been extended in many ways over the last several years, for now the goal of WebSpex will be to simply read and display error-free examples of the original format specification.

Conclusions

Good Web-based spectroscopy tools are a prerequisite for the open sharing of this important form of experimental data. WebSpex could fill this need by providing an installation-free tool that can be used in any browser without plugins. Currently consisting of nothing more than just some ideas, WebSpex successes and failures will be documented here in several installments.

Image Credit: estaticist

JavaScript for Cheminformatics

Rich Apodaca — Tue, 15 Jul 2008 08:32:00 +0000

Regular readers of this blog know that one of its recurring themes is the convergence of Web technologies and chemical information. Although several articles describe how Ruby and Java can be applied to cheminformatics, one language has never been featured: JavaScript. JavaScript is both the default language of the Web client, and a language of growing importance elsewhere. This article, the first in a series, introduces JavaScript as a tool for creating rich, chemically-oriented Web applications.

Surely You Jest

If your last exposure to JavaScript was in the 1990s, a lot has changed for the better. Most importantly, performance has increased considerably, making possible JavaScript software of considerable complexity. A growing collection of well-crafted libraries such as Prototype and Scriptaculous now make it possible to focus precious developer effort at a higher level of abstraction. Although cross-browser compatibility continues to be an issue with browser-specific features, the JavaScript language itself is now remarkably stable and consistent across browsers and platforms.

JavaScript will obviously never enjoy the performance of Java or C++, and it would be a mistake to assume otherwise. The key is to focus on what JavaScript can do that no other language or platform can. With this thought in mind, it's interesting to speculate on the role JavaScript could play in developing Web-based software for chemistry.

For example, with essentially complete read-write access to the document object model (DOM) of sites on which they're active, tools based on JavaScript have great potential to enhance static content with content created either on a server or locally.

As another example, consider the combination of JavaScript and an invisible Java applet. Java-JavaScript communication is possible in all browsers through LiveConnect, which can be used to offload computation-intensive operations from JavaScript to an applet. In many ways, this approach to development on the client resembles the approach, discussed here many times, of using Java from Ruby through Ruby Java Bridge (RJB) or JRuby.

Ultimately, JavaScript is the only programming language that allows cross-browser, client-side software to be written independently of a plugin. This may not sound like a big deal, but for many developers and organizations, Flash, Java, and other plugin technologies are less than ideal.

What's Known?

There are currently only scattered examples of the use of JavaScript in chemistry, an indication that either the field is ready for this idea, or that it will never work.

Perhaps the two best-known examples of JavaScript applied to chemical informatics are the WebME and PubChem chemical structure editors. Although remarkable accomplishments, both packages rely heavily on server back-ends for processing and analysis of chemical structures. The JavaScript code serves mainly to asynchronously pass low-level mouse events to the server, which then asynchronously passes a raster image back to the client. To an extent, the back and forth degrades the responsiveness of these tools.

The Blue Obelisk maintains a Wiki page discussing some of the uses of Greasemonkey scripts in chemistry. Greasemonkey is a wonderful tool for augmenting existing Websites, and these scripts do some remarkable things, but they don't fall into the category of cross-browser, installation-free, general-purpose tools.

Recently, Robert Hanson discussed on-demand Javascript as a potential tool for building chemistry-oriented Web applications. Although the proposal contains many important points, it has to my knowledge not been followed up with the release of code.

An early compilation of resources can be found here, although all of the listed sites have since either disappeared or converted to other content.

Poking around the Web, it's possible to find many examples of one-off chemistry tools created in JavaScript. For example, this page contains a JavaScript-enabled periodic table. Useful as tools like this may be, they're not general-purpose solutions designed to create a platform for further work.

What Would Be Most Valuable?

There are many cheminformatics tools that could be built in JavaScript. But to be of the greatest value, a tool should be usable in a variety of contexts. And it should serve as a platform on which more complex software can be built. Even more importantly, the tool should fix something that really is broken.

We might begin by asking: what makes chemical information difficult to work with in the greatest number of cases?

Since the earliest days of chemistry and computers, it has been clear that one of the distinguishing characteristics of chemical information is the central role played by chemical structures and the difficulty in accurately representing and processing them on machines.

So, one answer to the question of what would be the most useful JavaScript tool for cheminformatics could be: a low-level cheminformatics toolkit that understands chemical structures and their associated graph operations.

Another possibility: the handling of NMR, IR, UV, and mass spectra. JSpecView is a good first choice, but it may be possible to build a pure JavaScript tool for interactively viewing and manipulating spectra, if a low-level toolkit for processing JCAMP-DX were available.

Would the performance and usability of such toolkits be high enough to make them a serious choice for use in chemistry-driven Web applications? What would the availability of such a toolkit enable that is currently difficult or impossible?

Conclusions

JavaScript is the default programming language of the Web client, offering a great deal to creators of chemically-oriented applications. One of the biggest barriers to using JavaScript for this purpose is the lack of key developer tools. Future articles will explore this idea.

Image Credit: johnmuk

Anatomy of a Cheminformatics Web Application: Structure Cleanup in Java Molecular Editor

Rich Apodaca — Mon, 18 Dec 2006 15:15:00 +0000

A very useful feature of many 2-D structure editors is a "clean" function that tidies up bond lengths and angles. Java Molecular Editor (JME) is a lightweight 2-D editor that lacks this functionality. In this article, I'll describe a small Web application called "Cleanup" that adds a "clean" function to JME through Ajax and server-side programming, rather than directly extending JME itself. The technique described here differs somewhat from that described in a previous article on adding InChI support to JME with Ajax.

Cleanup in Action

Let's say Bob needs to draw the structure of the H₁ antagonist chlorpheniramine with JME. He mistakenly creates irregular bond angles at several points, but continues drawing anyway. His finished molecule looks like that shown below:

Rather than starting over to beautify his molecule, Bob, simply presses the Clean Molecule button. This produces a structure with much more aesthetically-pleasing atom coordinates:

If Bob needs to continue drawing at this point he can. In fact, he can press Clean Molecule as many times as he wants to clean his structure at any time. Each time he presses the button, his structure is retained within the JME window.

Download and Prerequisites

Cleanup requires Ruby on Rails and Ruby CDK. Both of these libraries can be installed using the RubyGems packaging system.

A recent article described the small amount of system configuration required for Ruby CDK on Linux. Another article showed how to install Ruby CDK on Windows.

The complete Cleanup source package can be downloaded from RubyForge. For convenience, a copy of JME is included with the distribution. The author, Peter Ertl, has kindly given permission for the bundled JME applet to be used with Cleanup. For other uses, consult the JME homepage.

Running Cleanup

After inflating the Cleanup archive, the following commands will start the server:

$ cd jme-cleanup-0.0.1
$ ruby script/server

AMD64 Linux users will need to prepend a LD_PRELOAD assignment to the script/server invocation. On my system, which uses Sun's JDK, this looks like:

$ cd jme-cleanup-0.0.1
$ LD_PRELOAD=/usr/java/jdk1.5.0_09/jre/lib/amd64/libzip.so ruby script/server

After starting the Cleanup server, pointing your browser to http://localhost:3000/editor/cleanup will run the application.

How It Works: A Web Application in Two Parts

Cleanup is a Web application consisting of two main parts - one written for a Web server, and one written for a Browser client. These two components work together to achieve an effect that, to a user, is indistinguishable from extending the JME applet with Java.

The first component consists of small Rails application that accepts a Molfile as input and produces a Molfile with re-assigned coordinates as output. A Rails Action, clean_structure accepts a Molfile encoded as form data and produces a response Molfile with re-assigned coordinates.

The second component of the Cleanup application is written in JavaScript and executed from within the Browser. Let's take a look:

<script language="JavaScript">

  /*
   * Returns the client-specific version of XMLHttpRequest
   */
  function createXHR()
  {
    var xhr;

    try
    {
      xhr = new ActiveXObject("Msxml2.XMLHTTP"); // IE 5.0+
    }

    catch (e)
    {
      try
      {
        xhr = new ActiveXObject("Microsoft.XMLHTTP"); // IE 5.0-
      }

      catch (E)
      {
        xhr = false;
      }
    }

    if (!xhr && typeof XMLHttpRequest != 'undefined')
    {
      xhr = new XMLHttpRequest(); // every other browser
    }

    return xhr;  
  }

  function cleanStructure()
  {       
    var molfile = document.jme.molFile();
    var xhr = createXHR();

    xhr.open("GET", "clean_structure?molfile=" + encodeURIComponent(molfile));

    xhr.onreadystatechange=function()
    {
      if (xhr.readyState != 4) return;

      cleanMolfile = xhr.responseText;

      document.jme.readMolFile(cleanMolfile);
    }

    xhr.send(null);
  }
</script>

As you can see, the client side of Cleanup consists of two JavaScript functions, createXHR and cleanStructure.

The purpose of createXHR is to return a valid instance of the central Ajax JavaScript object, XMLHttpRequest. This function is a standard idiom in Ajax programming, and many JavaScript toolkits eliminate the need to write it explicitly. The function is included here mainly for the purpose of illustration. Microsoft browsers define two different flavors of XMLHttpRequest, and both differ from the flavor supported by every other browser. To take this browser-specific behavior into account, a series of try/catch blocks are used.

The second function, cleanStructure does all of the JME-specific work. After obtaining an instance of XMLHttpRequest, a HTTP GET request is built from JME's molfile. Of course, the magic of this request is that it is asynchronous; it will not block the browser while it is being processed. When the request is complete, the cleaned Molfile is read by JME.

Through the coordinated action of both of Cleanup's components, the application gives the appearance that JME has cleaned its own structure.

So What?

Well-designed, rich functionality makes software interesting and useful. At the same time, users demand software that loads and responds quickly. Using the technique presented here, it's possible to satisfy both of these contradictory requirements. Delegating key tasks to a server obviates the need to transmit large Java libraries to clients. Instead, small Java libraries can be transmitted, and several small asynchronous requests will be processed along the way.

Viewed from this perspective, the capabilities of a good Java applet take on a very different character from what many have become accustomed to. In particular, extensibility and a robust, text-based communication protocol become much more important than built-in features.

For example, we could provide a much more consistent user experience if the Clean Molfile button were contained inside the JME editor itself, instead of on the Web page. In a more general sense, we'd like JME to offer the option of defining custom buttons that can be assigned arbitrary actions. Because Java/JavaScript integration is very well-supported, these custom actions could actually be written in JavaScript.

Conclusions

Java applets have been much maligned of late, partly due to the realization that in many situations they can be replaced with Ajax. However, well-designed, small, and extensible Java applets can play a key role in certain kinds of Ajax applications such as the one described here. Future articles in this series will explore some more of the many possibilities.

Look Ma, No Applets!

Rich Apodaca — Thu, 09 Nov 2006 14:28:00 +0000

The state of the art in structure editors for chemical Web services is Java applets. Although closed editors have long dominated this field, Open Source editors are a possibly viable option. Java applets are great from a developer's perspective. But applets are avoided by some end users and IT support for their underlying need to install a Java plug-in of some kind and long startup times.

Through David Bradly's sciencebase, I came across a non-Java solution to the structure editor problem. The software is called WebME. WebME looks and feels similar to Java Molecular Editor. It loads quickly and provides a clean, inviting user interface. It should work in any modern browser. Most interesting of all, WebME works without a browser plugin of any kind.

The magic behind WebME is AJAX, which has been summarized by Paul Graham as "Javascript now works". By asynchronously interacting with a Web server as user interface events occur, WebME is able to cram a lot of functionality into a relatively small deployment package. The user interface is written in a mixture of HTML and JavaScript, thus eliminating the need for Java.

Although WebME's use of AJAX is innovative, other non-Java solutions to the structure editor problem have also been implemented. For example, PubChem have developed an editor in JavaScript/HTML for use with their popular service.

Despite its advantages, the AJAX approach does involve some trade-offs. For example, WebME is not nearly as responsive as, say, JME. I would imagine that unusually high network latency could further erode WebME's responsiveness. Furthermore, the subtle visual cues that make JME a productive tool, such as highlighting the node or edge the cursor is about to edit, are non-existent. It's unclear if this is a limitation of this particular version of WebME I used or the underlying technology.

AJAX is a promising new technology that may well have a place in producing ergonomic user interfaces for chemistry Web services. On the other hand, it wasn't too long ago that JavaScript "didn't work", was loathed, or simply ignored altogether. It may well be that Java applets undergo a revival similar to that of JavaScript, perhaps triggered by built-in support for applets made possible through an open source Java implementation. Regardless of how Java applet technology evolves, WebME's approach is worth serious consideration.