right. auxiliaryInfo was generally implemented, but only applied in the Spartan
SMOL file reader. It looks like a lot of coding, but really almost all of it is
what I call "stitching" because it feels like you are stitching together a
fabric (Viewer --> ModelManager --> Frame --> Mmset), with a suite of functions
to pull out specific data types. Nothing really fancy there; just following a
system.
Miguel, one thing to think about:
Somewhere along the way the "Collection" word was dropped, which I copied:
setModelSetProperties(adapter.getAtomSetCollectionProperties(clientFile));
setModelSetAuxiliaryInfo(adapter.getAtomSetCollectionAuxiliaryInfo(clientFile));
Properties modelProperties = adapter.getAtomSetProperties(clientFile, i);
Hashtable modelAuxiliaryInfo = adapter.getAtomSetAuxiliaryInfo(clientFile, i);
This was a real nuisance. It creates confusion as to what a "Set" is (one thing
in the adapter; another thing in Viewer. When you implement this or integrate
these, perhaps you can align these. Unless there is some logic to
atomSetCollection --> ModelSet
atomSet --> Model
I suppose there might be some logic to that.... (There really are "model sets"
in real life -- they are collections of atoms though, not collections fo models.
So maybe that's what seemed confusing there.) I guess I would prefer:
setModelSetProperties(adapter.getModelSetProperties(clientFile));
setModelSetAuxiliaryInfo(adapter.getModelSetAuxiliaryInfo(clientFile));
Properties modelProperties = adapter.getModelProperties(clientFile, i);
Hashtable modelAuxiliaryInfo = adapter.getModelAuxiliaryInfo(clientFile, i);
It's just an odd sort of wordplay going on there. Not a big deal.
Bob
René Kanters wrote:
On Mar 30, 2006, at 6:11 PM, Miguel wrote:
Review prior to 10.1 release
============================
[snip]
Reader/File related
-------------------
[snip]
r4624,r4625,r4630 - auxiliaryInfo
r4623,r4635,r4640 - SpartanSmolReader
OK r4623 was reintroduced in r4854. The JUnit tests run fine on all
of the
SpartanSmol files.
I uncovered a problem when looking into auxiliaryInfo and the other
reader
changes that depend upon it ...
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.
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.
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.
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.
As far as I know the Gaussian change does not use the auxiliaryInfo.
The only modification was to be able to recognize the additional
Gaussian data file we had, and also allow for reading output from PM3
(Semi-empirical) calculations as opposed to only HF and DFT types.
I really would like to have SpartanSmolReader to still interpret the
archive information and the vibrational vectors. I know that the old
reader will in a lot of cases test properly with JUnit, but it does not
get all this information. So maybe a partial introduction of Bob's
modification?
These are revisions r4624,r4625,r4630,r4635,r4640
Miguel
-------------------------------------------------------
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
-------------------------------------------------------
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_______________________________________________
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
