Gusts,
OK, taking a look now at http://gusc.lv/jmol/assets/js/jquery.jmol.js
So I think this is based on Jmol.js, not JmolCore.js, right? In any case,
some advice:
We need this class to overcome stupid "functionName"-as-a-string
passed to Java Applet
Note that JmolApi does access the function directly, but I don't know that
there is an alternative to sending a String to the Java applet. This
function name is (or can be) set by Jmol scripting, so it starts as a
String and is saved as a String. Within Java we just access the method with
that name. Are you thinking there's a way around that?
_cbMeasure = function(id){
switch (arguments[3]){
case 'measurePicked':
I guess it's not clear to me why you are implementing callbacks in such a
specific way. Page developers generally substitute in their own callbacks
to handle their own specific needs. I guess some defaults like this might
be handy, but it needs to be clear how someone would override these with
their own methods. Remember that hover and pick callback messages can be
tailored by the developer. I wouldn't be parsing that string. That's a real
hack.
var jMol = (function(){
/**
* Default option set
*/
var _defaults = {
// Jmol initialization properties
appletUrl : '',
useSigned : false,
syncId: 0,
memLimit: 512,
width: 400,
height: 300,
menuUrl : '',
modelUrl : '',
background: '#000000',
// Jmol callback events
onEcho: null, // param: msg
onMessage: null, // param: args
onScript: null, // param: args
onSync: function () { return 1; },
},
/**
* Unsigned applet file
*/
_appletFile = 'JmolApplet0.jar',
/**
* Signed applet file
*/
_appletFileSigned = 'JmolAppletSigned0.jar',
It's important to have a random number indicated as the sync id. Don't just
assign 0. See JmolApi for several more defaults. Be sure to make it clear
how one overrides these.
_htmlTemplate = '<object type="application/x-java-applet" id="%id%"
name="%name%" width="%width%" height="%height%"%add_attr%>'
+ '<param name="syncId" value="%sync_id%"/>'
+ '<param name="progressbar" value="true">'
+ '<param name="progresscolor" value="blue">'
+ '<param name="boxbgcolor" value="%bg_color%"/>'
+ '<param name="boxfgcolor" value="black">'
+ '<param name="boxmessage" value="Downloading
JmolApplet ...">'
+ '<param name="mayscript" value="mayscript">'
+ '<param name="codebase" value="%applet_url%" />'
+ '<param name="archive" value="%applet_file%" />'
+ '<param name="code" value="JmolApplet.class" />'
+ '<param name="java_arguments" value="%java_args%"/>'
+ '<param name="script" value="%script%"/>'
+ '%add_param%'
+ '<param name="appletReadyCallback"
value="JmolCallbackWrapper.cbReady" />'
+ '<param name="hoverCallback"
value="JmolCallbackWrapper.cbHover" />'
+ '<param name="loadStructCallback"
value="JmolCallbackWrapper.cbLoad" />'
+ '<param name="pickCallback"
value="JmolCallbackWrapper.cbPick" />'
+ '<param name="measureCallback"
value="JmolCallbackWrapper.cbMeasure" />'
+ '<param name="syncCallback"
value="JmolCallbackWrapper.cbSync" />'
+ '<p>You do not have Java applets enabled in your web
browser, or
your browser is blocking this applet.<br>'
+ 'Check the warning message from your browser and/or
enable Java
applets in<br>'
+ 'your web browser preferences, or install the Java
Runtime
Environment from <a
href="http://www.java.com";>www.java.com</a><br></p>'
+ '</object>',
The browser checking in Jmol.js and JmolApplet.js probably looks
unnecessary to you, but the general philosophy is to make sure this runs on
all browsers possible. There's a reason for that. I wouldn't mess with it.
Just use JmolApi to deliver this, please.
+ '<param name="appletReadyCallback"
value="JmolCallbackWrapper.cbReady" />'
+ '<param name="hoverCallback"
value="JmolCallbackWrapper.cbHover" />'
+ '<param name="loadStructCallback"
value="JmolCallbackWrapper.cbLoad" />'
+ '<param name="pickCallback"
value="JmolCallbackWrapper.cbPick" />'
+ '<param name="measureCallback"
value="JmolCallbackWrapper.cbMeasure" />'
+ '<param name="syncCallback"
value="JmolCallbackWrapper.cbSync" />'
Well, if we can avoid creating multiple objects it would be better. How
many primary objects are you creating here -- only JmolCallbackWrapper? Can
that all be within "Jmol." ? Also, you don't necessarily do yourself a
favor to generate unnecessary callbacks in Jmol. You are loading it up with
callbacks when you don't know that the user is interested. That's just
wasted communication.
/**
* It seems that "appletReadyCallback" return's an internal
wrapper object
* Which we kindly store here to use instead of
document.getElementById('some_applet') and then wonder
* why an object does not have a method for no reason.
*/
_applets = {};
yes, that's right, and it works great. That's what we do now in JmolApi.
Not sure why you are doing anything with _applets.
// Funny thing about Jmol Java
applet :)
// Hacking is the way to the
victory
_applets[id] = args[3];
Agreed. I think that one got missed in the documentation.
On the ready signal, you need to send all cached scripts.
_appletScript = function(id, command){
var applet = _appletFind(id);
_appletFind is obsolete. The idea is to always pass the object to the
function so that there is no finding anything. This was a legacy default
that has caused all sorts of grief and it is good to be done with it.
html = html.replace('%script%', script);
oooh, I really don't think that is going to work. You aren't escaping
double quotes there. Basically we don't send script to the applet in param
tags anymore. It just doesn't work reliably. Instead, take any script and
append it to a growing script that needs to be sent when you receive the
applet ready signal.
Most importantly, you need to make sure you never access the applet except
after its ready callback. no scripts sent; no queries made.
Overall, I think it has great potential.
Q: Will changes to jQuery have to be made to ensure the applet never
experiences CSS style.display = "none"?
Q: Would you be willing to create a version that is built around
JmolCore.js instead of Jmol.js?
Q: What's your plan for integrating JME, JSpecView, and ChemDoodle into
this?
Bob
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
