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> 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.
>
>
>
>> c) nothing - in that case if it's a link and it has a href attribute,
>> that is not '#' or does not start with 'javascript:' will perform as a
>> script loader.
>>
>
> "script loader"? To me "script" and "load" are apples and oranges. You
> mean it will load a model or set of models with parameters, or run a script?
>
> it will look for a href attribute and if it's value is not '#' and it's
> value does not start with 'javascript:', then it will use the value of href
> as an URL and call "script URL" on Jmol. Assuming that the URL will hold
> the script's source. It does not use "load" command here, as you pointed
> out earlier, that I should use "script" command instead.
>
>
that sounds right.
>
>
>
>
>> 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).
>
>
>> 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.
>
> 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?
Also, how are you handling the caching of script requests prior to applet
initialization?
>
>>
>>
>>
>> With this demo I've made it would look like this:
>>
>> var my_jmol = new Jmol(...something something...);
>> my_jmol.addScript('#link1', 'wireframe 0');
>> my_jmol.addScript('#link1', 'script myscript.spt');
>> my_jmol.addScript('#link1', function(jmol, el){
>> return 'echo "yes!"';
>>
>> });
>>
>
>
> Yes, that sounds good. In my implementation, where you can have
>
> jmol = Jmol.getApplet("jmol",....)
>
> jmol is a new Jmol._applet(), so that's basically the same thing, I think.
>
> Some of the more sophisticated aspects of Jmol objects, such as linked 2D
> rendering and information panels would be nice to plug in here. As well as
> all the 2D and WebGL options. If you could build from JmolCore and mostly
> provide a new jQuery-based interface (replacing JmolApi but not all the
> Jmol objects), that would be more sensible, it seems to me. Can't we do
> that? I hate to see you recreate all this from scratch.
>
> From now on I think, I'll stick to jQuery-Jmol only. I'll finish
> jQuery-JME and then I'll take a look into GLmol. And after that, I'll try
> to create one unified library, that can switch between three of them -
> GLmol for iOS devices, Jmol for all other and JME where possible to add
> some editing capabilities.
>
>
>
>> Still not sure how that would work for selects or check boxes...
>>
>> Q: Is it pretty simple to set up checkbox groups in jQuery? JmolApi makes
>> that relatively easy.
>>
>> Not sure what you mean by that. Do you have some demo, that I could look
>> at, to see it in real world situation?
>>
>
> Angél Herráez probably does. It's been a while since I looked at that.
> Basically you click one "master" box off and all its boxes in sub-levels
> are unchecked as well. Hierarchically.
>
> It would be nice if Angel could send me some demos.
>
>
--
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
