I've just committed two minor (proposed) updates:
1) applet.loadInline(strModel,script);
This fixes an old problem that one could load a file and run a script,
but one couldn't load a model inline and run a script. With this
(proposed) update you can do both in one shot.
2) applet.getProperty("bondInfo","<atom selection>") and
applet.getProperty("extractModel","<atom selection>")
The purpose of this extension is to make possible something that I
know many of us have WISHED we could do but couldn't -- extract pieces
of a model out into a separate, smaller file.
These two properties complete my demonstration of the getProperty()
idea that Miguel asked for earlier. The working demonstration web page
and associated jar files can be found at
http://www.stolaf.edu/people/hansonr/jmol/test/json.
There should be sufficient options there now to get us talking about
what we really want to do with this.
Consider everything I do with getProperty() only a test -- an
exploration of what the capabilities of this might be. It is possible
that, in the end, method or parameter names will be changed, and, I
suppose, that some would be removed.
Internally, now it's time to think about how exactly getProperty()
should be implemented vis-a-vis applet and app, and how this "reading"
idea meshes with the Jmol philosophy.
Currently I've got getProperty() working from within Viewer, and only
intended for use by the applet; I'd like to know more about how a
"common" interface might be set up. Presumably this means that the
applet and app would have the same interface but implement these
differently -- one using JSON objects; the other some sort of
agreed-upon Java data structures. I don't in any way want to imply
that I know how to do this.
I like Miguel's idea that a common class could generate Java
structures that could then be simply converted into JSON objects on
the fly instead of creating two distinct parallel methods.
My implementation is rough, for sure. Just JSON, just to get the idea
out there enough that we could give it a try. Personally, I'm
convinced that JSON is ideal for the applet --> JavaScript synchronous
connection. Far as I can tell, it works like a charm and is very flexible.
One thing I'd like us to think about is how to crack the callback
problem once and for all. One option would be that the MAYSCRIPT
parameter is removed -- or at least the capability of the applet can
be fully in place without MAYSCRIPT. That is, the applet never calls
any JavaScript function.
One idea I have is a data structure that maintains the status of all
of the information generally sent to callbacks -- frame status, pick
status, message log, file load status, etc. A page could poll this
data structure using getProperty() and just look for whatever changes
might be of interest, then respond as need be, perhaps requesting more
specific information (what atoms were clicked, what the new
orientation is, etc.). This would require a single setTimeout() per
applet, probably with a 50-100 ms turnaround (maybe).
Anyway, that should be enough to get us going. I know, time to back
off and let this digest....
Bob
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
