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)
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. :/
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.
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.
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.
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 :)
I should note that Jmol.js and JmolApi.js both allow simple
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...
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
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
And this is easier than
Jmol.jmolButton(jmol, "myscript", "mytag")
? What makes that particularly appealing to you?
Let's say we have my one and only example:
<p><a href="some_molecule.pdb" class="jmol-load">DNA</a></p>
Well fancy stuff is a nice side effect for jQuery, but that is not what I'm into here.
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?)
OK jQuery-Jmol it will be.
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.
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
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.
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!