Miguel wrote:
I cannot think about this as a 'callback' issue. I fundamentally don't
think of it that way.
One is a very simple delivery of a single parameter value -- what file
was loaded, whether there was an error loading the file, what frame is
being displayed, which atom was picked -- that sort of thing. No real
problem there.
I think that I basically agree.
One point ... you said 'which atom was picked' ... and I think you meant
'the last atom that was picked'
right. That's it.
2. more involved value
There are some values that one doesn't really want to deliver every
time they change (like orientation or measurement information), but
still you want to notify the application that they have changed and IF
there is an interest, they can be delivered in a second request. Sort
of a checkStatus/getProperty idea.
I don't see the difference between #1 and #2.
It would just be in terms of efficiency. Reorientation messages, in
particular, wouldn't need to be terribly specific, just "the model was
reoriented". But I could imagine it either way. Measurements looks like
it's really #1. I have the prototype putting out full measurements with
no problem.
I realize I'm working awefully fast here. This endangers mixing up the
getProperty() and callback issues, I know. Basically, the way I look at
it, we need to split the callbacks into two categories -- those that
really need to be event-driven (atom pick...), and those that don't
(show file...). Those that do need to be event-driven can be handled
through some sort of internal "listener" or "notification" scheme -- I'm
using JmolStatusListener because it pretty much collects everything I
needed. (I had to add back in that measurement listener, but all the
rest were there.) But we can move that out, if you like.
3. streaming information
This is the message log and perhaps the stream of information arising
from clicking on atoms.
I am not comfortable signing up for a 'stream of data' yet.
No,no. Sorry -- I sort of figured you would take that word a bit too
literally. This was meant in a figurative sense -- information/message
"streams" is being produced and maybe/maybe not consumed. Without a
callback, they have to collect somewhere until querried. That's all I
meant. My prototype seems to be working ok just implementing it as a
Vector that gets loaded and unloaded. "Stream" is not the right word,
because it has very specific I/O meanings, I know.
Q: Does this sound about right?
First steps should be querying static data about the model.
OK.
Q: Is there a very easy way to handle the simple "streams" of
information that isn't text. Is that a Java Vector, maybe?
I cannot think about this yet.
The Vector seems to work OK.
Q: What's the best way to make this work with the app and applet?
I see how the idea of a common interface would work -- and we
basically have that already, because the callback mechanism currently
works out of JmolStatusListener.
I think that you made some reference to JmolStatusListener before; I
should have said something at that time.
JmolStatusListener is evil ... it is part of the problem, not part of the
solution.
OK, we'll talk about that. Let's get it cleaned up. Right now, though, I
think I have to work with it.
But this is a little different
because basically the app and the applet should really have a COMMON
class, I think, like Viewer, or part of Viewer,
Correct. In one of my previous messages I think I said that all of this
stuff needs to go underneath Viewer
and then something has to connect the two different implementations of
the data transformation on the way out the door. I thought that was
JmolStatusListener -- an interface -- I'm eager to hear what you have in
mind.
that collects the
information for either and then, only in the "getProperties" side of
things, at the very end, would the two diverge.
(Now that part sounds
like an interface with dual implementations.)
They should not diverge. Rather, all the code should be in Viewer and the
exact methods should be published for the app API and the applet.
Right, but then the applet has to take in a different data format that
the app. JavaScript objects are not the same as Java objects, obviously
enough.
Q: Ideas for exactly where this should fit in?
Inside Viewer
That's where I put it -- I may have sprinkled a few things in
TransformManager and ModelManager -- but it doesn't matter to me.
A new class?
Probably
A new interface?
Nope
I guess you don't like interfaces..... JmolStatusListener was certainly
extremely useful for me at the learning stage. Very compactly showed me
how openscience/jmol/jmol.java and jmol/applet/jmol.java fit together.
But if there's a better way..... Hey, I'd like to see MeasurementTables
in the applet! :)
Extension of the JmolStatusListener interface?
Definitely not
Two new implementations of a class and one new interface?
Definitely not
you REALLY don't like interfaces, I think ! :)
I don't think this should be a terribly difficult thing to set up. I
figure whatever I implement on my own will just form the basis of
whatever we end up with anyway. But the closer I can come at this
point, the better -- and the more I'll learn.
Good.
OK, you should do your work inside orj.jmol.viewer.Viewer. We can split it
out into a separate class later.
I think I'm mostly done with the prototype. Let's work together now to
implement it properly.
Or, if you prefer, I can easily set up a 'PropertyManager' class for you
where you can do your work.
Let me know which one you want to do. I'll be glad to set up a little
infrastructure if that is what you would like me to do.
Can this be done as a separate branch in the CVS? I have it all ready to
go checked out as "Jmol-callback" but I don't know what to do next if I
were to put it up somewhere for others to look at and help me with it.
You want to implement
Object getProperty(String)
Object getProperty(String, String)
String getJsonProperty(String)
String getJsonProperty(String, String)
All the guts should be in getProperty, not in getJsonProperty
Right. Put that on the list to talk about. What I would then do is
have the applet.Jmol class expose "getProperty" and deliver
"viewer.getJsonProperty" while the app exposes "getProperty" and
delivers "viewer.getProperty" (That was the idea of the common
interface -- what am I missing that you dislike that interface so much?)
But the "JSON" isn't quite appropriate here, because not EVERYTHING
delivered to the applet has to be a JSON string -- file contents for
example -- single strings and such. They can just go straight to
JavaScript. It's just the more complex Java objects that need JSON.
There might even be a small openSource Java utility package that
converts Java to
JavaScript data formats directly. Basically JavaScript combines Vectors
and Hashtables into one common thing called an "Array" and all the
numeric types into "Number" so going INTO JavaScript is pretty
straightforward.
Now that I have written that, it occurs to me that this may be too
difficult for you, because the conversion from Java types to Json strings
might require Java type manipulations.
Nah. Difficulty is only a measure of time. So far I'm a fast learner. I
had fun with Hashtables and Vectors today, so I think I'm catching on.
Right now the message queue is organized in a Hashtable under the
category of the message, with Vectors representing each individual
message. That way it's easy to pull out just the ones that are
requested, and they come out in order using Vector.remove(0). For the
callback repackaging into JSON I have a routine that chunks the
Hashtable Vectors into a single Array of Arrays, but I can see there are
any number of ways of doing this.
Typecasting conversion, I'm not 100% there on. Took me a bit to figure
out what ((Integer)value).intValue() is all about.... There are a few
things I'm sure you see there that make you laugh. I know there's
something silly I'm missing with "Short".
This morning I mapped out all the threads and also all the interfaces. A
bit of a tangle, for sure. But I see where that's coming from. I went
through your Integration.java example fairly carefully. Still have a
question or two about abstract classes, but I see how it all fits
together reasonably well.
I think you will find that although JavaScript plays loose with the
types, I've benefitted from being a serious VB programmer who likes to
declare everything up front in a function even if it isn't necessary. (I
have been at this fairly constantly for, ah, 34 years -- wow, can that
be true? I guess so.... Hey, I remember reading paper tape -- by hand.
Ah, the old HP 2114B.... What fun!)
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
