From: Ted C. <jm...@mo...> - 2012-01-22 02:32:48
|
Summary of what follows: When a structure is loaded inline, the "view" submenu of the "about" menu option fails. In any case(inline load or out of line load), the java applet sends a link(url) to the server when you click on the "view" option, the same as if you had clicked on a link in a normal web page. The resulting file, that can be opened or saved on the client workstation is the same structure file that was opened by the applet, before any alterations or combinations were made to it using Jmol. Detailed Explanation: On Sat, January 21, 2012 19:18, Herráez Sánchez Ángel wrote: > I hope to be of help rather than confusing to your problem. > We may be speeking of different ideas. You were very helpful and I now know exactly what is happening. Thanks so much Angel. > - There should not be any file being generated in the server, there is not, as we will see below. > everything is client. I was hoping that the client was involved, but it is not doing much, just sending a link to the server as if you had clicked on a link, as I will explain below. > Certainly Jmol is not posting back to the server. You are right, too bad as I will try to explain below. > In fact, Jmol applet reads the file from the server, > so there is no sense in posting it back, it's already there! Not necessarily, As I will explain, but that statement is the key to understanding what is happening. The view feature only works when the source of the structure is a file at a server that the applet previously read. When that happens, the name of the structure file is displayed in the "About" submenu. Selecting the "View" option uder that does generate a link to the server using that file name. The server does serve it back to the browser with appropriate headers and the browser is going to handle it based on how that individual browser was configured to handle resources of that type. Be it a browser plug in, a helper application, or a generic save/open menu. The server is actually invoved, there is a round trip as the client sends the url and the server sends back the same file that was previously retrieved by the java applet. > - I don't get what 'request' you expect to be happening. > Jmol or the browser will not send anythng to the server. You may not see it, but I assure you that it is happening the way I have described it. I suggest the following test to prove it: 1) Open a Jmol web app and display a molecule that resides on a server. 2) Once it is displayed in Jmol, rename the structure file on the server. 3) Clear the browsers cache. 4) Click on Jmol->Main Menu->About->Molecule Structure File Name->View. Instead of the molecule opening in the CHIME plug in as you are expecting, I predict that you will get a 404 not found message from your server. 4) Rename the structure file back and press F5 (refresh) in the browser window. The file will open as you expected. What happened to me is that because my molecule was loaded inline, not loaded from a server (ie, it was loaded from a "String"). When I do the Menu->About sequence, what I see is litterally, the word "string". Jmol can not display the name of my structure file because there was none. When I click on the "view" option, the applet does what it always does and sends the name of the file to the server in an http request packet. In my case, that name is "string" and the server has no clue what to do with it and returns the 404. I got all excited about a feature that I was imagining. That feature turns out to not be that exciting since it only works if the file already exists. I could accomplish the same thing by typing the url of the file in the browser address bar and the server would send it to the browser, the browser would figure out the file association and offer me the plug in, the helper of the open/save dialog just the same. Not a big advantage to me. I was thinking that maybe you could load a few structure files, manipulate them in Jmol and then save the result on your workstation, as it currently existed in Jmol, rather than as it initially existed in the structure file(s) on the server(s). If I have correctly diagnosed the problem with the "view" option when loading inline then I see a some options for the applet such as: 1) If the file is "string" disable the "view" option for that structure. 2) If it is not possible to disable a menu option on a case by case basis, then generate a warning if "view" is pressed but don't send off a url of "string" to the server which will generate an error. 3) Write a script and put it on the server as part of the intallation. Call it "mirror.php" or something. Have the applet post the string to mirror and have mirror echo it back with appropriate headers so the browser will handle it like it handles the non string structures that you are familiar with. Option 3 is what I was assuming had to be happening all along, mostly because that is what would have been most useful to me. If someone programmed the option 3 route, then you could rethink how to handle non-string molecules. If they have been modified in some way since being loaded, should the "view" menu option link to the unmodified structure file from the server or would it be better to mirror the molecule(s) as they exist in jmol at the time the "view" option is invoked? All of that last paragraph is based on an assumption that I am making which is that structure files can me modified in Jmol, even if it is just by rotating a molecule(s) or by combining molecules from multiple structure files. I am a programmer by profession, not a chemist. I am brand new to Jmol and what it can do. Perhaps I am wrong about using Jmol to change things and then wanting to be able to save your changes but it seemed like a good thing to me. |