On Sun, Aug 5, 2012 at 3:31 PM, Gusts Kaksis <gusts.kak...@gmail.com> wrote:
> On 2012.08.05. 22: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.
>
>
>>
>>
>>> 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.
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.)
> 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.
> 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.
>
> 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.
>
> --
> 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
>
>
--
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
