Just to confirm, Gusts, I'm totally with you on this. I've wanted to learn more about  jQuery for a long time, and this seems like a great opportunity.

My key points:

--Anything you want to do in relation to JmolCore/Applet/Api is great. Jmol.js is history.

--We don't want to remove any of the functionality of  JmolCore/Aplept/Api/Controls/CD/JME/JSpeView, but certainly a new JQueryApi.js, for example, that would extend that functionality would be terrific.

--I'm more than happy to share my experience with issues. Others on this list know a lot about this as well. Some of these I'm sure jQuery addresses; maybe some (like "a div containing an applet may not ever be set to display:none") are less obvious.

--ChemDoodleWeb.js must not be adjusted -- or if it is, that must be done in collaboration with Kevin Theissen (who is probably reading this)

On Mon, Jul 16, 2012 at 5:40 AM, Gusts Kaksis <gusts.kaksis@gmail.com> wrote:

I have to pardon my self, I wasn't looking carefully enough at Jmol.js and JmolCore.js, JmolApplet.js and JmolApi.js, and it looks that I kinda misjudged the applet initialiation process. Sorry about that :) As you alerady mentioned in your example "Jmol.setDocument(0);". So there seems to be no problems with that, my bad. :/
A good challenge for you would be to rewrite http://chemapps.stolaf.edu/jmol/docs/examples-12/simple2.htm using your alternative approach. Allow no JavaScript within the <body> (right?). Make sure it still works properly on iPad, iPhones, and Android tablets. The challenge would be to make it as simple as what you see there.

I say challange accepted, just give me some few weeks, as I have to dig deeper into ChemDoodle, JME and JSpecView APIs. My main intention was to create an alternative for Jmol.js only (and kinda stripped down version, as I said it was intended only for core build-up and communication), but now I see the possibilities in those new sample pages, where you can turn Jmol into JME seamlessly, and that kinda intrigues me. I'd be glad to create a jQuery version for JME too.


jmolButton is simply a higher level interface that allows page developers to quickly introduce functionality so that they don't have to mess with  "IE way" and "others". We really do not want page developers messing with that. Three years from now there will be another way for another random browser. This is asking to have broken pages that require difficult maintenance. But I think you know that and must mean that these would be within some other API.
The "IE way" and "others" example was intended to show low level JavaScript approach, that I saw proper. If I manage to somehow convince you to start using jQuery, all that pain would go away, because jQuery smoothly wraps all these different browser event binding problems away from us.

Well, actually, that won't work. Jmol scripts can be quite complicated, and some have enough quoting in them that they don't lend themselves to being expressed as attributes. jmolButton and other controls allow for a higher level of use that hides all that complexity. Are you suggesting the page developer writes that tag themselves? If so, then I think you are just going back to an earlier stage in our process (about  8 years ago) and not appreciating the advantage of a JavaScript library such as Jmol.js. If you mean that some API would write this tag, OK, but I don't see the advantage then of that over jmolButton.
If we return to my point of separating JS from HTML, I say don't worry about complicated scripts. HTML was intended (by Sir Tim Berners Lee) as a markup for data.

So I say there is no problems with writing simple HTML with data attributes containing some hard core scripts. Maybe, if you have some really nasty examples, that have strict indenting and line breaks, that you could show me and I could test them, then, please, show me them.

We just can't put scripts in HTML as tag attributes. Period. Find some other way. Trust me on that one.

As for quotes - always escape them. If the site is running with some kinda CMS, that can be done automatically in WYSIWYG, if the site is prepared with some authoring tool, like, for example, Dreamweaver, then it will also do it for you.

First of all, scripts could run hundreds of lines. Second, we have tried escaping these, and besides being a royal pain, mostly it hasn't worked. HTML tags and <param.  values are just not adequate for holders of scripts. It's totally unnecessary anyway, I think. the solution has been around for years, and we have had no problem with it. It seems to me you will quickly find a different way. Perhaps the "data-script" simply points to a key in an associative array that is created in the head using an API, for example.


I should note that Jmol.js and JmolApi.js both  allow simple

<div id="xxxx"></div>

within the body and all Jmol calls in the head to populate those. Most developers I've talked with just don't find that any easier. I actually like it, because it nicely separates the page formatting (in the body) from the dynamics (in the head). But still, I rarely do it unless I really have to. Jmol calls within the body are really just implementing static code anyway, so one could argue that's where they should be. But that's probably old school...
Yes, I was not paying enough attention to whole inner workings of Jmol.js and JmolApplet.js, maybe beause I was more looking at example code that used inline scripting, and that kinda made me a wee bit angry :)

Coding web pages is an evolving art. All you see there are best practices from pre-jQuery days. Some of us have seen the entire process from the start (no CSS, no DIV, no document.getElementById, etc.). So it's hard to imagine what you would be angry about. You are blessed to have missed all that, I think. Welcome to the club.

We could probably do a lot more with jQuery, but since it's only needed for the AJAX, we haven't felt it necessary to do more with it.
var jmol; // This is the Jmol object on which we are working on
function myclick_listener_function(e){
  e.preventDefault(); // If it's a link tag for example, we kill it's default behaviour
  var scriptStr = $(this).data('script'); // We could store all the scripting in HTML code in HTML5 data attributes
  Jmol.script(jmol, scriptStr); // This is where we call Jmol OOP framework and send some commands to our Jmol applet
    $('#mybutton').bind('click', myclick_listener_function);

And this is easier than

Jmol.jmolButton(jmol, "myscript", "mytag")

? What makes that particularly appealing to you?
Jmol.jmolButton() returns HTML instead of HTML already being prepared in the body, that's it. Basically, the main concern I see is that JavaScript is doing stuff it could be freed of - like generating HTML where it's not really necessary. JavaScript is great for adding action to static HTML, but why should one use it create HTML?

Well, for one thing, that was pretty much the original function of JavaScript -- to create HTML on the fly for a page. Newer browser capability has allowed that original function to be expanded greatly, and the combination of CSS and DOM in particular has greatly extended the use of JavaScript. If you are saying you never want to use .innerHTML =, that seems rather unnecessarily harsh. Even jQuery must use innerHTML, I think.

If you mean, "Never use document.write," then what you are basically saying is simply, "Let's move this to XHTML standards." That's certainly of interest to some Jmol page developers. We explored this three years ago, and mostly it didn't go anywhere.

Q: Is jQuery XHTML compliant?

If you want to remove all document.write, it seems to me you might as well go to XHTML compliance. That might require hacking of jQuery, though....

Let's say we have my one and only example:


<p><a href="some_molecule.pdb" class="jmol-load">DNA</a></p>

If Jmol didn't load properly or JavaScript has been disabled, this allows user to download a PDB file and open it up in whatever software he likes. If JavaScript is disabled Jmol.jmolButton(jmol, 'load some_molecule.pdb', 'DNA'); would not even show up.

Agreed. But also, if JavaScript is disabled, for just about all Jmol web apps, the app is toast. jQuery is dead, Jmol is dead, the page is probably totally malformed. I've never seen a need to cater to users who turn off JavaScript. Have you ever turned that off and seen how far you can get? But you are right, probably something more than a blank page is advisable.

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 think a better argument would be that if you used the jQuery framework, you could have a much richer user interface -- tabs, buttons of all sorts, flying images, etc. That, to me, would be a distinct positive, and I think some interesting examples using, say, tabbed applet panels (that work -- i.e. never use "display:none")  would be very interesting. (You know about never using display:none with an applet, right?)
Well fancy stuff is a nice side effect for jQuery, but that is not what I'm into here.

First, despite the convention, please don't use "jMol" -- we've had issues with this before and other  application. It should just be "Jmol". Please. Maybe jQuery-Jmol if you must start with a lower-case letter.
OK jQuery-Jmol it will be.



2. Get rid of document.write - it's a fast feature, but it forces developer to use inline coding. Instead I'd suggest to use native DOM methods for appending DOM fragments, or the nasty, but still easy inlineHtml or jQuery's append() or replaceWith();

That is, make all calls after the page has finished loading and the </body> tag is processed. Right? From


And then have all of JmolControls.js be implemented using jQuery. I would welcome that. I just would suggest not looking at all at Jmol.js. We need to move forward, not backward!

Well not only that, JmolApplet.js could be completely replaced with my jQuery plugin, as it's what my plugin does - it creates a Jmol applet and places a HTML code in the placeholder tag.

Sounds good. I'm totally game for that. JmolApplet.js is simply the current stage in development. I think it should be much easier to work with than Jmol.js since everything is already compartmentalized for you.

Looking forward to seeing some pages from you,


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