On 2012.08.06. 14:07, Robert Hanson wrote:
On Sun, Aug 5, 2012 at 3:31 PM, Gusts Kaksis <gusts.kak...@gmail.com
<mailto:gusts.kak...@gmail.com>> wrote:
On 2012.08.05. 22 <tel:2012.08.05.%2022>:55, Robert Hanson wrote:
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.
I understood that. What I was trying to say was that #2 is not useful,
generally. It has very limited application, perhaps for small
molecules that don't really need Jmol for their display anyway. It
seems unnecessary. I don't think I've ever used such a simple load
command. Well, maybe once.
It's the same as why do you need an addButton method then :) If you're
building a helper library to aid development, it's for the best to add
more helpful functions than less. And it's still the same argument
between you and me, weather molecule files should be linked with an
anchor, which in case of Jmol's/JavaScript's or any other failure would
allow the client to download it and view it in, for example, Avogadro.
For example my father is hosting all the molecular data files him self,
so it would be useful for him, to load them as a file from server,
meanwhile allowing his students to download the mol file and edit it in
ISIS/Draw. So I don't see a point why not.
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.
I don't know. That site is reporting that I don't have JavaScript
enabled, which I do. So something is amiss there.
Which browser (version) does report that? Might be cache? I just opened
it up in IE8, Firefox 13, Chrome and it works.
I get the applet in Firefox, but the Show/Hide MEP button is not
working. (That's just because you are using an older version of Jmol.)
Yes, I see - if you use Load + MEP it will show MEP and "Show/Hide MEP"
button will hide it, but it will not restore it. There seems to be a
problem either in the version of Jmol (I'm using 12.2.32) or the script
itself (it's in data-script attribute). But I copied it from your site,
so I don't know...
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.
Ah, interesting. Good. Still, that requires sites delivering the
proper header.
You mean "Access-Control-Allow-Origin: *"? Yes it does, but it's the
default cross-domain behavior. The same pain as the signed Java applet
or crossdomain.xml file for Flash. Internet would have been a beautiful
place, if only not for those hackers :(
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.
Just deliver the contents as specified; the web page developer would
have information relating to these. Examples are at
http://chemapps.stolaf.edu/jmol/docs/examples-12/new.htm (near the
bottom on the left -- a set of links above the text area). But you
don't need to know any of the details yourself.
No problem. Same as jmolscript() I'll just have to introduce new jQuery
method (for example jmolgetprop(key, val). Just not to make everything
too complicated, I think I'll go with an array approach.
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.
The applet detects when it has been destroyed and clears itself out,
passing a callback to appletReadyCallback with a parameter false.
I have not experimented with removing the applet from the DOM tree,
but even doing a display:none on it in CSS destroys the applet in
MSIE. Don't do that.
Ahh, OK, well I'll play around that and do my internal cleanup in
onDestroy callback (jQuery-Jmol callback, not Jmol). This thing is kind
of important for performance. For example I'm showing a placeholder
image of some molecule instead of Jmol applet, and I have some 30-60
molecules on the page. So I'd like to enable Jmol on click and disable
other Jmol instance that's already visible. I'm afraid of the
performance hit on client side with 60 instances of Jmol. :/
--
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
