From: Gusts K. <gus...@gm...> - 2012-08-05 20:31:14
|
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 <gus...@gm... > <mailto:gus...@gm...>> 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 |