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' > 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. > 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. > Q: Does this sound about right? First steps should be querying static data about the model. > 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. > 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. > 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 > 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. > Q: Ideas for exactly where this should fit in? Inside Viewer > A new class? Probably > A new interface? Nope > Extension of the JmolStatusListener interface? Definitely not > Two new implementations of a class and one new interface? Definitely not > 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. 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. 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 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. I'll get back to you. Miguel ------------------------------------------------------- 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&kid3432&bid#0486&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
