On Wed, Jul 11, 2012 at 6:50 AM, Gusts Kaksis <email@example.com> wrote:
I took a deeper look into the new OOP approach, but I have to say
it still brings some legacy with it - the one I'd suggest you to
get rid of. I am talking about inline scripting. For example, the
new code still looks like this (somewhere in between tables, ew
:), and body tags):
// The standard call to insert the applet follows.
// Note that we redefine the variable now to be an object.
jmol = Jmol.getApplet(jmol, Info);
And this is a problem because....?
In between tables and body .... You could certainly avoid that by creating divs and then later populating them, is that what you are thinking?
And then thease:
Jmol.jmolButton(jmol,"load ? ","Load URL")
Which are the things I'm still preaching against. :) First of all - why does anyone need a special method to create a
<br> tag, I know it would be a mess to mix
<br><script>...</script><br> and so on,
Well, if you are preaching, I suggest you come down from your pulpit and maybe just explain your position. ;) I'll be the first to listen. Much of what you see there is legacy, going way back, and the jmolBr() is sort of silly, but if you are creating a page with lots of customized buttons, this is just a convenience. No one says you have to use it. jmolHtml() is the same.
there is a native API for catching events like this:
> var button = document.getElementById('
click', myclick_listener_function); //
FF, Chrome, Safari, others.
> button.attahEvent('click', myclick_listener_function); // IE way
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.
this code can be placed way out of HTML into a separate code for
dynamic scripting and can be run at window.onload if you wish so.
And then there could be a clean HTML code looking like this:
<p><input type="button" id="mybutton" data-script="load
?" value="Load URL" /></p>
<!-- data-* are HTML5 data attributes, where any content
unrelated data can be stored -->
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...
Second, If you say, you are already using jQuery as an AJAX
provider, then why not use it on fullest?
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?
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?)
And third. jMol jQuery plugin is intended only as as "write less,
do more" wrapper for Jmol applet. It replaces a placeholder
have it disabled) with a Jmol applet. So I propose it as a
building block for your OOP approach.
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.
Certainly you can do that now with Jmol. Just create the div:
and then, on your body onload event, use:
document.getElementById("jmoldiv").innerHTML = Jmol.getApplet(....)
Also, as the modularity is kept intact users could choose weather
they want to use full blown experience with JmolCore, JmolAPI,
etc. or just use parts of it - like jQuery plugin, WebGL approach
or write <object> tags them selves.
Not seeing that as being different from what we have now. Users can choose any combination of WebGL/Java Applet/HTML5-only/image only.
Here are a few suggestions where to start:
1. Get rid of legacy button, checkbox, br and any other methods or
change them into something like Jmol.addScript(jmol_object,
html_element, script_source). Which, from inside, would look
something like this, in jQuery's terms:
Very cool. As long as you can get all the functionality of what we have now, it certainly looks good to me. Take a careful look at what those calls allow. It's probably all doable. I think you just have to rewrite JmolControls.js if you want to implement this. Take a look there and see what you could do to create JmolControlsJQuery.js. Make sure the actual functionality is exactly what it does now.
Easy as that :) And html_element can be anything.
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!