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 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?


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.

[We don't refer to any of our users as amateurs. Very few are professional programmers, actually.]

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.)

Q: Is jQuery XHTML compliant?
I think yes, because, it doesn't really matter, as JavaScript is working with DOM, and if DOM has been initialized as XHTML then JavaScript will work with it. If I'm not mistaken, the same innerHtml, just sends some kind of eval() to the browsers DOM parser, where it turns into a DOM fragment, whereas it really does not matter anymore weather it is XHTML or just plain old HTML.

I'm not finding support for that on the web. Depends on things like namespaces and, for example, whether data-xxxx is in a dictionary, I think.
Aah, you mean XML namespaces? Well HTML5 came with XHTML5, dropping the attempt to create XHTML 2 as it was going in completely wrong way (I wouldn't say that, but there were people who thought so). So there should be no problems with that (but I have to double check the W3C then).

If it validates, it validates. 

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.

Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN

If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900