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.


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to