On 2012.08.07. 17:03, Robert Hanson wrote:
On Tue, Aug 7, 2012 at 6:40 AM, Gusts Kaksis <gusts.kak...@gmail.com
<mailto:gusts.kak...@gmail.com>> wrote:
Hi, Bob!
I've already started planing the next iteration of my jQuery
plugin with
a little bit different approach - trial and error is the way to go
:) I
wanted to ask a few questions about Jmol applet though, as I didn't
receive any descriptions about the external methods (and there is no
commentary in applet's source code, except for deprecated
methods). I'm
talking about this class, that exports methods to JavaScript:
http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/JmolApplet.java?revision=16759&view=markup
1. What is the difference between getPropertyAsString and
getPropertyAsJSON, does the string version return human readable info
and is JSON version intended to return an object (key-value pair)
representation of this information? Also what's the output of
getProperty - string, object or JSON string?
You should just download Eclipse and check out the code. Then you
could easily follow it and answer all these questions yourself.
I've modified http://chemapps.stolaf.edu/jmol/docs/examples-12/new.htm
to give you some guidance. Scroll down to the bottom of the
left-side panel and see if that answers your questions.
Got it. I'll just stick with Array (I'll ask for JSON and then parse it).
2. Does the loadInlineString act the same as "load INLINE "fileData""
scripting command?
You should never use loadInlineString or load INLINE. Use the LOAD
DATA command.
OK
3. If I understood correctly from your comments in our discussion,
then
loadNodeId and loadDOMNode methods were just a test and they will be
deprecated in the future?
Essentially. It was just an idea that one of our developers had;
didn't go anywhere.
OK
4. Next, I'd love to have some explanation on what's the difference
between all of those script methods: script, syncScript, scriptNoWait,
scriptCheck, scriptWait, scriptWaitOutput. Pretty please! :)
syncScript is very special. It's for sending scripts to synchronized
applets. Not something a user would do themselves. See the
documentation on the SYNC command.
So it's used in between Jmol applets themselves, and it should not be
exported in JavaScript library?
scriptNoWait -- standard script entry, puts it on the queue.
scriptCheck -- just checks a script for syntax, doesn't run it.
scriptWait -- bypasses the queue and waits for output, returning a
rather complicated list of callback event information. I wouldn't go
there.
scriptWaitOutput -- bypasses the queue and returns the output buffer
(echo, message, print, etc.)
OK
5. And last, but not least. register and registerApplet - are
these for
synchronization? Is the fullName argument in registerApplet the same
syncId received by appletReadyCallback (2nd argument)? And what's the
second argument for register?
Yes, these are for synchronization. Don't play with those. Just make
sure your syncID is effectively unique.
OK, so I have to use a script command "sync" then with all it's options,
right?
My new idea is to create an applet wrapper class, that gets created once
the applet becomes ready. It will be thrown around in all the
events/callbacks as the first argument. And it will export applet's
methods or store something in cache if applet (for some unknown reason)
would not be available. jQuery-Jmol plugin would be used only to
initialize DOM node of Jmol applet and update some basic things, like
dimensions, visibility of the applet, also destroying it and restoring
placeholder to it's initial state (this option kind of complies with
jQuery UI widget guidelines). I'm targetting this:
Initialization:
$('#jmol').jmol({... options ...});
Update options:
$('#jmol').jmol({... options ...});
Update single option:
$('#jmol').jmol('option', 'width', 200);
Some jQuery-Jmol internal commands:
$('#jmol').jmol('hide'); // Hide applet - set it to 2x2 px
$('#jmol').jmol('show'); // Restore to original dimensions (from options)
$('#jmol').jmol('destroy'); // Remove Jmol from DOM and destroy every
reference
$('#jmol').jmol('bind', 'pick', myPickListener); // This would be an
event binding wrapper -
$('#jmol').jmol('unbind', 'pick', myPickListener); // This would be an
unbind wrapper -
Binding wrapper would do the trick (although still, not quite
jQuery-way) - it would set up an appropriate callback in Jmol and then
bind an event listener to itself, so that callback listener could
trigger an event. And when all the listeners are removed, callback
should also be freed, so I'll send "set [callback] NONE". Event
listeners should always receive my wrapper object (which wraps a single
instance of an applet) and other parameters sent to callback (except for
the ID attirbute). For example a hoverCallback would be translated into
an event, that would receive these arguments:
function myHoverListener (jmol, label, index){
// Now you can just do some scripting
jmol.script('... some script source ...');
}
Methods, that I currently have in my Jmol wrapper, are:
getProperty - underneath it would use getPropertyAsJSON and parse the
JSON string prior returning a result.
getId - an ID attribute value of Jmol applet
script - same as in applet
scriptNoWait - same
scriptCheck - same
scriptWait - same
scriptWaitOutput - same
And, if I understood you correctly - other methods should not be made
public for JavaScript developers, these are either deprecated or for
Jmol intercommunication, right?
So, this is what I'm currently playing around with.
--
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
