On 2012.07.16. 21:55, Robert Hanson wrote:
On Mon, Jul 16, 2012 at 12:47 PM, Gusts Kaksis <gusts.kaksis@gmail.com> wrote:
On 2012.07.16. 20:03, Robert Hanson wrote:

It's possible that it's no problem any longer. especially if you aren't actually calling JavaScript in an href tag. So, for example, we try to avoid this:

<a href="javascript:Jmol.script(jmol, &quot;load &#92;&quot;my file.xyz&#92;&quot;&quot;)">my file</a>
Not on my watch :)

i.e., you like that for some reason. More power to you, I guess.
I think that's why I like C language - it's a perfect balance between readability and power. :)


I guess in this context that would  become something like this:

<a data-script="load &quot;my file.xyz&quot;">my file</a>
Yes it looks more like that, but for loading I've come up with even better solution:

<a href="my file.xyz" class="jmol-load">my file</a>
And I just use the magic of jQuery's selectors to add this:
    $('#jmol').jmol('load "' + $(this).attr('href') + '"');

This is the one solution, that gives user an opportunity to download a file directly weather JavaScript is running (right click -> save as...) or if it's disabled (default action of a link click). And you can even insert an image in between <a> tags so that's a beautiful solution to degrade gracefully.

I'm not seeing that. So when JavaScript is disabled, this reads:

<a href="my file.xyz" ...>my file</a>
I would still suggest that no one wants to "get the file" -- the value is not in the file, it's in the script. The file is just a bunch of atom positions and bonds (maybe; not in this case). If you have a file reader for xyz files, and you are interested in this app page, then you need the functionality of the page, not the file. Looking at the file itself -- just that -- except in the absolute simplest applications -- is not valuable. There would be absolutely no reason to have an image tag within the anchor. Unless you figure on replacing the innerHTML of that tag immediately with JavaScript. Is that the idea?
No no, the idea is that internet is for sharing, and "bunch of atom positions and bonds" might be of value to somebody. So this is why I never restrict a default functionality to anybody. Same method is used for all those Lightbox image viewers, where you have a thumbnail which is wrapped within a link that points to original image - simple left click opens up a lightbox, but right click allows you to save the image on your computer. It's this thing of sharing and freedom of information I'm more into. Anyhow, I think it's one of those things that a developer should decide on his own site.


I'm starting to think, that there should be at least two clear layers in the API. One for the hard core developers, for example, just jQuery.Jmol.js, for the ones that wish to do everything themselves, and the second one should be fully featured library for seasonal developers or complete amateurs. Last ones could use data-scriptid in conjunction with something like Jmol.storeScript('myScript', 'load "some file.xyz"'), while hardcore guys just go with the Jmol.bindLoader('.jmol-load') or just simply use jQuery.

Interesting point. So there would be a js that would somehow include a bit of jQuery, but nothing too sophisticated -- really no callback interpretation then, for example.
Yes, then I'd have to turn of my parser. And you didn't answer my question about output formatting. So I'll repeat it here:

I'm more intereseted weather the syntax of hover's 1st parameter will allways be "atom atom_num x y z"?

And what about those parameters of measurement?
"Angle H #2 - C #1 - H #3 : 109.477165", 3, "measurePicked", 109.47716522216797
1st - a string representation of a mesurement
2nd - ?
3rd - action name?
4th - the angle as a float, right?

I think it would be easier for a developer if thease values would be presented in a nice and documented structure, so that they can create whatever output they wish from it.

[We don't refer to any of our users as amateurs. Very few are professional programmers, actually.]
Sorry, didn't mean to sound rude. :(

By the way, what is Jmol spt file? It's Jmol's script file source, what about the same use case as in my <a href="file.mol" class="jmol-load">Load my file</a>, just with a prepared script file <a href="wireframe.spt" class="jmol-load">Wireframe</a>. It creates a separate request to the server, but it would really separate HTML even from Jmol's scripts. One more option to think about.

An spt file is a script file for Jmol. It runs from the SCRIPT command rather than the LOAD command. ".spt" there is not significant; it could have any extension. Jmol does not put any weight on file extensions except in very few circumstances. (If you use LOAD with a .spt, .png, .pngj, or .jmol file, it will switch to SCRIPT and use that instead, but that's about it.)
Well, then for very complicated script I see a solution, right in that spt file. And why not? It's the same as a js file for the browser.
In any case, no one wants to download a pdb file as last resort. That's way too esoteric. (Anyone who could read that file will not want it this way.) If the applet doesn't load, the best solution is to provide an image. That's what JmolApplet.js does, upon request. 
I'd propose a different approach and throw in one more buzzword - accessibility :) neither Flash nor Java is good with all the screen readers for blind people, but they are not my main concern here. My approach would be to show a static image in the placeholder in the first place and then gradually replace it with Jmol applet (instantly or with a mouse click). By the way, it's the approach http://www.pdb.org/ are using, which, I must say, is really thought trough. I think it's called degrading gracefully. And throwing in an option for file download if Jmol could not be started is one of them.

yes, thank you.  Glad you like the http;//www.pdb.org solution. 
Anyway, that's what we have going with JmolApplet.js now. Exactly that. Did you try http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm on your smart phone?
Yes, just right now. But it does only draw a static 3D image, right? Or should it be interactive, like rotation and zoom? And loading buttons don't do anything on my iPhone.

my bad. I forgot to implement server-side image generation from databases. Try it now.
Now it works.

Gusts Kaksis