On 2012.08.05. 22:55, Robert Hanson wrote:
Gusts, good to hear from you. Sorry to hear about your "vacation"
comments below.
On Sun, Aug 5, 2012 at 1:59 PM, Gusts Kaksis <gusts.kak...@gmail.com
<mailto:gusts.kak...@gmail.com>> wrote:
Hi, Bob!
script(script_source) - execute a script. Same as
Jmol.script() in your solution
2nd level methods - abstract jQuery bind() methods and some
element type checkings
bindClickScript(element, options) - bind a script to some
element that can receive click events. Options here can be
many things:
a) a script source as a string
b) a callback funciton that returns script source as a
string (I followed your advice and added those 2 parameters -
Jmol object and the clicked element itself - in that order)
And the function parameters. Third parameter, perhaps. This is
very useful, because it allows one function to process clicks
from a variety of elements and conditions.
I quite didn't get you here. What third parameter?
Just make sure that the script allows us to pass parameters to the
function as we do now. I think you've got it. For example, in a recent
page, we have:
Jmol.jmolButton(jsvApplet, [doSave, false], "Save")
Jmol.jmolBr()
Jmol.jmolButton(jsvApplet, [doSend, false], "Create PDF")
Jmol.jmolBr()
Jmol.jmolButton(jsvApplet, [doSend, true], "Send PDF")
I think you mentioned that above.
Ahh, now I got it. But I really do not understand the need of passing a
parameter through Jmol (weather JS library or Java applet) to user's own
function. I'd do it differently:
function doCreatePDF(jmol, this){
return doSend(jmol, this, false);
}
function doSendPDF(jmol, this){
return doSend(jmol, this, true);
}
Same computational overhead (of function call), but ... Power to the
People :)
If it's not a link, then data-script attribute will be used.
What's the significance of the difference there? Say, between a
button and an anchor?
Button does not have a href attribute. Also buttons are
one-hell-of-a-pain-in-the... to do proper styling on. That's why I
prefer anchors, and also they usually point to a real file (in my
case), so that's why I'm using them.
As long as there's no difference in capability between the two, that'
fine.
addDataScript(element) - read href or data-script (same as
bindClickScript)
addURLLoader(element) - load model data from a file specified in
a href attribute
Are all these distinctions necessary? A simple script in each case
should be able to handle any of this.
1. is used to perform "script" command in Jmol
2. is used to perform "load" command in Jmol
This doesn't make a lot of sense to me. the LOAD command rarely
involves just one parameter (the file name). That seems very
specialized (and not useful) to me. For example, once a file is
loaded, you need to render it one way or another. You can do it all
with a script command. So I would get rid of (2).
Sorry, I lied. :)
1. is to add a click event listener and use the contents of data-script
attribute as a script source - just call Jmol script() method with all
what's written in data-script attribute;
2. is to add a click event listener and use anchor's href attribute to
load molecule data from a file located on server sending "load [contents
of href attribute]" to script() method of Jmol applet.
Two completely different things.
addAJAXLoader(element) - same as previous, just use AJAX and
call "load inline" in Jmol - actually this might be a great
alternative for signed applet. Just a thought.
Well, not really. The thing is, we can't depend upon XHR2 because
it's just not out there reliably and won't be for several years,
probably. So one needs either a server-side app (jmolcd2.php) or
the signed applet.
Well, I've been using AJAX (and by AJAX it does not really matter,
weather it's XHR1, XHR2 or XDR, all I'm doing is making an
asynchronous GET request to server) for couple of years now,
without a problem. So I'd like to disagree to your statement. :)
That's fine if you are getting files from your own server. It's when
you want to get data from RCSB or NIH or PubChem or wherever that your
AJAX will fail. That requires XHR2 and (a) not all sites are up to
speed on adding the proper header to the reply for that, and (b) not
all browsers allow it anyway. For example, MSIE 8 doesn't. That's what
it's all about there. The signed applet doesn't need this -- it can do
the call directly; it's the unsigned applet and the image-display
option that need this. And ChemDoodle.
But take a look at my example http://dev.gusc.lv/code/jmol/simple2.html,
it requests data from PubChem and the others through AJAX and pushes the
results to Jmol applet with "load inline" command.
The trick with IE8 and 9 is that you have to use XDR (XDomainRequest),
which is basically the same as XHR, just, as usually, the Microsoft way.
And with this jQuery plugin iecors
(https://github.com/dkastner/jquery.iecors) it adds XDR as an AJAX
driver (instead of default XHR), so to speak.
By "load inline" you probably mean the LOAD DATA statement. You
should never call applet.loadInline() anymore. It's not thread-safe.
Sorry, I meant <select> elements.
I'm referring to Jmol scripting commands, not actual applet's
interface methods. The only method jQuery-Jmol uses is script()
method.
Yes, good. How are you handling the getProperty options?
Well, If you're referring to Jmol applet's interface method, then I'm
still waiting for some documentation about these methods from you.
Also, how are you handling the caching of script requests prior to
applet initialization?
It's done. You can actually call my jmolscript() prior to any
initialization, but you might need an id attribute set.
Q: What about the destroy method in Jmol applet's interface? Is it
possible to create one? And will it help the situation with IE, when I
want to remove applet from DOM tree without crashing the browser? I've
done server side Java development, but I've never developed Java browser
applet's so that's kind of an unknown territory for me.
--
Gusts Kaksis
------------------------------------------------------------------------------
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
