right, well, that's what getProperty("atomInfo") does. The "string" is instead a
"structure" that any attached agent (such as Jmol.js or another app) can turn
back into whatever human readable form it so chooses. This is far better (I
think) than sending it out as a string and then having other software have to
turn it BACK into a structure to read it. The catch is that you can't reliably
pass Java data structurss to JavaScript, so that's where JSON comes in -- it
makes a "machine-readable" string out of the data structure which then can be
turned back into a data structure without parsing it as a "human-readable"
string. The model is:
file string --> data structure
Java data structure --> other apps directly usable data
Java data structure --> other apps --> human-readable form
Java data structure --> JSON --> JavaScript data structure
JavaScript data structure --> directly usable data
JavaScript data structure --> human-readable form
rather than
file string --> property string
property string --> other apps --> human-readable form directly
property string --> other apps --> parsed type conversion --> usable data
property string --> JavaScript --> human-readable form directly
property string --> JavaScript --> parsed type conversion --> usable data
That is, it's a data use model with human-readability option rather than a
human-readable model with optional data use.
Something like that.....
René Kanters wrote:
On Mar 30, 2006, at 6:22 PM, Bob Hanson wrote:
Miguel wrote:
The problem is actually with getAtomSetCollectionProperties and
getAtomSetProperties ... those entry points were intended to be used
for
passing more complicated information from the Readers to the Viewer.
right - they only pass strings. That's pretty much useless. These
should probably be abandoned.
Actually Miguel and I had a long discussion about that when he added
the properties as strings only. His reasoning, which I now agree with
(since I make use of that in the AtomSetChooser feedback) is that it
would be hard to communicate the values of the properties to users if
they can not be cast in a easily interpretable format (i.e., human
readable string).
Bob pointed out that he could not use getAtomSetCollectionProperties
because he needed to pass more complicated data structures. So he
created
auxiliaryInfo methods that use Hashtable.
This is something that we need to take a look at and consider. These
two
things need to be consolidated ... because they are trying to
provide the
same functionality.
This is also related to the API and data structures that we use to
exchange information between the viewer and JavaScript or the viewer
and
Java.
Right.
I strongly suspect that the Hashtable solution is the right one and
that
we will replace the use of java.util.Properties in org.jmol.api.* with
java.util.Hashtable. This will need to be reviewed after the 10.1
release.
Great. This is a rich source of information. Costs next to nothing.
Useless of course without getProperty()!
So, this auxiliaryInfo API enhancement will not make it into the 10.1
release. Nor will the reader changes (SpartanSmol + Gaussian ?) that
depend upon it.
Fine, as long as it's a priority right after. Along with getProperty
(). getProperty() and draw should have top billings after 10.1;
frame/visibility very close 3rd in my opinion. Spin right up there, too.
Bob
--
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
--
--
Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107
Professor of Chemistry, St. Olaf College
1520 St. Olaf Ave., Northfield, MN 55057
mailto:[EMAIL PROTECTED]
http://www.stolaf.edu/people/hansonr
"Imagination is more important than knowledge." - Albert Einstein
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
