> Some of my older pages do not use Jmol.js.
Jmol.js only came into existence a year ago.
> All my current development
> is with Jmol.js, with occasional "extensions" such as
>
> function addCallback(sappcode,functionName){
> return sappcode.replace(/\<param/,"<param name='messagecallback'
> value='"+functionName+"' />\n<param")
> }
>
> which allows the addition of callback parameters.
Correct.
The callbacks that are sometimes used by advanced applications are not
supported by Jmol.js
> All the documentation examples at
> http://www.stolaf.edu/people/hansonr/jmol/docs/examples now use
> Jmol.js with this sort of added extension.
good
> Reasons I'm exclusively using Jmol.js now include:
>
> 1. The realization that maximizing the number of browsers/platforms
> that I wanted my pages to run on required some pretty nasty tricks. I
> can let Miguel worry about the implementation details.
That is the idea.
> When word comes
> that something somewhere doesn't work, I'd rather install a new
> Jmol.js in a few choice directories than retool all my pages.
Since Jmol.js supports the DOM standard and also generates tidy HTML 4.01
code, I believe/hope that it will correctly recognize compliant browsers
for the near/forseeable future.
> 2. There were/are serious limitations using Jmol.js the "old" way
> (allowing the Jmol.js functions to use document.write), but now, since
> one can "turn off" direct document writing and instead just get the
> code from the function returns and add them wherever/whenever one
> wants using .innerHTML() or document.write(), those problems have gone
> away.
Yes, the recent enhancements allow for much-improved support of advanced
applications such as yours. Yet the introduction of this functionality was
transparent to existing web pages.
> 3. I rarely do anything as simple as throw up an applet on a single
> page with just a single molecule in there.
>
> 4. I'm moving more toward "write the applet on the fly" applications
> rather than the old "write the applet as the page loads". This is very
> easy with Jmol.js.
>
> That said, no one should feel obligated to upgrade anything that is
> working to newer Jmol.js or .jar files unless doing so makes the
> applet (a) load significantly faster or (b) load more reliably. Both
> of these HAVE been improvements lately.
I agree. No reason to upgrade simply for the sake of upgrading.
New web pages and Chime translations should be built using Jmol.js
Miguel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
