Lists Home |
Date Index |
I took a look at the Jmol CML interpreter and I can say that I was
I noticed something in the main web page (ref:
display the applet instead of using an HTML element.
jmolApplet(300, "script script/promotion1.en.txt");
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:
height=300 width=300 classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93
<PARAM NAME="_cx" VALUE="7938">
<PARAM NAME="_cy" VALUE="7938">
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 :-)
Didier PH Martin