[
Lists Home |
Date Index |
Thread Index
]
Hello Peter,
I took a look at the Jmol CML interpreter and I can say that I was
impressed.
I noticed something in the main web page (ref:
http://jmol.sourceforge.net/). The demo is using a javascript call to
display the applet instead of using an HTML element.
<script type="text/javascript">
jmolApplet(300, "script script/promotion1.en.txt");
</script>
I think after having taken a look at the javascript that the jmol project
too is moving toward a layer isolating the document creator from the
browsers idiosyncrasies. For instance the previous imperative call is
translated into the following declarative code:
<OBJECT id=jmolApplet0
codeBase=http://java.sun.com/update/1.5.0/jinstall-1_5_0_07-windows-i586.cab
height=300 width=300 classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93
name=jmolApplet0>
<PARAM NAME="_cx" VALUE="7938">
<PARAM NAME="_cy" VALUE="7938">
</object>
This is the code I got in IE. The code is most probably different in Mozilla
since the latter don't understand what cabs are. In certain platforms it can
generate the <applet> element if this is what it can understand. When the
limits of declarative code are reached, imperative code comes to the rescue.
It's just a matter of thinking out of the box.
Having this type of code is a good step toward checking PRE-CONDITIONS
before interpreting and displaying the CML document. It can make possible
that different code be generated on the basis of different browser platform.
We have here the equivalent of an install program putting in place the
pre-requisites or code dependencies. Moreover, it can also check the target
platform a see that the latter support component caching and then cache the
code on the host machine so that next time, the code is loaded from the
machine instead of from the server. Sounds like JMOL people are taking the
right steps to control their run-time environment. Bravo!
Good sign, it seems that the jmol people too got out of the trance :-)
Cheers
Didier PH Martin
|
